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

[Edmond Begumisa]

On Wed, 25 May 2011 14:29:16 +1000, Richard O'Keefe <ok@REDACTED>
wrote:

> On 24/05/2011, at 8:06 PM, Joe Armstrong wrote:
>
>> Why do we need modules at all?
>
> To hide data types,

What are the possible ways of dealing with this? When you break modules up
into individual functions?

I presume such a system would therefore need a way of importing types
(complete with versioning) in addition to functions. Which would then
introduce additional complexity for the programmer than just importing a
whole module (the C header-file mess). Maybe the proposed system could
support both -- modules and individual functions?

- Edmond -

> 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.
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/