<br><br><div class="gmail_quote">On Wed, May 25, 2011 at 6:29 AM, Richard O'Keefe <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz">ok@cs.otago.ac.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On 24/05/2011, at 8:06 PM, Joe Armstrong wrote:<br>
<br>
> Why do we need modules at all?<br>
<br>
</div>To hide data types,<br>
and to provide short names (we can import a function<br>
and not have to keep on repeating a long long name for it).<br>
<br>
I note, without recommendation either way,<br>
the existence of<br>
<br>
local<br>
<declarations><br>
in<br>
<declarations><br>
end<br>
<br>
in Standard ML, where the second lot of declarations<br>
defines things visible outside but the first lot<br>
defines things visible only inside this form.<br>
<div class="im"><br>
> fib(N) -><br>
> fib(N, 1, 0).<br>
><br>
> fib(N, A, B) when N < 2 -> A;<br>
> fib(N, A, B) -> fib(N-1, A+B, A).<br>
<br>
</div>could be<br>
<br>
local<br>
fun fib_aux n a b = if n < 2 then a else fib_aux (n-1) (a+b) a<br>
in<br>
fun fib n = fib_aux n 1 0<br>
end<br></blockquote><div><br>How about<br><br>public<br> Functions etc.<br>private<br> Functions etc.<br>end.<br><br>Functions etc is just a regular sequence of function defs macros, records etc.<br><br>The use of the words public and private would attract hoards of programmers to our humble little<br>
language...<br><br>/Joe<br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
in SML. I also note that this is NOT something that SML uses instead<br>
of modules.<br>
<div class="im"><br>
>Does the idea of a module come from the idea that functions have to be<br>
><br>
> stored somewhere, so we store them in a file, and we slurp the<br>
> file (as a unit) into the system, so the file becomes a module?<br>
<br>
</div>Probably not. Smalltalk has classes, but the unit of compilation is a<br>
single method, and the unit of storage is classically a "change set"<br>
(which may involve any number of classes and methods, and may include<br>
revisions to existing classes).<br>
<br>
I also note that in the days when Interlisp-D was just that and did<br>
not include Xerox Common Lisp, you slurped a file (as a unit) into the<br>
system, but there were no modules.<br>
<br>
There are plenty of languages where a file may contain many modules,<br>
possibly nested. (SML, Ada, to name just two.)<br>
<div class="im"><br>
> If all the files were store by themselves in a database would this<br>
> change things.<br>
><br>
> I am thinking more and more that if would be nice to have *all* functions in<br>
> a key_value database with unique names.<br>
<br>
</div>In Erlang as it stands, a source file is the natural unit of version<br>
control and documentation. The idea of coping with a sea of functions<br>
all being busily revised by hundreds if not thousands of programmers<br>
acting asynchronously troubles me.<br>
<br>
Haskell has a large package library, and people can update things often,<br>
and I keep on seeing version issues in the Haskell-café mailing list.<br>
<br>
Can<br>
- scope of names<br>
- grain of compilation and reloading<br>
- version control<br>
- documentation<br>
- units of (program) storage<br>
be teased apart?<br>
<br>
Smalltalk seems to suggest that something along these lines might be<br>
doable. (Smalltalk methods are version controlled individually.)<br>
However, Smalltalk documentation, especially internal documentation,<br>
varies between woeful and dire.<br>
<div class="im"><br>
<br>
> When programs are large we need a lot of meta-data to understand them.<br>
<br>
</div>The Xerox slogan: a program is a data base, not a listing.<br>
Interlisp-D did not strictly speaking _have_ source files.<br>
There were files with source code in them, but they were<br>
randomly accessed data bases. Thanks to macros, this did<br>
not work as well as one might hope, but it did work after<br>
a fashion.<br>
<br>
Hey, maybe this could be a way to get rid of the preprocessor!<br>
<br>
Joe, you've invented one great language, this is crazy enough to<br>
be the concept for a second one.<br>
<br>
</blockquote></div><br>