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

[Richard O'Keefe]

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

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.