Is it fair to say abstraction and expressiveness are Elm's weak points?

rupert 2018-05-22 09:32:01 UTC #23

I would also like to add that type-classes can be done in Elm. Not everything that can be done in Haskell is possible, but there are still many ways in which they can be used effectively in Elm. Here is an example:

github.com

the-sett/ai-search/blob/master/src/Search.elm#L146


zero, when performing an iterative search. For bounds that do not iteratively
increase, this can be ignored.
-}
type alias Limit state =
Int -> Node state -> Bool




{-| Defines the operations needed on state buffers that hold the pending search
states.
-}
type alias Buffer state buffer =
{ orelse : Node state -> buffer -> buffer
, head : buffer -> Maybe ( Node state, buffer )
, init : List (Node state) -> buffer
}




{-| This utility function is used to convert a comparison over states into a
comparison over search nodes.
-}
nodeCompare : Compare state -> Node state -> Node state -> Order

And see the implementations of the Buffer class on lines 287, 304 and 314.

reactormonk 2018-05-22 13:28:24 UTC #24

Very rudimentary typeclasses are possible, but neither higher-kinded classes [1] nor hierarchies [2] are supported.

[1] can’t have higher-kinded types - apparently the type aliases compile (bug), but you can’t use them
[2] http://reasonablypolymorphic.com/blog/elm-is-wrong/

Tann 2018-05-28 07:36:52 UTC #25

Hi, here is my take after 4 years of Haskell, and several months of Elm and front-end stuff.

I think that the most important piece in FP is Functors. Elm has them, albeit in many flavours as the typeclasses are not there to help factor the code.

Typeclasses does not bring additional power to the application developper, because in that case a union type can handle all the given cases. It seems to me on the other that library development would greatly benefit from typeclasses, because then you can define typeclasses for cases you cannot know yet.

The aim of Elm being to develop front end applications, I must admit (reluctantly because I love those abstraction stuff) that the balance between power and simplicity is good as it is.

Tann 2018-05-28 07:47:27 UTC #26

I personallly would love Elm to have Zygohistomorphic prepromorphisms

Not to use them of course, since it is utterly out of my intellectual reach. But I kinda like the idea of added expressiveness (of course they are joke also in Haskell…)

rupert 2018-05-28 14:43:09 UTC #27

I must have read about 3 text books on Haskell, and somehow never got past the Monads chapter on all of them. I think Elm has hit the sweet spot, as you say, somewhere between power and simplicity that is just right.

miniBill 2018-05-29 21:42:45 UTC #28

I think that when you understand what all the andThen functions have in common you can read the Monads chapter and get it easily.

After all:

Maybe.andThen : (a -> Maybe b) -> Maybe a -> Maybe b

(=<<) :: Monad m => (a -> m b) -> m a -> m b infixr 1

system 2018-06-08 21:42:49 UTC #29

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.