Syntax

I will admit that before I tried my first programming language that used significant whitespace, I thought it would be horrible. I cannot remember why. I was thinking about this whilst reading An incomplete list of complaints about real code. In this the author doesn’t like signficant white space, here is what they say: I don’t like meaningful whitespace. If a tab means one thing and a space means another and they both print the same way (i.e., NOTHING, a big blank space on the screen), I’m not going to be happy. Also, if the amount of whitespace somehow controls branching or blocking of code, you better believe I’m not going to be happy when it trips someone up. ...

This post is pure, unadulterated bike-shedding, on the use of the | operator for extending a record type. As I’ve said many times before, one of the big draws of Elm is the clean, and very slim syntax. This has numerous benefits. One thing I never noticed before but has just been pointed out on the Elm discouse is that the bar operator | is used for two different, unrelated record-type meanings in Elm. The first is within a record type to indicate that the record is an extensible one: ...

A fairly common problem for an Elm developer to encounter after around 6 months is that nested record update is a little painful. Suppose you have a form on your model, like this: type alias CommentForm = { content : String , subject : String , visibleToAll : Bool } type alias Model = { route : Route , commentForm : CommentForm , ... } So now you want to handle the message for updating the comment form. So you might have a handler like this: ...

An interesting thread came up on the Elm discourse today. It concerned the point of the unit type () (which is also the only value of type unit). The question was do we really need this? Couldn’t we use the empty record {}. This then provoked the question of whether we even need tuple types at all, why not just always insist on record types? I find it quite interesting that even in Elm a language that is far more frugal with its syntax than most, you can still find parts of the grammar that have questionable use. I think getting rid of both the unit type and more generally tuples would be perfectly doable, though I doubt it will happen since it would be somewhat inconvenient for most since tuples are even used as the results of both the init and update functions. Hence all programs and probably a large proportion of libraries would need to be updated for the change. Nonetheless it’s pretty fun to imagine the language without tuple types. ...

Elm apps, require that we define a single type, usually called Msg, to host the type of messages that form a major part of the ‘The Elm Architecture’. This single type is usually a custom/variant type, and because it must host all of the messages that the app may consume, it can get rather large. This leads to a large update function. I do not think this necessarily a bad thing, but many beginners to Elm baulk at the idea of large functions, and so they seek solutions to break up their Msg type. The basic idea is to make your messages hierarchical, so you have a variant that itself contains a variant. The question is how best to split this up. I’m going to explain why the first instinct in this is usually wrong, suggest a slightly better way, and end up by claiming that the main thing is to remain fluid in your datatypes so that you can best represent whatever the current situation is, rather than cling to an old design for earlier requirements. ...

Just after I wrote about lambdas in Elm suggesting that they were not particularly useful and if we had a mind to we could remove them from the Elm language (very unlikely to happen since I think it would cause too much anger within the Elm community), I read on the awesome Python newsletter a post regarding lambdas in Python, specifically 5 uses of lambda expressions. The author doesn’t quite have a main point, but it seems to be that lambda expressions are useful and you should use them in your Python code. ...

As I’ve mentioned many times on this blog Elm has a famously pretty frugal syntax. There are obviously positives and negatives from this. A potential negative is that you simply cannot write the code the way you would wish to, which presumably might mean that the code you do write is inferior, since you obviously had some reason for wishing to write it another way. Still, in general I think the positives outweight the negatives, and have even argued in the pass that Elm could consider removing some syntax, specifically lambda expressions and if-then-else expressions. Though it must be said I’ve also argued for the inclusion of the odd bit of new syntax. ...

I have remarked before that Elm is pretty frugal when it comes to syntax. Lambda expressions though are a sort of staple of functional languages. For no particularly good reason a language is not seen as functional if it doesn’t have lambda expressions. It’s even possible to see phrases attributing elements of functional programming that have found their way into mainstream imperative languges such as Python, and it often includes lambdas. So lambda expressions are somehow seen as a quintessentially functional feature. ...

Elm is pretty frugal when it comes to syntax. This has many benefits, one oft cited is that it helps beginners get started pretty quickly, in particular after learning the syntax for ten minutes or so a beginner can understand most Elm code out in the wild. I think a more compelling advantage is that the lack of syntax reduces the ways in which the same problem can be solved. It of course doesn’t eliminate this entirely, some people like to use |> and others much prefer <|, or even just to use parentheses. ...

There is an old but excellent post from Joel on Software which defends hungarian notation. Briefly hungarian notation was mis-applied in many places, and so something that wasn’t nearly as useful as hungarian notation was adopted and then (rightly) despised. That post is great and worth reading if you haven’t, but it is also quite long, so I’m going to first of all explain the correct hungarian notation that is useful, then the incorrect despised hungarian notation. Finally, I’m going to end by discussing how the old despised hungarian notation relates to Elm maybes. ...

