Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Support type classes #38
As a driving example, the Dict class doesn't make sense without typeclasses. Right now, it's unclear how exactly the Dict implementation gets the "compare" function - it looks like duck typing.
Without type classes, passing in an Ord instance is preferable to duck typing.
Alternatives include generalised implicit parameters.
I think, given Elm's Haskell heritage, Haskell-style type classes would be nice.
Type classes and/or module functors (like in OCaml) are on my very long to-do list. Don't worry!
Elm currently uses Standard ML's method of operator overloading. It is a thing :) I chose it because it can be gracefully upgraded to work with type classes.
There are problems with adding to Dict an explicit comparison function or "Ord instance" (which I think needs to be
This would be well typed but not really meaningful: how do they get put together? Why should this even be a question when working with dictionaries of the same type? Later when type classes or module functors make it into Elm, what happens to the code that uses the old API with an extra argument? It all breaks or I have to support two different ways of doing dictionaries (and one version has semantic problems).
Long story short, type classes are in the works, and based on the trade offs that come with each interim option, the current solution is best in my opinion until I add something better. For now, Dict and Set should work with strings, chars, ints, floats, and times which all define a
I just stumbled on the issue related to this - Set(Dict) inability to work with tuples. Please add the aforementioned note as fast as you can, so that nobody will hit the wall because of this. Why there's no error when using tuples with Set, when there's no compare function defined for them?
So I learned at LambdaConf about the existence of elm-html and am now conflicted. Elm has everything I want in an interface system except typeclasses. Everything I want is here on the Elm side in terms of libraries and functionality, but no Monads, and very limited type level programming in general; which is what attracted me to PureScript in the first place. Typeclasses need to be on the roadmap to compete with PureScript's future.
The current plan is that in the long term some type-class-like feature will be supported. It's currently low priority and will probably not replicate Haskell's exact solution because Haskell requires all kinds of extensions to use type classes for all the situations where you want them. It is more likely that implicit arguments will be borrowed from Agda, which in combination with Elm's records will be enough to emulate everything around type classes. Use your favourite search engine to find more information on the mailing list, or about Agda, or about a method in the blog post "Scrap your Type Classes" about how you can use records for emulating type classes.
referenced this issue
Aug 25, 2015
@Apanatshka has described the state of the world quite well.
I'm gonna close this. The arguments for and against this (and the various alternatives) are understood at this point, and I am very skeptical that further discussion will reveal new information. It is conceivable that there is a theoretical break through revealing a 4th way of achieving these things, but I'll hear about that independent of this issue. This is obviously on my list of "features to think about" along with a bunch of other stuff, so I will do the appropriate thing at the appropriate time.
If you feel compelled to comment on this issue more anyway, first please look through the mailing list to get an idea of what has already been said (everything) and maybe watch this to get a feel for how these decisions are made. The most relevant point there is that the timing of a feature is an important aspect in how the feature is used.