axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Axiom-developer] [build-improvements] Requests for discussion


From: root
Subject: Re: [Axiom-developer] [build-improvements] Requests for discussion
Date: Thu, 3 Aug 2006 10:10:31 -0400

> I guess the literate idea even says that it does not matter how a file 
> is called. It is most important that you write a paper from which you 
> can generate all the code (even different files from one pamphlet 
> source). That sounds nice, but in some sense I find that very difficult 
> to maintain. For ALLPROSE I set the convention every file is a .nw file. 

> I suggest to adopt that convention for axiom (replace .nw by .pamphlet).

Ralf,

In fact the system direction is the exact opposite, at least the parts
I touch. C (and, even more egregious, Java) adopt the file-per-function
kinds of idea.

If you look back in history (or lived it as I have), you'll see that the
tiny-file idea is based on computer restrictions. Memory was small and
the compiler couldn't handle large files. Furthermore, the loader couldn't
load large files. So everyone uses small files (or, in my case, short
paper tapes).

You see this legacy everywhere. It is still possible to write memory
overlays in linkers so that when one function completes it can be 
relaced in memory by another link section. This allows a large program
to run in small physical memory. This "feature" is still supported by
the intel chip with segmented memory (which is rarely used but still
causes pain). Limits of storage, compiler technology and imagination 
caused the idea of splitting out header files as a way to expose
signatures. Now we live in header-file hell. "Libraries" were ways
to collect all the little pieces so the linker could connect them
and now we have DLL hell and lib* hell. Indeed we are forced to use
"IDE"s because the tiny files have overwhelmed our ability to cope.

The #line directive is a hack to allow a runtime to figure out which
grain-of-sand-file contains this particular function. It is also a
legacy of history. I am building a program for work that lives in one
literate file, has 30,000 lines of Lisp code, and has 2000+ pages of
final pdf documentation (so far) and 7000 test cases. It is never
ambiguous which file contains the failing function.




Computer programs have nothing to do with their file storage but
we have linked these ideas and suffered for it. Suppose we follow
the past and make Axiom "include" files which separate out the
signature information in a domain or category into separate files.
Then we could add an "include" statement. This way lies madness.

Consider what happens if you scale Axiom by a factor of 100 in
the next 30 years onto a petamachine. You end up with 110,000
domains and categories with roughly 1,100,000 functions. I don't
want 110K files. I want 110 books.



I have a library that must include 20 books on group theory. 
They each have a section on permutation groups. It would be more
"efficient" if there were a standardized "permutation group" booklet
that everyone referenced as "included" into their text. That way there
would be no duplication. But that misses the point of literate works.

The key point is not that I talk about permutation groups but that I
talk about them in a certain way, in a certain place, with a certain
style, for a certain audience. The fact that the information is
available elsewhere means nothing to the human.

And we're trying to write for humans, not for machines.

I want to send you one book that you can just sit and read.
Not read by computer, but sit and read for educational purposes.
And, as a side-effect, you can also compile and run it. The running
program illustrates the ideas in a way that you can build on them.
You can modify them, extend them, write about them, and distribute
them, solve problems with them. You can build on other people's work. 

We need to lift our eyes back to the humans, away from the technology.
Communicate, don't program.

Tim







reply via email to

[Prev in Thread] Current Thread [Next in Thread]