A final, short gentle comment..

[spc@gate.net]

On some network somewhere in cyberspace, Francois-Rene Rideau transmitted:
> 
> > Fare>> If you despise technology, I invite you to live naked
> > [rest of diatribe deleted] <<
> > I *love* technology. I *hate* seeing it misapplied. (Pout).
> We may have different ideas about how to apply it or not.
> 
> 
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > Me>> then you presumably have to
> >  create a virtual machine on EACH system that
> >  (a) uses Scheme as its "native" language;
> >  (b) can perform ANY & EVERY O/S task in the context of (a);
> > Fare>>  Of course I'll have to (even if it's not Scheme) anyway.
> > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> > So this is your common level! Please note that there is then
> > no "LLL" subproject. There are a zillion. I hope you can
> > find a zillion "LLL" programmers to write them (and revise them
> > IN CONCERT according to your ever-changing specifications)!
> > I will watch with interest.
> 1) There is not a ONE common level.
> The more people have in common, the more they'll share.
> You just can't ask an Alpha version and a MuP21 version
> to share the same LLL, because they are too different architecture.
> 3-regs RISC cpu implementations will share more together than
> just what they will share with every implementation.
> Perhaps it's hard for you to accept,
> but a heterogeneous world requires heterogeneous solutions.

  You know, it suddenly "clicked".  What you are after, Fare, is a backend
to the HLL.  That's it.  Nothing more and a technology that's been around
for quite come time (even Microsoft was doing this in the mid 80s for all
their languages).

  I would have assumed something like this, had you, Fare, not made such a
big production out of it, making it, in my view, into something so different
that it needed discussion.  It doesn't.  

  Or, at least not to the degree you think it might.

  Or, if the LLL is going to be so different from CPU to CPU, then why even
bother with it?  You might as well go HLL -> assembly and be done with it.


> 2) Yes, of course, the more platforms you'll support,
> the more LLL programmers you'll have to find to support them.

  Then why limit the LLL programmers in the tools required?  Why force the
LLL to be so poor then?

  Personally, I feel you'd (Fare and the other HLL people) be better off
defining the HLL, and maybe implimenting it under an existing system, and
leave the OS portion till you've hashed out what you want in the HLL and the
OS.

  -spc (just my two zorkmids worth)