There’s a “Stop trying to make Haskell happen, Gretchen - it’s not going to happen!” joke here, somewhere.
He’s ... just not your type?
What Kind of joke is that?
A primer on the cruel, tacit laws of type-level programming in Haskell
61–69 of 69 posts
Re: A primer on the cruel, tacit laws of type-level programming in Haskell
#62Holy 6MB 2,046px × 1,416px image, Batman!
Yep. Multiples of them totalling 35.4MB of pointless, bandwidth-sucking stupidity.
Re: A primer on the cruel, tacit laws of type-level programming in Haskell
#63Kinds in Haskell seem to be evolving in the direction of controlling the representation of datatypes in memory. * (also called Type) is the kind of types whose values are "lifted": they can be lazy computations which might cause an infinite loop, throw an exception, and so on. There are also kinds for types whose values are "unlifted", meaning they really correspond to actual values in memory, not lazy thunks. Right…
I'm not sure that "evolving" is the right phrase - unlifted types have always been a part of low-level (generally compiler-specific) Haskell.
Re: A primer on the cruel, tacit laws of type-level programming in Haskell
#64Re: A primer on the cruel, tacit laws of type-level programming in Haskell
#65Re: A primer on the cruel, tacit laws of type-level programming in Haskell
#66Re: A primer on the cruel, tacit laws of type-level programming in Haskell
#67There seems to be a nigh-irresistible urge for people, when explaining type systems, to pick examples that are absolutely useless. None of the types in the theme here make much sense. They are arbitrary. The contribution to writing a robust program is questionable and they don't do much to explain concepts. May as well stick with classic "Goats are mammals; that should be enough to get you going with OOP" examples, a…
That's a problem with the domain itself. Type system examples can be two of: short, concrete, well-motivated. Short concrete examples don't have time for motivation; concrete well-motivated examples require lots of text (or else are unreadable); and short well-motivated examples are forced to be highly abstract.
There's no substitute for actually encountering a real-world problem which makes you want/need type-level programming. The article makes the sensible choice of not trying to invent one for you. I don't think it should be bemoaned for that.
Re: A primer on the cruel, tacit laws of type-level programming in Haskell
#68Re: A primer on the cruel, tacit laws of type-level programming in Haskell
#69Kinds in Haskell seem to be evolving in the direction of controlling the representation of datatypes in memory. * (also called Type) is the kind of types whose values are "lifted": they can be lazy computations which might cause an infinite loop, throw an exception, and so on. There are also kinds for types whose values are "unlifted", meaning they really correspond to actual values in memory, not lazy thunks. Right…
Can't you just add bang patterns, use deepseq or use the strict/strictdata extension?