Support type classes

[techtangents]

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.

e.g.
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.

[evancz]

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.

[evancz]

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.

[techtangents]

Okie dokie. Type classes FTW.

[techtangents]

Okie dokie. Type classes FTW.

[solarplexus6]

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?

[solarplexus6]

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?

[adnelson]

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

[adnelson]

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

[viclib]

Same

[viclib]

Same

[fosskers]

Purescript does.

[fosskers]

Purescript does.

[Fresheyeball]

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.

[Fresheyeball]

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.

[unbalancedparentheses]

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

[unbalancedparentheses]

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

[Apanatshka]

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.

[Apanatshka]

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.

[evancz]

@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.

[evancz]

@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.

[evancz]

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.

[evancz]

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.