[erlang-questions] Why do we need modules at all?

Joe Armstrong <>
Wed May 25 11:09:04 CEST 2011

On Wed, May 25, 2011 at 6:29 AM, Richard O'Keefe <> wrote:

> On 24/05/2011, at 8:06 PM, Joe Armstrong wrote:
> > Why do we need modules at all?
> To hide data types,
> and to provide short names (we can import a function
> and not have to keep on repeating a long long name for it).
> I note, without recommendation either way,
> the existence of
>        local
>           <declarations>
>        in
>           <declarations>
>        end
> in Standard ML, where the second lot of declarations
> defines things visible outside but the first lot
> defines things visible only inside this form.
> > fib(N) ->
> >     fib(N, 1, 0).
> >
> > fib(N, A, B) when N < 2 -> A;
> > fib(N, A, B) -> fib(N-1, A+B, A).
> could be
>    local
>       fun fib_aux n a b = if n < 2 then a else fib_aux (n-1) (a+b) a
>    in
>       fun fib n = fib_aux n 1 0
>    end

How about

    Functions etc.
    Functions etc.

Functions etc is just a regular sequence of function defs macros, records

The use of the words public and private would attract hoards of programmers
to our humble little


> in SML.  I also note that this is NOT something that SML uses instead
> of modules.
> >Does the idea of a module come from the idea that functions have to be
> >
> > stored somewhere, so we store them in a file, and we slurp the
> > file (as a unit) into the system, so the file becomes a module?
> Probably not.  Smalltalk has classes, but the unit of compilation is a
> single method, and the unit of storage is classically a "change set"
> (which may involve any number of classes and methods, and may include
> revisions to existing classes).
> I also note that in the days when Interlisp-D was just that and did
> not include Xerox Common Lisp, you slurped a file (as a unit) into the
> system, but there were no modules.
> There are plenty of languages where a file may contain many modules,
> possibly nested.  (SML, Ada, to name just two.)
> > If all the files were store by themselves in a database would this
> > change things.
> >
> > I am thinking more and more that if would be nice to have *all* functions
> in
> > a key_value database with unique names.
> In Erlang as it stands, a source file is the natural unit of version
> control and documentation.  The idea of coping with a sea of functions
> all being busily revised by hundreds if not thousands of programmers
> acting asynchronously troubles me.
> Haskell has a large package library, and people can update things often,
> and I keep on seeing version issues in the Haskell-café mailing list.
> Can
>  - scope of names
>  - grain of compilation and reloading
>  - version control
>  - documentation
>  - units of (program) storage
> be teased apart?
> Smalltalk seems to suggest that something along these lines might be
> doable.  (Smalltalk methods are version controlled individually.)
> However, Smalltalk documentation, especially internal documentation,
> varies between woeful and dire.
> > When programs are large we need a lot of meta-data to understand them.
> The Xerox slogan:  a program is a data base, not a listing.
> Interlisp-D did not strictly speaking _have_ source files.
> There were files with source code in them, but they were
> randomly accessed data bases.  Thanks to macros, this did
> not work as well as one might hope, but it did work after
> a fashion.
> Hey, maybe this could be a way to get rid of the preprocessor!
> Joe, you've invented one great language, this is crazy enough to
> be the concept for a second one.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110525/05f613a5/attachment.html>

More information about the erlang-questions mailing list