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

Robert Virding <>
Sun Mar 6 04:43:41 CET 2016


I have missed this discussion. Some comments though:

- LFE now supports defining multiple modules in one file so you lose the
coupling module name <-> file name. It is sometimes practical but I am not
sure I like.
- I wouldn't like a hierarchical module namespace which couples the module
name to the directory structure.
- I don't think I would like a hierarchical module namespace at all anyway.
I agree with Joe that a name, in this case a module name, should only refer
to one thing and each thing should only have one name. So having aliases as
in Elixir may mean less characters to type but make things more difficult
to understand.
- I honestly don't see the problem with having to declare the name of the
module, even if you only have one module per file.

Robert


On 26 February 2016 at 07:55, Bengt Kleberg <>
wrote:

> Greetings,
>
> It would be sufficient (for me) if Erlang provided dictionaries (name
> spaces) with words (identifiers).
> The modules/atoms/pids/? in one dictionary would have to be allowed to
> look the same as in another, without being the same. And I must be able to
> access them all from my code.
>
> This would be more useful (for me) than having parts of the module name
> taken from the file system.
>
>
> bengt
>
>
> On 02/25/2016 10:31 AM, Joe Armstrong wrote:
>
>> On Wed, Feb 24, 2016 at 10:46 AM, Konstantin Vsochanov <>
>> wrote:
>>
>>> On 2/23/16 01:30 , Richard A. O'Keefe wrote:
>>>
>>>> I do not recall ever seeing -module coming up here before.
>>>> I certainly don't recall a long thread like this one.
>>>>
>>>> Maybe because people who stumble over -module() too shy to write to
>>> erlang mail list?
>>>
>>> #!/bin/sh
>>>> #Usage: edit module
>>>> case "$1" in
>>>>   */*)  echo "Module name may not contain /"   >/dev/stderr; exit 1 ;;
>>>>   -*)   echo "Module name may not start with -">/dev/stderr; exit 1 ;;
>>>>   *\'*) echo "Module name may not contain '"   >/dev/stderr; exit 1 ;;
>>>>   *\\*) echo "Module name may not contain \\"  >/dev/stderr; exit 1 ;;
>>>>   *)    ;;
>>>> esac
>>>> file="$1.erl" # Beware: file system may mangle name!
>>>> if [ ! -e "$file" ]; then
>>>>     date=`date +%Y-%m-%d`
>>>>     case `expr "$1" : '^[a-z][a-zA-Z0-9_]*$'` in
>>>>      0) module="'$1'" ;;
>>>>      *) module="$1"   ;;
>>>>     esac
>>>>     echo "%%% File   : $file"     >"$file"
>>>>     echo "%%% Author : $LOGNAME" >>"$file"
>>>>     echo "%%% Created: $date"    >>"$file"
>>>>     echo "%%% Purpose: "         >>"$file"
>>>>     echo ""                      >>"$file"
>>>>     echo "-module($module)."     >>"$file"
>>>>     echo ""                      >>"$file"
>>>>     echo "-export(["             >>"$file"
>>>>     echo " ])."                  >>"$file"
>>>>     echo ""                      >>"$file"
>>>> fi
>>>> exec ${EDITOR:-emacs} "$file"
>>>>
>>>> So here's how much burden -module adds to this programmer:
>>>> instead of
>>>>   % emacs foobar.erl
>>>> I have to type
>>>>   % edit foobar
>>>>
>>>> Hang on, that's LESS work.
>>>>
>>>> Thank you for the script, I think it will work for me. I personally
>>> don't use emacs, but it doesn't matter.
>>>
>>> Reading all this long thread I must agree, the -module() is not the
>>> worst problem in Erlang.
>>>
>>> Regarding modules, I think the flat space for module names is more
>>> troubling. If you look at almost any Erlang library/application, you can
>>> see, that file names are like
>>>
>>> myapp_file1.erl
>>> myapp_file2.erl
>>> myapp_subsystem1_file1.erl
>>> ...
>>>
>>> So we manually implement hierarchic module system. It's a clear sign,
>>> that something going wrong or is missing.
>>>
>> No - I fundamentally disagree - I think that all module names should be
>> unique
>> ie in a flat name space.
>>
>> Why? It's all about the meanings of words - when I use a word it's
>> meaning should
>> not depend upon context - it would be nice if this were the case.
>>
>> If two people use the same word it should have the same meaning and there
>> should
>> be one place to look up the word.
>>
>> We should agree on the place to lookup the word. So for example, in
>> English
>> I might say all the words I'm going to use are in the Chambers English
>> dictionary.
>>
>> Dictionaries have flat structures - The Second Edition of the  Oxford
>> English Dictionary has 171,476 words, in alphabetical order so it's
>> easy to find them.
>>
>> If all module names are unique then we can put all the modules in one
>> directory
>> so we'll know where to find them - so several very difficult problems go
>> away.
>>
>> This solves all these problems:
>>
>> 1) I know the module name but I can't find it
>>
>> 2) I know the module name but a module with this name is in
>>       dozens of different directories
>>
>> 3) I have a new module and I don't know what directory to store it in
>>
>> Dictionaries are fantastic because we know where to find words - file
>> systems
>> are horrible because we don't know where to find things.
>>
>> I can imagine having different dictionaries, French, German etc - so I can
>> imaging different large collections of modules - which is akin to
>> having a two-level
>> namespace. With rather few top-level names (like dictionaries)
>>
>> If you want to simulate stucture then by all means add underscores to the
>> names
>> this_sub_module is fine '_' has no semantics and is purely a
>> linguistic convention (just like this.sub.module )
>>
>> /Joe
>>
>>
>>
>>
>>
>>
>>
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> 
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>> _______________________________________________
>> erlang-questions mailing list
>> 
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
> _______________________________________________
> erlang-questions mailing list
> 
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160306/4a39e9ad/attachment.html>


More information about the erlang-questions mailing list