<div><br></div><div>If someone had told me in 1981 (when I got a taste of both Prolog and Smalltalk) that, in 2011, we'd still be editing files of code with text editors, with a strong coincidence between "module" and "code-file/header-file pair", I would have been surprised. But here we are. Is it just cultural inertia? Or is it that this way of doing things isn't really broken, just the best compromise in the best of all programming worlds?</div>
<div><br></div><div>By some coincidence, Richard and I are discussing non-contiguous clauses in named functions as something that was nice in Prolog, and would be nice in Erlang. Which would suggest an even finer granularity for the database: as long as you can maintain a (partial) order of clauses for a function, clauses, not functions, might be the minimal units.</div>
<div><br></div><div>I think it's worth looking very closely at how other systems tried to solve the same or similar problems (even decades ago, e.g., Smalltalk and Interlisp-D) and what problems they ran up against, and at what kind of scaffolding would make the architecture of any Erlang solution backward compatible with (most) existing Erlang development. The ideal (probably unachievable) would be that nobody would need to change anything about how they work now, while anybody who wants to take fuller advantage of the system would face no obstacles that were rationalized in the name of backward compatibility. A tall order.</div>
<div><br></div><div>-michael turner </div><div><br></div><div><br><br><div class="gmail_quote">On Wed, May 25, 2011 at 1:29 PM, 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:0 0 0 .8ex;border-left:1px #ccc solid;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>
<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>
<div><div></div><div class="h5"><br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>