From M4 to Scheme (was Re: M4)

> How will our Scheme implementation relate to the LLL and the HLL ?
   After some thought, I think that we should do in Scheme what
I ended up trying to do in m4 (with lot of pain):
writing an interpreter for a subset of some representation for the HLL,
in which a compiler for the LLL will be written, as well as a compiler
for an extension of this representation as implemented over the LLL.

That is:
* we take a semantic subset of the HLL
* we define a approximate representation of it into Scheme
* we program a LLL compiler using the subset,
  that we code using this representation
* we gradually extend the LLL compiler
  so as to implement the subset of the HLL,
  plus essential Tunes feature not found in Scheme.
* we finally leap into a bootstrapped system,
  as the compiled system is satisfactorily powerful


> Remember I'm the one which was wondering why we needed a LLL.
> I'm not exactly clear on what we'll do with that LLL.
   As I said previously, all that relates to migration require a new
LLL to be defined, which can't be made *efficiently* on top of a HLL
(expect several orders of magnitude of inefficiency loss for a Scheme-based
implementation over raw assembly).
   For instance, real-time, open-implemented GC, distribution, persistency
all require low-level protocols and low-level memory management. A LLL is
required. Sure we could do assembly directly, but except where performance
is especially needed, a portable LLL is better (at least at first).


> Are we going to build
> the HLL from there (in the LLL) by adding complex stuff ?
> We'll already have written complex constructs in Scheme.
   Scheme is too low-level to be our HLL:
it lacks an expressive type system,
has unclean reflection, though with hygienic macros and quasi-quoting).
   It is too high-level to be an efficient LLL:
it hides too much of implementation (notably as of memory access and
number encoding) to allow both access to hardware and migration of high-level
scheme constructs.
   However, some improper dialect of Scheme
could layer between the HLL and LLL.


> Will we continue
> doing so and implement Scheme in the LLL or will we port the complex
> stuff we've done to the LLL ?
   Depending on the development of the HLL at the point such implementation
is made possible, it may or not be useful to implement Scheme over the LLL.



> Here's what I think we need :

>[Long speech]
   Very good plan.
I'm not sure whether we should or not use Scheme directly,
or first implement a subset of the HLL over Scheme, that'd
do everything from then on.


> So ? Any questions ? (Dis)agreement ?
Always the aforementioned stuff.
If all of Tunes could be efficiently done entirely over an existing HLL,
it would be pointless as an OS.


> We have to be sure about the long term plan to decide what to do now
> or we risk wasting more of our critically scarce resource :
> programmer-time.
Ditto.


>>    Tunes/i386 can boot from bare floppy,
> I hadn't thought about that. Good.
>> or from Linux tools (like LILO, or LOADLIN from the DOS command prompt).
> But then I assume Linux dies once it gives control of everything to Tunes ?
   Linux allows one to "reboot" cleanly, which is required as it is not a
persistent OS. Once the machine is booting again, the floppy boot sector,
LILO, or DOS then LOADLIN can launch Tunes.

> OS/2 would rather kill the application than die. I assume Linux's
> brain was tweaked to make sure it doesn't mind commiting suicide on
> request from an application :)
See above.

>> Does OS/2 have mmap() ?
> Never heard of it. I don't think so.
> 
>> If it does, where can I safely mmap() inside (or outside) the 1GB-3GB area ?
> Why do you need acess to the physical address ?
   I'd like to control the *logical* address,
because many hackish optimizations can be done
if some tagging is achieved as bit patterns in values,
instead of e.g. arithmetical comparisons.
Of course, slower, more portable versions must be provided, too.
But a unified encoding could make Tunes memory images a good representation
for persistent data among different versions of Tunes on the same machine
but different underlying environements.


>>    Let's learn the lessons from that m4 trial,
>> and abstract as much as we can our implementation
>> from the underlying Scheme system.
> 
> Do you mean write code that would be easily moved from Scheme
> to another language ?
Precisely, unless you can show that Scheme fulfills the requirements for
our HLL.


> I hope no one is horrified by parenthetic languages. I prefer a nice
> syntax but I think we have much to gain by living without one for a while.
   I get bored by parentheses quickly,
because they lack human-wise useful redundancy.
But what you lose in human readability,
you gain (with Scheme) in very nice and simple semantics,
which are absent from brain-damaged languages we have to use everywhere else
(like C, m4, sh, tcl) !

--    ,        	                                ,           _ v    ~  ^  --
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
--                                      '                   / .          --
Join the TUNES project for a computing system based on computing freedom !
		   TUNES is a Useful, Not Expedient System
WWW page at URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"