[erlang-questions] Why we need a -module() attribute?

Loïc Hoguin essen@REDACTED
Thu Feb 25 11:36:22 CET 2016

On 02/25/2016 04:00 AM, Richard A. O'Keefe wrote:
> On 25/02/16 1:53 pm, Loïc Hoguin wrote:
>> A similar but larger pain point that's been rationalized by people
>> used to Erlang is the expression separators.
> I take it you're referring to commas, semicolons, and full stops.


> We have a complete solution to that called LFE.

I largely prefer the Erlang syntax despite its faults, at least for most 
of the code I write.

> We also have Elixir, which has enough syntactic weirdness of its own
> that I decided not to use it.

We agree there.

> I briefly played with a Haskell-inspired syntax for Erlang, which I still
> think would be a good idea.  One thing I certainly kept in that design
> was -module directives because of the good they do.

My problem isn't that the -module directive exists, just that it's 
mandatory. It's good that you are protected from every possible error if 
that's what you want. But it's not good that you are forcefully 
restricted to a particular behavior just because someone somewhere might 
run into issues otherwise. This reminds me of the Unicode 
variable/function names debate, where people argue that they might one 
day run into code that they can't read.

> I wouldn't say that I've *rationalised* the issue, just that I stopped
> falling off that particular bike very very quickly.

I still run into this, mostly when refactoring. When moving code around 
I usually end up with wrong separators. It's often in lists or maps when 
writing one item per line. If I could have an optional comma for the 
last item in the list I wouldn't have to compile, get an error, fix it 
and compile again.

I did rationalize it, "it's like sentences!" and you probably did too. 
If you really never run into issues with them you either never refactor 
code, do tools assisted refactoring or are smarter than everyone else.

> I don't think there is any point in trying to "fix" Erlang syntax as it
> stands.  I *do* think there is point in developing a whole *new*
> self-consistent
> syntax from the ground up, just like D didn't so much fix C's syntax as
> replace it.

I don't think any of the things discussed here break backward 
compatibility, or if they do, not as much as some of the changes OTP 
team already does (some latin1 source files broke in 17 for example).

Loïc Hoguin
Author of The Erlanger Playbook,
A book about software development using Erlang

More information about the erlang-questions mailing list