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:
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…
Whether the ability to generate one’s own operators should be as restricted as it is in Elm…
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”…
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…
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.
I just found another thread here about another proposal for an Elm-like language that shares many of the ideas I have about eliminating Garbage Collection (GC) by using smart reference counting with elided counts and mutation in place when the compiler can determine that the old value is never referenced again, as well as re-using memory allocations for similar conditions in order to save the high cost of memory allocations/deallocations: post here by @Bram; I’m just not as sure about the proposals for “guaranteed memory safe functions”.
Evan even chipped in with a post that offered suggestions to look into using the techniques that the Koka language uses as in the Perceus memory management model and re-using allocations, both of which are as used by the Roc language, and which have become commonly known as optimization techniques to avoid the use of GC with some or similar techniques used in some language implementations such as the imperative language Nim and another imperative language called Lobster. Some of these languages documentation make reference to the Perceus research and to “mod cons” optimizations which have been proven to work.
Although I like the research possibilities of investigating “memory safe functions” as referenced in the thread linked above, I don’t see including this feature in a ElmPlus language as it would break the Elm syntax in ways that would make such a language not backward compatible with Elm; going by history, the development of new languages with their own syntax takes something about ten years before being commonly accepted languages if successful: Nim is now pushing twenty years worth of development, Odin and Zig have something like ten years of development, and even Rust (probably the most popular of “new” languages) has been publicized for about six years - Elm has taken about twelve years to get to where it is although the past five years since version 0.19.1 have been mostly stagnant…
I seems to me that the Roc language is perhaps the most popular of the new functional languages that aims to be able to offer something like the features as I propose for ElmPlus, but my opinion is that it is going to take at least another five years before it is ready for production code to the point where current Elm users might consider switching to it and then they are going to have to switch everything including IDE tooling (thanks for mentioning that, @uweg) and re-writing all of their source code. It seems to me that there is nothing all that bad about the existing Elm source code syntax that makes it worth diverging from in the interests of back-compatibility…
I want to avoid a development project that takes more than a few years to being able to be used in production and generating enough interest so that someone else can take over the management of contributions and maintenance as I may not be able to support it for all that much longer than that - definitely not as long as twenty years as has been the development of Nim by Andreas Rumpf!