i386 subproject

[Francois-Rene Rideau]

>>> 	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 !
> 
>   Not if you give some form of rational behind the decision, even if the
> rational is "Well, we NEED something!".  But I guess it depends upon your
> view if a bad decision is better than no decision, or vice-versa.  I've seen
> quite a bit of talk, but no real head way, but if that is not the case, I
> stand corrected and will appologize.
   This indeed is the feeling the mailing-list may give. Actually, on the
other projects I've participated (not as a coordinator), that was the case,
because even when good or bad ideas were proposed, there was no way to
remember it for sure. These projects had no "memory". Our WWW site is our
memory (not a very good one, for sure, but if I wasn't the only one to
write it...). Have you consulted them ?


>   FORTH is not a bad language for the LLL.  There are some problems with it,
> mostly due to stack noise (DUPs, ROTs, ROLLs, PICKs etc) and the rather
> clumsy vocabulary paradigm.
   Yes I fully agree. Stack noise can be removed by using high-level
extensions to FORTH. The clumsy vocabulary hack should not even be
included, but perhaps as an optional "compatibility feature" . Actually,
different FORTH systems, because they use differently organized vocabularies,
cannot run the same programs; so even then, compatibility is low.


>   Don't get me worng.  I'm crazy about Forth, but I don't like Forth. Or, I
> like the idea, but not the implimentations so far.
   It's the same for me.

>  I did create my own
> Forth like language called VIth (pronounced "sixth") that, IMHO, had a
> better way of dealing with vocabularies, and it did have overloading ('+'
> for instance, can add two integers, floats, or strings) but it's not perfect
> either (you can't add an int and a float without an explicit conversion of
> the mismatching type to the other type, and the overloading is clumsy in
> certain reguards).
   I'd like to know more about it. But beware ! With such languages, there
is the risk of having some system neither low-level, nor high-level, but
in-between (like LISP). My wish is to have a system *both* high-level and
low-level, not neither one (that is, being able to do completely abstract
things, and being able to map abstractions to completely low-level bitwise
implementations if one likes).


>   As to your HLL, I'm not even sure it's possible.  At least some of the
> requirements seem theorectically impossible (and I'll be responding to this
> later when I find the references I need).
   My opinion is it is possible. Of course, I'll have to prove it. But up
to now, I've not received objections I could not solve. Your feedback is
welcome !


>>> 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...
>> 
>   I'm not exactly sure what first-class means.  I can take a stab in that
> arrays in C are not first-class (as an example).  If that's the case, then I
> understand what you are talking about.  If not, you'll need to define
> first-class (it probably wouldn't be a bad idea anyway).  
   Yes, arrays are not first-class in C. Not even structures are completely
first-class (can't return structure). Yes, I'll have to expand on it soon.


>   There are some gaps in my knowledge here.  I tend not to trust the
> theorectical side of CompSci that much.  Too much hand waving (not to
> mention a prof at the university I attend who specialty is "Software
> Engineering" but hates programming).
   Don't let such people make you think computer science is lame. Things
and people who do them can be different: stupid people can participate in
great things (without great result), and great people in stupid things
(with horrible results).


>>    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.
>> 
>   But my impression of you is not as a LL type of guy.  Then again, that's
> me.  I tend to be pragmatic myself.  Theory is nice, but the Real World (TM)
> often gets in the way of a nice theory.
   I don't have this approach to theory: theory is not completely abstract,
but talks about the world. I am not proponent of theorizing without realizing
(though I am not prononent to ban or discourage people who do, unless I have
a very good and sure both theoretical and practical reason).
   I've not been developping my HLL concepts out of nowhere to nowhere.
I've begun with my real-life coding, and I've thought a lot about how I'd
like it to be; I've found lots of real-life objections to my wishes, which
I integrated as constraints; I don't think I've neglected real-life
constraints. To me, the best way to write low-level programs is to use some
low-level mappings for a truely abstract HLL; those mappings would
eventually come with HL specifications, so the HL system could eventually
help the user manipulate it and optimize it beyond anything that can be done
today either manually or automatically.


>>    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.
>> 
>   The key is to find a few (and by that, I mean two or three) people that
> will actually DO something.  And fight out the details.  And be willing to
> compromise. A project I'm working on has only three people, and just
> between the three of us, we've gotten quite far (although the amount of mail
> we generated doing so has already exceeded 1M).
   I fully agree. Two or three are a good number of people to bootstrap the
project. Are there two or three people ready to be those three here ?


>>>   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.
>>
>   Cons cells?  LISP?  LISP - everything is a list.  Code.  Data.  How a list
> is implimented is left up to the implimentation.  Certainly there are
> classical methods for storing lists in LISP (Forth has a similar problem in
> that a particular implimentation became the de facto standard and hampered
> advancements of that language for years), but that still doesn't make LISP
> low level.
   LISP is a low-level language for an abstract machine that is not
the model followed by current CPU designers. FORTH too. Because there
is no standard efficient way to get abstracted from the underlying
machine in those languages, actual FORTH and LISP programs do follow that
model, which make an (unadapted as of LISP) low-level language of these.



>>>>    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 ?
[actually, I think it's forty compilers instead than twenty]
> 
>   I think you made my point.  How can you know what's best if you don't get
> your hands dirty and impliment something?  VIth went through four previous
> versions (right now, the latest version is 3) and I'm working on a fifth
> implimentation (or 12th or something.  I know I started v3 several times and
> v4 several times as well).
> 
>   I would plan to throw away the first implimentation anyway and start over
> from scratch.
   Did I say nothing should be implemented before the specs are finished ?
I just always said the opposite: "DO NOT WAIT FOR THE SPECS TO BE FINISHED
TO EXPERIMENT, EVEN THOUGH IT'S HARD WORK". Because it's the only way to
have working specs. I've not been listened. But I've begun to do it:
I've written some generic implementation for FORTH in asm, that can be
mapped to various CPUs and calling conventions - so we can later "tune" the
implementation when we have programs to benchmark it.
   Also, I'm calling other people to begin write applications for the LLL and
HLL. Let's write the programs first. The language will be created with the
programs as a basis.


>>    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) !!!
>> 
>   Generic, modular and extensible.  Okay.  They're pretty broad constraints
> though.  And personally, I'm not a real fan of genericity.  I do apply it,
> but not everywhere.  The real trick is to find out how generic it needs to
> be and leave it at that.  Too generic and you may suffer performance
> problems or induce more bugs (as there are more cases to test - I'm a real
> nut when it comes to reliability).  It is a tough call sometimes.
>
> (This isn't to say I'm totally against genericity, just blatant genericity
> just to say "My code is generic!"  There has to be a good justification I
> feel).
   To me the trick is: write generic code, but be able to map specialized
instances to very low-level stuff. Existing languages don't allow me to do
that, but as a hack, which I do.



>[about AmigaDOS...]
   I have been told a lot of good about AmigaDOS. I think what it lacks
is security. It was not a hard constraint for single-user computers like
the Amiga where the user is also the superuser and responsible for installed
modules to work, and is always here when the user complains. But it *is* a
big constraint for TUNES, as we aim distributed multi-* computing. And
Amiga modules are not as fine grained and generic as should be, either
(which would also require more security).


>   -spc (Although if QNX dropped the POSIX support, it may be the best
> 	OS design I've seen as well ... )
   It may, but I'm convinced that micro-kernel-based message passing is
pure overhead, that could be removed in a better 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/"