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

Loïc Hoguin <>
Mon Feb 22 02:38:46 CET 2016


On 02/22/2016 01:45 AM, Richard A. O'Keefe wrote:
>> But there's no point in having the source file require the module name
>> directly in the source if the compiler can figure it out (and it can
>> *because we give it* when we ask the compiler to compile files).
>
> Eh?  When we ask the compiler to compile FILES we give FILE names.
> MODULE names look like file names (as long as you close one eye and
> squint with the other) but they are not the same thing.

I don't see how that's going to be any worse than what we currently have.

Today, if we take for example OSX, we have this:

- Create file m.erl containing -module(m).
- erlc m.erl succeeds
- erlc M.erl fails with Module name 'm' does not match file name 'M'

- Create file M.erl containing -module(m).
- erlc m.erl succeeds
- erlc M.erl fails like above

Despite the fact that my filesystem says I have a file M.erl, I can 
compile it just fine if I tell erlc it's "m.erl" instead.

If we didn't have the -module line because it became optional, we could 
have the module name taken from the file name we give to erlc.

- If you run "erlc my_module.erl" it should create the module my_module.
- If you run "erlc MY_module.erl" it should create the module MY_module.

In both cases, what you see on the disk and the module name can appear 
different. It's no better or worse than what we currently have.

One could argue that currently if you do "erlc MY_module.erl" you get an 
error right away (as opposed to "my_module" being not found later on if 
module name was taken from file name). I believe this is largely a 
non-issue. I have yet to hear from anyone trying to name their files 
with uppercase characters and ending up with the module name not 
matching. And despite this being the hundredth time -module has been 
brought up, I don't recall seeing anyone come and say they ran into this 
problem. On the other hand I recall seeing this topic many times because 
people feel this attribute shouldn't be mandatory.

Concerns about encodings/charsets are also unfounded. We have the same 
problem in both cases, except in the current situation we take the file 
name and compare it to the declared module name, and for optional 
-module attribute you take the file name and use it as the module name. 
If you can do the first you can do the second.

If you compile from forms, then the module name should of course remain 
mandatory. It's only when compiling from files that it could be 
optional. And there's no technical barriers to prevent it.

Regardless of the technical merits of one or the other solution, when 
developing software it's generally a good idea to listen to what you 
users want, and this Nth topic about -module should be a clear 
indication that the current situation is not what many users want.

It doesn't matter if you think you are technically correct, because you 
defend a point of view that many people do not care about. All solutions 
have their strong and weak points, and enough people are annoyed by the 
current solution's weak points (the mandatory -module attribute) to 
create topics every couple months. People tend to want different things, 
so when so many people agree on something it's time to take notice. This 
happens a lot less than you'd think.

In general it's also a good idea to remove as many steps as possible to 
get code up and running, if only to give the illusion of Erlang being a 
productive language, as this attracts newcomers much more easily. Erlang 
is the most productive language I've seen (in large parts due to 
readability and low maintenance) but it's doing a terrible job showing it.

We often say Erlang makes hard things easy and easy things hard. Perhaps 
it's time to seriously consider making easy things easier. This is the 
best way to get more people in. But I get the feeling not everyone wants 
that, considering how little effort is spent on that end (maps happened, 
but it seemed more like a miracle than anything).

-- 
Loïc Hoguin
http://ninenines.eu
Author of The Erlanger Playbook,
A book about software development using Erlang


More information about the erlang-questions mailing list