On Erlang's Syntax

Note that while I generally like the Erlang syntax, there's one main issue where syntax quirks come back to bite me: the combination of Erlang records with a missed line ending. This topic comes up on occasion on the mailing list and apparently it's a side effect of a change that was made to make Erlang records a little easier to work with.

In short, if you've got two records in a list, and forget to end the first one with the comma line ending, the behavior becomes a bit unpredictable.

  [
   #myrecord{
    field1="whatever",
    field2=123
   }
   #myrecord{
    field1="booyah",
    field3=3.14
   }
  ].

That statement would mysteriously return a list with a single element:

  [ #myrecord{field1="booyah", field2=123, field3=3.14 } ]

And all because of the missed comma after the first #myrecord { }.

What's happening can be visualized by the (sort of) equivalent version here:

  R1 = #myrecord{
   field1="whatever",
   field2=123
  },
  [
   R1
   #myrecord{
    field1="booyah",
    field2=3.14
   }
  ].
   

So you can see that the second #myrecord is overwriting the values in R1, since you can do syntax like R1#myrecord{ ... } to take the values of R1, and overwrite them with whatever you need to.

The reason that happens is due to a compiler change a while back to make record syntax no longer require being wrapped in parens. This is due to having records with values in them being records, and it makes it easier to access those records.

For example:

  Mybook#book.author#author.name

Which is an OOP language's equivalent of something like:

  Mybook.author.name

This previously used to be required to be written like this (correct me if I'm wrong, this syntax is before my time):

  ((Mybook#book.author)#author.name).

Which removed ambiguity. Errors like my first example then would be caught by the runtime if records were written in the "old" style:

  [
   (#myrecord{
    field1="whatever",
    field2=123
   })
   (#myrecord{
    field1="booyah",
    field3=3.14
   })
  ].

Will generate an invalid function error (still not a great error, but it makes sense in this regard.

My hope is that this class of error caused by the syntax will be somewhat minimized if Ericcson decides to merge the erlson[1] project into an official release of Erlang, replacing the somewhat clunky record syntax with something a little more "modern".

[1] https://github.com/alavrik/erlson - An object notation for Erlang, but which in order to be a decent record replacement will need to support pattern matching.

I used to dislike the use of different punctuation characters as they make it "difficult" to re-arrange code. I've, however, grown to love them as they are very explicit and gives the reader a good indication on what will happen next (f. ex. an alternate function clause).

All in all, I pretty much love Erlang's syntax. It's the perfect mix of readability, terseness and structure; and it has that cozy nerd-air about it, the one that makes you want to sit up all night dishing out code.

Coming from Ruby, I was pretty excited to see Elixir[0] (and before that, Reia[1]), a language that runs on the Erlang VM but is more approachable for me syntactically and that adds some interesting features. I think it's worth checking out for anyone who wants to 'learn them some Erlang' over winter break.

[0]: https://github.com/josevalim/elixir

[1]: http://reia-lang.org/ (abandoned; author points user to Elixir now)

tldr - The user simply reads , as 'and', ; as 'or' and . as being done.

Learn Prolog first and it will all make sense.

I up'd this just because 1) I love me some Erlang 'Learn you some Erlang' and 2) I love to see Erlang entries on HN

most of it is beautiful <3