I want to explain a minor tweak to Elm’s import syntax, that I cannot find justification for. Before that I’ll explain a syntax improvement that I at first thought was a no-brainer, but then came to realise was hard to justify, and certainly not a no-brainer. I’ll end by saying that despite the fact that I cannot find sufficient justification, I still think my minor syntax tweak should be adopted. ...

There was a fairly long thread on the Elm discource regarding a proposal to add extensible custom (union) types to Elm. I thought I would try to summarise a little, the current status. In brief, I think currently the cons outweight the pros, but most of the cons are uncertainty rather than definite disadvantages so it is possible that some further work could tip the balance. I’ll describe here very briefly what an extenible custom type is, and then the pros and cons, why I think the cons outweight the pros at present, and finally a path towards overturning that. ...

Elm famously has excellent error messages, particularly for type errors. When the compiler detects errors in multiple files it outputs a little switch between which looks like this: `This `NeverEditable` value is a: Field.Editable But `withEditable` needs the 1st argument to be: Int Admin.Config.Orders.OrderTotals ↑ ====o======================================================================o==== ↓ Admin.Config.Basic -- TYPE MISMATCH ------------------------------------ src/Admin/Config/Basic.elm Although it’s a little redundant to repeat the filename (technically it’s a module name in the separator but since module names must line up to the filename it’s still redundant), I find this pretty helpful. Just one thing I would change, for the last error message, because you’re not at that point switching between error messages you don’t get a module or filename at the very bottom of the output: ...

Since almost as long as compilers have been around there have been attempts to store source code as something other than plain text. Various different formats have been suggested but the actual format is not important the general idea is to store the abstract syntax tree of your program rather than text that can be parsed into the abstract syntax tree of your program. There are several reasons you might wish to do this, and several disadvantages as well. But I wanted to speak today about one particular part of this. Comments. ...

There was a thread on the Elm discourse regarding the communcation of expectations when contributing to Elm. It’s an interesting thread albeit mostly quite negative, but it’s still useful to hear people’s frustrations and view points. I wanted to focus in on one particular view point that seems pretty common. This is a direct quote from the thread: Thinking this a bit more, this actually sums up clearly the difference between Elm and other open source projects: ...

In Elm comma separated lists (and records and tuples) are traditionally written with the comma on the next line preceding the next item like: elements : List (Html msg) elements = [ title , introduction , mainImage , mainContent , conclusion ] I’m quite used to this style from my Haskell days. Although the comma-at-the-start feels a bit unnatural at first, I think after a while you start to see the benefit of having a nice visual clue which distinguishes a contination of a previous item with the start of a new item. Another benefit in my mind is that it means the items naturally align even though each line has the same indentation. ...

I’ve always indented Elm with four spaces. To my mind this looks nicer than two or eight spaces. It also seems to be about the default, relatively common in code seen in the wild. Recently I’ve found a really good reason to prefer two spaces, but I still cannot quite make myself accept it. I thought I would detail it here anyway. The ‘problem’ with four spaces comes when you want to indent nested comma separated entities. So a list of lists, or a list of record types. Suppose you have a list of people: ...

In Elm it’s possible to import a name from a module in two ways, you can either import the module and expose the name, or import the module, perhaps aliasing the module name, and then qualify the use of the target entity. This seems common in documentation, I’m not sure why it seems to be that having unqualified names “looks better”, and there is certainly a sense in particular for the elm/html library that the resulting code more resembles the HTML that is essentially being described. ...

Elm is famously pretty conservative when it comes to adding language features/syntax. In general I appreciate this, but or-patterns are something I have longed for for a long time. I feel they can drastically increase clarity. However I do understand that a ‘better’ solution may arrive and we will all be glad Elm held off on implementing or-patterns. Still I feel that in this case, it’s worth the risk, or-patterns are used in a few other languages and to good effect. ...

Elm has extensible records, you can write a type like { a | x : Int } which means a record type that has at least a field named x of type Int but may have other fields as well. The general advice seems to be not to use these for data modelling but instead use them to narrow the type of function arguments. See this Richard Feldman talk and, for example, this Charlie Koster blog post. ...

The builder pattern seems to be prettty popular in Elm, here is an elm-radio episode dedicated to it. The builder pattern To be clear, the builder pattern is used where you have a data structure, usually a record, which allows for a reasonable default and can be customised by chaining modifier functions. A simple example is best to describe this. Suppose you have number inputs in your application. You might have some module tasked with rendering a number input, but the number inputs themselves can have various settings, so you have a NumberInputConfig type which controls both the view and update of a number input. ...

I have a small niggle that comes up in my Python programming. I’m going to describe it and propose a possible addition to the Python programming language that would mostly solve the problem. However, I have not thought through this language modification at all thoroughly so at the moment it’s just a germ of an idea. It wouldn’t be a major change or fix any important problem in any case, it would just solve my own personal peeve. ...