[erlang-questions] Why do we need modules at all?
Wed May 25 08:07:57 CEST 2011
On Wed, 25 May 2011 14:29:16 +1000, 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,
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
> 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
> fun fib_aux n a b = if n < 2 then a else fib_aux (n-1) (a+b) a
> fun fib n = fib_aux n 1 0
> 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.
> - 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
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
More information about the erlang-questions