Where is Elm going; where is Evan going

Request Feedback
94

I think you can define a nice set of basic capabilities, but I think I would also want user-defined capabilities.

I have been using Jeremys OO style pattern in Elm to do ad-hoc polymorphism, by hiding the implementation in a continuation. Elm Object Oriented Style

This let me define an element in a drawing like this:

type Element msg
    = Element (ElementIF msg)

type alias ElementIF msg =
    { move : VScene -> UpdateContext msg -> UpdateContext msg
    , select : UpdateContext msg -> UpdateContext msg
    , animate : Posix -> Maybe (Element msg)
    , position : PScene
    , bbox : BLocal
    , view : ViewContextIF msg -> List (Svg msg)
    }

What I would use ‘capabilities’ for is to define this exact same interface, and then create multiple implementations of it.

The issue with the technique that lets us use the above already in Elm, is that is is a bit of hack, to hide the implemtation using continuations. It is also inefficent as a result. Its actually fine for TEA event handling because the overhead is not so noticeable there. But for more fine grained use, say defining implementations of hashable for user defined hash table keys, it is too slow.

I think capabilities bring a decent level of ad-hoc polymorphism to the language, which will make it easier to program in an open-ended fashion. As per my example, everything a new drawing element needs is all specified in a single interface. I can add new ones without going through a lot of existing code and altering many case ... of statements to hook in the new behaviour - they are self-contained.

2 Likes