New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support type classes #38

techtangents opened this Issue Nov 12, 2012 · 11 comments


None yet
9 participants

techtangents commented Nov 12, 2012

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.

instead of:
singleton :: k -> v -> Dict k v

do this:
data Ordering = LT | EQ | GT
data Ord a = Ord (a -> Ordering)
singleton :: Ord k -> k -> v -> Dict k v

Alternatives include generalised implicit parameters.

I think, given Elm's Haskell heritage, Haskell-style type classes would be nice.


This comment has been minimized.


evancz commented Nov 12, 2012

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 a -> a -> Ordering) as you can do in some functional/imperative hybrid languages (Scala right?). Say we have two different Ord instances ord1 and ord2, and someone writes:

fromList ord1 [ (1,0), (2,0) ] `union` fromList ord2 [ (3,0), (4,0) ]

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 compare function internally. I'll add a note to the Dict and Set libraries to make this clearer.


This comment has been minimized.


techtangents commented Nov 13, 2012

Okie dokie. Type classes FTW.


This comment has been minimized.

solarplexus6 commented Dec 4, 2012

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?


This comment has been minimized.

adnelson commented Aug 4, 2014

Sorry to revive a 2-year-old thread, but does Elm plan to support type classes? If not, why?


This comment has been minimized.

viclib commented Mar 11, 2015



This comment has been minimized.


fosskers commented Mar 11, 2015

Purescript does.


This comment has been minimized.

Fresheyeball commented May 26, 2015

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.


This comment has been minimized.

unbalancedparentheses commented Jun 29, 2015

It would be really useful to have type classes. I don't know how difficult it's to add them but it would be really helpfull :D


This comment has been minimized.


Apanatshka commented Jun 29, 2015

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.


This comment has been minimized.


evancz commented Aug 29, 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.


This comment has been minimized.


evancz commented Aug 29, 2015

Alright, made the #1039 meta issue to track all type system extensions and describe the state of the world for folks interested in this topic.

I am trying a new pattern of managing design discussions and suggestions, described in more detail here in the "design discussion" section.

@elm elm deleted a comment from brainrape Sep 30, 2017

@elm elm locked and limited conversation to collaborators Sep 30, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.