blog.tmorris.net
wrong
Alternatives to OOP
They are a basic form of type level programming. They form partial/open type functions which can return a record of methods. What this can be use for is dealing with is tracking a type's membership to a constraint as well as a limited form of constraint implication, in addition to being parametric over objects/implementations.
This can do something as basic as prove that a type is more than what you think it is, like with the Functor-Applicative-Monad hierarchy, or, how Traversable implies Foldable and Applicative.
In the extreme, in terms of data, it can be used to automate capability/authentication checking. (Something that Kmett has actually implemented)
But more importantly to people is the fact that it gives a total assurance of membership of a type in a parametric function without losing sight of what that type is, and not losing sight of what other instance that type has.
While it can be said to be an interface, a typeclass is an interface parametric of types not objects, it's also a constructive proof mechanism. It's 100% what Casey was talking about but doesn't seem to know about.
This shit is so far up its own ass. Like , too. Can't they just give a simple example of some code that is improved by this feature with a before/after conversion? Rather than talk endlessly about nothing? That's how features in actually useful languages are sold rather than ramble like a crazy person about traversable applicative monads and their constructive proof mechanisms.
The Haskell community is a joke.
Oh hey, turns out they were total bullshit after all. They're just sugar.
Sorry bud we are not all web developers like you.
Everything in Haskell compiles down to a very simple IR a few constructors you retard. The entire fucking language is sugar.
Imagine my cock
Seems like he knew a lot more than your whole community of LARPers. They're just sugar. lol. Explain yourselves immediately.
Every feature of the language is sugar
youtube.com
Yes pajeet knows more Java.
I'm tired of python skids and web developers thinking they understand how compilers work.
Destitute poverty pajeet
Judeo-Aryan high IQ alliance
None of the shit you said except maybe "inherit" is specific to OOP.
You could do exactly what you said in Haskell. More idiomatically you would probably have something like
data Object = Item | Creature | ...
data GameState = GameState (Map Coordinate Object) ...
Probably shouldn't waste my time on this but I'm retarded, so here goes:
* GHC eliminates explicit dictionary passing in 99.9% of cases except weird cases like where you use ExistentialQuantification or when the inliner heuristics see a huge code size benefit
* GHC doesn't actually desugar typeclasses to this. You can look at the generated core for yourself; you don't have to take my word for it. SPJ is just giving a simplified explanation. It wouldn't even make sense for GHC to do this anymore because you can't represent e.g. TypeFamilies with this construction
* Just because something is semantically reducible to a different concept doesn't mean that using it is the same as using the simpler concept
* The interesting part of using typeclasses is what you can offload to the type-level constraint solver system, which is basically a prolog dialect. It is absolutely not interesting what the typeclasses are compiled down to, but you are wrong about even that