LLL weekly [far32]

[Michael David WINIKOFF]

> about a standard LLL (or what I began to call a LLL, but I'm sure
> you'll soon find a better word/acronym).

L^3? :-)

> 
> Pros
> ~~~~
> 1) Greatly shortens compile time

Not the compiles that developers do since they are working of the source 
anyway.


> 2) allows quick, easy and efficient portable code&data (=object)
> exchange inside a heterogeneous distributed system or between 
> remote systems.

We're not here to develop a distributed OS.

> 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.

One can have a back end language without having the OS responsible for
compiling LLL.

> 4) may extend current existing HLLs by including features a OO,
> genericity, recursive call to HLL from LLL, etc.
> 5) may be compact _efficient_ (_standard_) interpreted code for HL
> tasks, sometimes quicker than hand-written assembly, while much more
> portable (don't you know most adventure games use their own
> interpreter ?)

That's because adventure games don't have to be fast.

> 6) Is simple enough to be used as back-end by anyone willing to
> compile his own expressions (see spreadsheets, function graph
> drawers, etc)

It's simpler to write an interpreter rather then compiling to LLl.
Even if LLL is simple.

> 
> Cons
> ~~~~
> 1) Is an important human-time investment (but aren't we Moosers
> here to work ? :-)

Not any more then we have to -- besides we've got plenty to do as it is.

> 2) Requires our respecting programming rules (but anyway, it's
> inevitable)

Huh?

> 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).

Nope. 
We can simply have a utility to translate from (EG) MS-DOS object code 
format to our object code format.

> 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 ! :-)

NO!
Standards
(1) Happen after the system has become both popular and many versioned.
(2) Prohibit progress by freazing the system as is.


Michael 
winikoff@cs.mu.oz.au