Current State of General Purpose ElmPlus

Request Feedback
21

@axelbd:

Glad we see it the same; as I said, my main regret with Gren is that it splits from being backward compatible with Elm so any that make the switch from Elm to Gren are going to have to refactor their packages and code.

Lately, I’ve been considering four major things that would affect ElmPlus:

  1. Whether it should have the most requested feature of Type Classes/Abilities: I don’t see that this is yet proposed for Gren; Ability’s are a limited feature of the Roc language with no Higher Kinded Type’s (HKT’s) meaning it can never have Mappable, MultiMapable, and Chainable (equivalent to Functor’s, Applicative’s, and Monad’s in Haskell/PureScript). So I guess if HKT’s were offered, it would be something that might cause some to choose ElmPlus over those others if they consider that feature particularly desirable. However, adding the complexity of HKT’s would only eliminate the boilerplate for the multitude of map, mapN and andThen functions of which there aren’t all that many, but would also permit a more general use of “do notation sugar” which could be more useful. None of these are absolutely essential, so I guess the decision to include them cam be deferred. Adding just Ability’s is quite useful as it allows a more general constraint system: for instance, if one were to add a iteratable constraint which would include those Type’s that include filter, foldl and foldr functions, using Elm’s current constraint system, one would then need to add comiter for those Type’s that are both comparable and iterable unless one were to expand the meaning of iterable to also include appendable and make all Type’s that are iterable include all Type’s that are currently appendable but also Type’s such as Dict a, Set a, Array a, etc. Then one has Abilities such as hashable, encodable and decodable that give equivalent problems with the current Elm constraint system if one needed these to be combined with other constraints such as comparable…
  2. Whether the ability to generate one’s own operators should be as restricted as it is in Elm…
  3. Whether to restrict the use of the Foreign Function Interface (FFI) for generating web pages as much as it is in Elm in the interests of “no run time error’s in practice”…
  4. For me, if the new ElmPlus language doesn’t offer performance comparable to C, I’m not all that much interested in completing it. In the interests of checking whether it should give good performance, I’ve been writing C code that should resemble what the new compiler is able to generate. So far, it looks like even with bounds checking, the code generator should produce code that is about the same speed as Rust with bounds checks as long as Custom Type’s are used with pointers to the stack (rather than the heap) where possible. The code should be as fast as C for the same algorithm when UnsafePointer’s including pointer arithmetic and unsafe mutation on store’s (without bounds checking) are used (when allowed, which is a question), which UnsafePointer’s will be necessary anyway if there is to be FFI with C code…

Including any of these features in ElmPlus need not break backward compatibility with Elm…

Please chip in if any of you have ideas on these…

22

Whether the ability to generate one’s own operators should be as restricted as it is in Elm…

For operators, the author of Odin (gingerBill) has talked before about how instead of allowing overloading operators he made sure the basic operators supported some of the most common uses for overloading (matrix multiplication, array * array, array * scalar, etc). Odin also has distinct types (they resemble something similar to Haskell’s newtype) which allow for preventing say Feet * Meter (assuming those are distinct types) but Feet * Feet or Meter * Meter is fine.

I’ve been writing a LOT of Elm recently with ianmackenzie/elm-geometry and ianmackenzie/elm-units and Odin’s distinct types would solve my use of functions like Quantity.minus, Quantity.ratio, and so forth.

23

I share this opinion. Not to forget the tooling support (e.g. IDE integration) which is important for usage in bigger projects.