|
|
|
|
|
|
by kccqzy
3118 days ago
|
|
|
More than 20 years ago people solved the token-that-must-be-consumed-once problem with the IO monad. Just a secret token that gets threaded everywhere. The monadic bind is just great syntactic sugar. Also more than 20 years ago people figured out a way to keep separate tokens completely independent and forbid them from interacting with each other. That’s the phantom `s` type variable in ST. Nowadays we have so many more complicated solutions (not all of them worthwhile!) giving you choice how you want to make sure an intermediate state is consumed once. Why not implement a state machine at the type variable using DataKinds, TypeFamilies et al? Or you know, for the case of ensuring file handles/database connections get closed correctly, use monadic regions: http://okmij.org/ftp/Computation/resource-aware-prog/region-... (disclaimer: I haven’t read this paper or used this approach myself but I heard it’s a good technique) But more importantly, even if introducing linear types can make what’s currently barely doable in Haskell easily doable, maybe even replacing five language extensions with one, does it have a good power-to-weight ratio? I’m not convinced. Is the kind of mistakes prevented by this language extension often made by typical Haskell programmers? My answer is no. |
|
|
The kind of mistakes often made by Haskell programmers interacting with objects not well managed by the Haskell garbage collector? Yes, absolutely. Whether there's enough Haskell programmers in that situation, I am unsure; quite possibly not, but it includes me and my colleagues, as well as those currently doing the work.