The Cathedral and the Bazaar.

[Eric W. Biederman]

>>>>> "Fare" == Fare Rideau <rideau@ens.fr> writes:

>> [I thought lazy was part of the definition of being a hacker]
Fare> One of my mottos is
Fare> "laziness is mother of intelligence; the father is unknown".
Fare> Perhaps if I knew the father, things would be better off...

>> But the Bazaar style approxiamentily says before you really start
>> going public with something, you have a working source base. [...]
>> This is where tunes fails. It never gets as far as a working source
>> base. Considering the amount of traffic I have seen on this list at
>> times, if tunes ever had even a part that was a working source base it
>> should evolve quickly.
>> 
Fare> Well, any existing system could be considered a base:
Fare> RScheme, GUILE, OCaml, CMUCL, some Forth interpreter, some Microkernel, etc.
Fare> The problem is that we do not even have a clear direction, or any
Fare> management. I admit I don't personally even have working self-management.
Fare> We know the immediate start: scratch. We know the far goal: a rich reflective
Fare> system. We have no idea for the way to go, or even the first step.
Fare> I don't dare; I'm inhibited.

I really don't want to commit myself at this point.  My todo list is
already quite long for working on dosemu.  But here are some ideas
anyway.

a) Define reflectivity in laymans terms.

Reflectivity -
  In a large system the ability to define that system from parts that
are already present. 
  Basically a well factored system.  So at any level you can use the
same tools that you rewrite that abstraction layer.   And as much as
possible those tools won't be hidden.

My current practical suggestion is start with an implementation of
R4RS with syntactic macros.  Probably at some point the low level
macro facility should be made to resemble that of forth.  Using
syntactic macros implement a type system.  This would at the minimum
be an experimental test to see possibilities.

The dialect of scheme we develope (perhaps we could call it Notes).
Would hopefully evolve into a language that has all of the
functionality of the HLL.  The syntax of the HLL can come later.

Then using Notes that is essentially made by definiting macros
(Portability being an important early step for a product).  The basic
implementation of the interfaces can be developed, and can be
experimented with. 

After there is some code that actually does most of what we want.
The concentration can be focused into refining that code into a
complete Tunes system.

Also always remember this is a long term project.  So that it won't be
finished any time soon.  The GNU project took 10 years to form a
complete unix system and they had a model to copy.  So for initial
code don't worry about hacks to make it work on slow
machines/inadequate machines.  At least not more than is needed to get
the initial code going.

This is an initial idea.  Doubtless anyone working on it can improve
it.

In defense of my idea:  I suggest R4RS scheme as a base because it
already has everything except for types.  So if those could be added
in R4RS macros.  We would be fine.

And since this is a democracy, all opposed implement something
different.

Eric