Misc Comments [Re: What is a ``reflective'' system?]

[Dwight Hughes]

| From: Jordan Henderson <jordan@Starbase.NeoSoft.COM>
| 
| Look, don't everyone get defensive about my suggestion of Forth.  It was
| just a suggestion.  While it overlaps quite a bit with Flux, it could
| be complementary and does solve different problems (like how to actually
| write the VM, GC, etc.).  I would prefer to reduce, to as far a degree
| possible, our reliance on C for low level stuff.  My view is that C is
| the enemy here, it's good for low level stuff, but once you rely on it
| there's just SO MUCH SUPPORT for it that it sneeks into your system at
| higher and higher levels.  I'm not religious about NO C, I just feel that
| there's a danger to base it on C that should be recognized.  The danger 
| is that the whole thing will just be another language environment 
| portable to systems with good C compilers where people will still do
| most of their work in C/C++ and just use Lisp as a hobby.

Flux uses C more as a higher level assembler. It uses its own minimized 
C library, not the general gcc libs, and deals with very low level
hardware specific items. When C is dealing directly with hardware it
is using the same types we would have to anyway -- at the lowest
level the hardware dictates what structures and types you must use.
When you then build the structures that process this i/o or that 
represent the hardware in some abstract fashion to higher level
processes then we should avoid C however we can. Remember that Flux
is a *toolkit* -- we can pick and choose whatever we want, and if the
code uses structures or models we don't want, change it. If we must,
drop down to inline assembler. I agree that we will eventually want
as much of the LispOS in Lisp as we can possibly manage, but we also
need to start somewhere.
 
| This is exactly why we need some form of Project Coordination/Steering
| Committee here.  I don't remember there being wide consensus on Flux and
| I've even seen some ambivalence toward CMU-CL.  If people would just form
| teams to research various things, then it would be clear which direction
| we were working.  This would not squelch other ideas.  People who wanted
| to go in different directions would just form their own teams.  It seems 
| like now we are all waiting around for unanimity and then we'll all go 
| off in the same direction.

We have been at this for less than 3 weeks. Many opinions have been stated
before any real research has been done (I am also guilty here). This is
the only real problem I see right now. But it has also been a period
of brainstorming, which requires freedom to turn up possibilities, even if
some of it is utter hooey.

Remember also that this is not a monolithic work (though it has been
discussed as though it were) -- there are many possible levels and what
I want or need for low level micro-kernel work may be very different
from what is needed for high level application or utility work. There
does not need to be "wide consensus" for the use of Flux or some other
approach to developing the micro-kernel -- those who are actually
going to do the work are the ones that need to decide what is best
for them. Similarly at the other levels.

I don't think it is quite time to create a steering committee -- but
I do think we should have a list of the major items in this project and
a show of hands of who is interested in working on which ones, so some
inner coordination can begin.

-- Dwight