i386 subproject

[Francois-Rene Rideau]

Dear Sean,
   I think you're being unfair.

> 	1. There's already too many people working on the project.
   Well, personally, I'd say that there are *not enough* people
*actually working* on the project (and I don't even count myself as
actually working a lot on it).

> 	2. There is no clear cut decision on anything.  No LLL, no HLL.
   To have a clear cut decision, we need have data on which to base decision.
Next time I take a decision, you'll tell it's arbitrary and I haven't
consulted anyone !
   As for the LLL, I proposed that we took all the standard FORTH computation
words, without parsing and I/O words for which we'd do something else; but
nobody commented. And for the HLL, I've written lots of requirements, and
we've come to the conclusion that a new language should really be designed,
as no existing one could remotely fit our specs.

> And I'm still not sure what higher order reflective lanauges are.  
   *That* is a good objection. I guess I should write some clear
explanation in the TUNES pages.
   Basically, higher-order means that functions, structures, and types
are first-class citizens. Reflective means that the whole system itself can
be abstracted over, that the language can manipulate itself...

> 	3. There are no low level people keeping the high level people
> 	   in check.  The worst thing that happened to TUNES is when Mike
> 	   Prince left.  He was probably the only thing keeping Francois in
> 	   check.
   How that "in check" ? I think we're together to collaborate rather than
fight; of course, anyone is free to have his own point of view on things.
I was the first to be sorry that Mike left; I often disagreed from him,
but I especially appreciated his energy and his leadership. When he left,
I had to take over the project, because no one else would, so it would have
died else. I'm still ready to leave the responsibilities and worries to
others (if they're serious), so I can concentrate on my technical
contribution. Any taker ?
   Moreover, I consider myself as a low-level people, too. I've been hacking
assembly for years (those sweet Apple ][ days...), have always loved low-level
details, and for TUNES alone, I've written the boot stuff and a lot of the
FORTH system already. Of course, low-level is not my *only* concern, and
actually, I believe there are already more than enough people doing low-level
things and not enough doing the high-level things, so I'm focusing on the HLL.


>   I signed up on this list just to keep tabs on what other people are
> working on (never hurts to study).  But my gut feeling (at least with TUNES)
> is that it's never going anywhere.  It's too lofty.
   Well, the project may be lofty, but I've done my best to divide it in
mostly independent subprojects, each being much narrower. But seemingly,
no one is willing to work on a project before somethings run already.
I know I'm very bad at leading people (which is another reason why I never
wanted to take the head of the project), and this sure hasn't made things
better. However, until I find someone to replace me, I'll keep being the
project coordinator, because I'm committed in having it succeed.


>   And I'm sorry, but LISP is high level.
   It sure is higher-level than C. However, by many aspects, LISP is
low-level (please compare to ML, and you'll see). I won't expand on it
now, but see how LISP program use cons cells, etc, as an *explicit encoding*
for higher-level constructs. Here is what I call low-level: making
implementation details explicit.


>>    The constraints are to keep the programming style as high-level and
>> abstract as possible, so that
>> 1) decisions like register layout, threading method, implementation
>>  of the dictionaries, memory allocation, garbage collection, etc, can
>>  be modified, tuned, added later.
> 
>   It's very difficult to design with that amount of potential change in
> mind.  Change the way the registers are used, and you'll end up recompiling
> large amounts of code.  The other things can probably be done in an abstract
> manner, but if it gets too abstract, there's nothing to hold on to.  It's
> all castles in the air.
   Before he could get an idea of what his F21 forth compiler should do,
Jeff Fox wrote twenty versions for it. Why makes you think we could choose
the right calling convention at the first try, without having tried a lot
of different versions ?
   Of course, we'll have to recompile, but that's the most trivial part
of the problem. As for holding things, please tell me what's wrong with
the generic code I've begun to write. All that seems truely feasible to me.
(actually, I already got many ideas about how to improve it, but I'll
do it in HLL rather than m4, if I can).


>>    So, ain't anyone interested ? Ain't the goal and constraints clear enough ?
>> 
>   The goals are too vauge (Really Francois, have you ever considered the
> language DWIM?) and the constraints are almost non-existant.
   Err, what's DWIM ?
   The constraints are quite existant: keeping everything generic, modular,
and extensible is an especially hard constraint, especially being considered
that this low-level coding is done with traditional tools (currently,
the m4 preprocessor generating code for a parametrized assembler) !!!


>   My advice (and this applies to Francois in particular) is to study the
> implimentation of as many OSs as possible, even those you don't think are
> relivent.
> Understand WHY they designed it the way they did and the
> ramnifications of their tradeoffs.
   That's what I've been doing for years. But of course, even then, my
knowledge is very reduced. I'd be glad you point us to any major idea
you could learn, and to warn us from any mistake we may be doing.

>  So far, I've studied MS-DOS, OS/2, CP/M,
> OS-9, AmigaDOS, QNX and Unix.  I understand the tradeoffs made, why they
> were designed.  Does anyone else on this list?
   I know MS-DOS, CP/M and Unix perfectly. I understand QNX, and I don't
know anything about the other two. But I also know perfectly HP28, FORTH,
LISP, ML systems, and happen to know Smalltalk and SELF systems a bit.
Believe it or not, these *also* are kinds of operating systems, even with
much different aspects than traditional ones. TUNES is also a project to
unify those two kinds of system.

--    ,        	                                ,           _ 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/"