It’s not a “you can” question, the person writing the library either provides you with the functions to do a given thing or they don’t.
In current Haskell you need to augment the Logger and pass the modified value to all relevant functions.
With references the library would declare an implicit configuration reference and you’d augment that for all functions invoked within a context.
tomjaguarpaw:
if
IOScopedRefexisted then I could instantiate theLoggerargument towriteUserDatato get the behaviour I desire
Yes, though I would object to this feature being implemented like that.
tomjaguarpaw:
I don’t know what “with references” means.
As in with either contextual values I outlined above or IOScopedRef.
tomjaguarpaw:
Do you mean I shouldn’t use
IOScopedRef(if it existed) to get the behaviour I desire
Not exactly, my point is that tacking dynamic allocations onto this feature is at best unnecessary and at worst would pollute the language with a second way to do something it already excels at.
A static reference table is the “missing” thing in the language as I see it.
tomjaguarpaw:
…
BurningWitness:
Not exactly, my point is that tacking dynamic allocations onto this feature is at best unnecessary and at worst would pollute the language with a second way to do something it already excels at.
I don’t understand. What is “this feature”? Your “contextual”?
BurningWitness:
A static reference table is the “missing” thing in the language as I see it.
OK, fine, and if that…
OK, so are we agreed, then, that if IOScopedRef existed then I could instantiate the Logger argument to writeUserData to get the behaviour I desire? And that with only the primitives provided by Haskell as it currently stands, the Logger argument to writeUserData cannot be instantiated in a way that gives me the behaviour that I desire. Instead Logger or writeUserData or both would…
If it’s unnecessary then what is the alternative way that I can instantiate the `Logger` argument to `writeUserData` to get the behaviour I want, in haskells-missing-mutable-ref?
BurningWitness:
tomjaguarpaw:
if
IOScopedRefexisted then I could instantiate theLoggerargument towriteUserDatato get the behaviour I desireYes, though I would object to this feature being implemented like that.
Sorry, what feature? Do you mean I shouldn’t use IOScopedRef (if it existed) to get the behaviour I desire, or IOScopedRef shouldn’t be implemented? In either…
tomjaguarpaw:
What is “this feature”? Your “contextual”?
Yes, worker threads carrying tables of references with table size defined at compilation time.
tomjaguarpaw:
I’m pointing out it’s not the library that declares the implicit configuration, it’s the caller.
Would this make for a good point of abstraction though? I’d expect a given library to need several internal values be…
Would you consider hiring someone through an Estonian company established via e-Residency , or do you require a personal right to work in one of the listed countries?
BurningWitness:
Would this make for a good point of abstraction though? I’d expect a given library to need several internal values be adjustable, not some interface type like
Logger.
Ah, well now it’s a question of API design, an area where I suspect, based on this comment, we will disagree, but not really the point of the original article. Happy to continue in a fresh thread if you create…
I once implemented a PostgreSQL client that didn’t use libpq either.
You might find it interesting to examine the differences in implementation approaches.
(I haven’t been updating it much recently, but
Hackage
pure Haskell PostgreSQL driver
idna2008 is a ground-up, pure-Haskell implementation of
Internationalized Domain Names in Applications (IDNA 2008):
Codepoint tables are derived from the Unicode Character Database
(17.0.0) by an in-tree generator script. Later Unicode editions can
be…
viktor:
> * Source: https://github.com/vdukhovni/idna2008
>
This link gives 404 to me.
Thank you for the status report!
Somewhat incidentally, I’ve never noticed this recommendation in the GHC documentation before:
We recommend compiling any code that is intended to be run in parallel with the -feager-blackholing flag.
Huh.
Hello everyone!
We are hosting the next Haskell meetup in Vienna on the 25th of June 2026! The location is TU Vienna Treitlstraße 3, Seminarraum DE0110. The room will be open starting 18:00 and the first talk will start at 19:00.
We are excited to announce, the speaker for our next meetup is Dominik Schrempf (@dschrempf)
Compiling C to Haskell — How
hs-bindgenTranslates C Headers
There…
I think I see: you are making the claim that dynamically allocating such references is not useful?
Slightly stronger, I don’t see how you can implement that without breaking some fundamental part of the language (I think referential transparency, but I don’t have the background to concisely describe it).
BurningWitness:
I don’t see how you can implement that without breaking some fundamental part of the language
Well, I explained how I can get my API from yours.
And another potential implementation is explained here: A reference implementation of IOScopedRef
tomjaguarpaw:
Well, I explained how I can get my API from yours.
Yes, and I explained that I have no idea what “reading from the vault” would look like. I’m essentially getting
contextual vault :: Contextual Vault
foo :: IO ()
foo = do
a <- _ vault
print a
---
main =
withScopedIORef vault 5 $ \x ->
overriding x (+2) $
foo
with…
tomjaguarpaw:
It can grow dynamically.
Yes, but that would require a completely different implementation. No matter how you slice it these references will have to live in CPU cache, and a static table is the most compact solution to that.
Much like with [RFC] Mutable records as a GHC extension, I view a simple solution that fits the existing model as infinitely more preferable to both the…
tomjaguarpaw:
which allows references to be allocated dynamically
And that’s a feature you’ll have to argue for.
Per my earlier example the piece of code we’re looking to allow for is
main = overriding x (+2) foo
such that overriding x modifies the behavior of foo without passing x to foo.
Your implementation uses ReaderT Vault, which, as others have pointed out, is…
Following up from yesterday’s post:
Haskell's missing mutable reference type Links
Whilst looking at the Scoped thread-locals GHC proposal I realised that Haskell is missing a mutable reference type that some other languges have (and people have tried to encode in Haskell), so I wrote it up: haskells-missing-mutable-ref
Today I show a reference implementation for IOScopedRef:
I’m not sure exactly what implementation you’re thinking of, but a table which grows dynamically is essential to implement withIOScopedRef, which allows references to be allocated dynamically. However, that variable-size table can be implemented as a Vault inside a fixed-size table: A reference implementation of IOScopedRef
I’m still not quite sure what you mean. Yes, withIOScopedRef in particular, and IOScopedRef in general, is a feature I am arguing for! Part of its essential behaviour is to allow references to be allocated dynamically, just like an essential feature of IORef is that they can be allocated dynamically.
But suppose I had your contextual. I could define
contextual vault :: Contextual…
If the value is dynamically allocated, then how do you use it inside a function without passing it? And if you’re passing a value, why not determine the wanted behavior based on passed value instead? The following is obviously not valid Haskell:
module Foo (foo) where
withIOScopedRef 5 $ \x ->
let foo = _ x
The point here is that x is not a value , it’s a place. foo…
BurningWitness:
It’s mutating if you look at the flow imperatively, but that would be an implementation detail.
That’s a fine point of view. I don’t have a strong view on what “mutable” should mean, but I think it’s interesting to know that the fact that IORef is implemented by actually mutating the value stored in a piece of memory is also an implementation detail. According to The Key…
Thanks for the feedback!
BurningWitness:
Okay, I had to spend 40 minutes figuring out what this is, and I’m still not sure.
Maybe the reference implementation in the next article (linked at the top of the current one) will help?
BurningWitness:
Am I correct to understand that the problem you’re looking to solve is that of a user-definable implicit global context, which can be adjusted…
tomjaguarpaw:
Why is it not “mutable from the user perspective”? The value of
x“mutates” here, doesn’t it?
It’s mutating if you look at the flow imperatively, but that would be an implementation detail. I instead think of x as a stack of changes over the initial value; no matter what I do, upon reaching the end of an overriding function x will be exactly the same as it was…
A Stackage intro/status report by Jens Petersen.
Stackage
### Stackage talk at Haskell Ecosystem Workshop 2026
Stackage talk given at the HF Haskell Ecosystem Workshop 2026 (Zurihac)
Two new i386 specific bugs were found on GHC this week:
GitLab
when building ghc for i386, either in an i386 debian container or targetting i386 on x86_64 host, if the ghc tree is configured with --intree-gmp, the external...
GitLab