GEN,LLL+ [far27]

[Francois-Rene Rideau]

 I'd like to regularly post a summary of pros, cons, reqs, etc,
about a standard LLL (or what I began to call a LLL, but I'm sure
you'll soon find a better word/acronym).
 This is the first version of the summary.

 
LLL principle
~~~~~~~~~~~~~
 There is a (family of (slightly hardware dependent ?) ?) standard
coding format for objects, INCLUDING EXECUTABLE CODE in such a way
as trivial programs can be instantly interpreted on any machine,
while more complicated programs are compiled without the
parsing/front end step which is known to be the most limitating,
and with intermediate code optimisation done and info ready for
ultimate back end compiling.

Pros
~~~~
1) Greatly shortens compile time
2) allows quick, easy and efficient portable code&data (=object)
exchange inside a heterogeneous distributed system or between 
remote systems.
3) greatly reduces future compiler design: a new language will
only need a new (or adaptated) front end; tools may be provided
for parsing (an OO lex/yacc equivalent). The back-end part of
compilers will be language independent, only hardware/implementation
dependent.
4) may extend current existing HLLs by including features a OO,
genericity, recursive call to HLL from LLL, etc.


Cons
~~~~
1) Is an important human-time investment (but aren't we Moosers
here to work ? :-)
2) Requires our respecting programming rules (but anyway, it's
inevitable)
3) Needs new compilers (but anyway, a new OS always requires new
compilers, to comply new object code format) (so why not profit
to build also a new HLL ? :-) for its features to be available to
programmers/users (again, I make no clear difference).
4) Compiler editing companies might not appreciate competition
(see Microsoft)
5) if it works, ANSI will have to produce again new papers (but
that also is inevitable, with MOOSE, isn't it ?Think about ANSI
MOOSE ! :-)

Reqs
~~~~
1) We must find a "good" preferably extensible format. A quick
linear conversion with a small memory occupancy is to be considered,
to provide at the same time external portability and internal
efficiency (in/external relative to each host). If we forget
something important, we'll have to produce un-upward-compatible
formats and thus forma converter that will occupy system time and 
space.
2) The standard must provide a quick, efficient, unspacy way of
coding external links: an object will almost always need external
objects to run/evaluate, that shouldn't/couldn't/oughtn't be
included in the object itself; however, when loaded/saved, the
object needs the link not to be forgotten, so as to be properly
restored next time. My opinion is have tables/virtual dictionaries
at module level (that'll be my definition for what Dennis called
modules)
3) As the format includes not only LL executable code, but also
data, etc, it's a full language. The main difference from usual
languages then is the fact that it is a binary format as opposed
to text format. But as text is a particular kind of binary, a
point of view would be that HLL is an LLL subset (as well as
machine language) (actually, if my LLL is extended to a full
object description standard, any object will be coded through it,
so why not HLL source fies in particular ?); thus, there is no
more compilation, but only simplification ("optimisation") and
evaluation, from subsets of objects to others.

Language Policy propositions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1) (Fare')
First have a LLL interpreter in C/C++; then build C/C++ and/or
NewHLL compiler to LLL (and why not NewHLL <-> C/C++ compilers,
understanding extensions of C/C++ through added info inside
comments ?)
2) (?) What else ?

Feel free (=bound 8-) to contribute and correct my poor english and my
mistypes.
   ,
Fare


PS:
- Gary, we can begin coding in C++, including added info in comments.
C/C++ may be only for kernel code. After that, we MUST have our own
compiler, so why stay with C/C++ which creates a programmer vs. user
barrier ?
- Sorry for the long silence. But being far from my usual Sparcstations,
I am bound to use a costly SLOW 1200/75 baud "minitel" terminal through
phone net, and I HATE wordprocessing with it.
- BTW, what about far23, Andreas ? Even if it wasn't a fundamental
message, I'd like to have it in my collectin of all my mail about MOOSE.