3 ms·

What you describe reminds me of Rust's typestate, which they removed. But the "branded types" replacement, combined with the unique pointers, sound promising -

What you describe reminds me of Rust's typestate, which they removed. But the "branded types" replacement, combined with the unique pointers, sound promising - see http://pcwalton.github.com/blog/2012/12/26/typestate-is-dead/ http://pcwalton.github.com/blog/2012/12/26/typestate-is-dead... I am new to Haskell, but I also have objections to Haskell's notions of purity. For example, accessing your pid or your argv do not have side effects, and certainly do not perform IO, yet these are grouped in the IO monad next to file deletion.

tel 14y ago
Runtime constant values as IO is a long-standing concern. The existence of withArgs cements the issue (definitely allows for non referentially transparent code to be written with getArgs) but there's more to be said about why withArgs exist and why getArgs is in the IO monad. http://www.haskell.org/pipermail/haskell/2005-October/016574.html http://www.haskell.org/pipermail/haskell/2005-October/016574... The argument usually seems to play out as "their denotation is uncertain" and therefore they get unceremoniously thrown into the IO monad. I tend to agree with that in that I feel a major point of purity is that it gives you a world sufficiently far from the reality of the RTS to play in. IO's general status as the "Unsafe Pandora's Box" is a wart in Haskell. I'd much prefer it be called the RTS monad and have something like IOSpec's Teletype type performing the classic IO. It's fixed by convention now though.
- Chris_Newton 14y ago
  IO's general status as the "Unsafe Pandora's Box" is a wart in Haskell. Isn’t that rather like saying mutable variables are a wart in C? :-)
  - deleted 14y ago
    [deleted]
  - tel 14y ago
    Sure. Haskell's wart is automatically verified to be context constrained by the type system, though. There are also lots of tools to mitigate that wart that are also verified.
  - tikhonj 14y ago
    It's more like saying void pointers are a wart in C. It's appropriate in two ways: for one, void pointers are a wart, and for two, there's no good way to get rid of them without radically changing the language.

tel 14y ago

Runtime constant values as IO is a long-standing concern. The existence of withArgs cements the issue (definitely allows for non referentially transparent code to be written with getArgs) but there's more to be said about why withArgs exist and why getArgs is in the IO monad. http://www.haskell.org/pipermail/haskell/2005-October/016574.html http://www.haskell.org/pipermail/haskell/2005-October/016574... The argument usually seems to play out as "their denotation is uncertain" and therefore they get unceremoniously thrown into the IO monad. I tend to agree with that in that I feel a major point of purity is that it gives you a world sufficiently far from the reality of the RTS to play in. IO's general status as the "Unsafe Pandora's Box" is a wart in Haskell. I'd much prefer it be called the RTS monad and have something like IOSpec's Teletype type performing the classic IO. It's fixed by convention now though.

Chris_Newton 14y ago
IO's general status as the "Unsafe Pandora's Box" is a wart in Haskell. Isn’t that rather like saying mutable variables are a wart in C? :-)
- deleted 14y ago
  [deleted]
- tel 14y ago
  Sure. Haskell's wart is automatically verified to be context constrained by the type system, though. There are also lots of tools to mitigate that wart that are also verified.
- tikhonj 14y ago
  It's more like saying void pointers are a wart in C. It's appropriate in two ways: for one, void pointers are a wart, and for two, there's no good way to get rid of them without radically changing the language.