Optional Key Records - Syntax Proposal

First of all, thank you for this detailed write up! I happen to have myself been frustrated by some limitations on the record syntax on several occasion (knowing very well that Elm records are among the most delightful to work with out of any programming language I ever encountered, so there’s that).

However, I am absolutely not in favour of the Optional Key Record syntax proposed here.

Please feel free to correct me if I’m wrong but the proposal, as stated here, would basically mean promoting the Maybe a type to have special compiler support and I can’t personally endorse that. This would open a whole class of problems:

  • What if someone would like some other type to have a default empty value (basically, the mempty part of the Monoid type class ala Haskell) ?
  • What should be a proper default for a Maybe a ? It could be either be Nothing but it could also be the Just default assuming the a type defines a default of its own.
  • Shouldn’t we also define a default for lists ? That should be easy enough, it’s []. What about booleans ? It depends, it could be True it could be False depending on what you may want to do.

At that point, it becomes more interesting to define some kind of ad-hoc polymorphism mechanics (be it type classes or not) to allow users to define default or empty. Notice that we’re already in the same kind of debate than with the number, comparable and appendable magic type variables in Elm. And I think adding a magical defaultable in the same spirit would be the absolute worst out of several already bad solutions.

Evan already stated that record syntax should stay minimal (cf. here and here).

To be clear, I would wholeheartedly support some additions to record syntax to make them a little easier to work with. But I don’t think the propositions stated thus far are any good, and I am truly sorry that I don’t have any other one to contribute myself at that time.

Really interesting discussion though.

As a side-note, I find it interesting that such a request comes more or less at the same time than this one whose “quick and easy” solution also seems to be some kind of type-class mechanic (Enum / Bounded) and I look forward to read some out of the box possible ideas on the subject (I am in no way promoting addition of type-classes to Elm, but I do feel that some form of ad-hoc polymorphism would be beneficial in the long run).

3 Likes