[fare-01] MOOSEing again

Francois Rideau rideau@mathp7.jussieu.fr
Tue, 31 May 94 8:42:41 MET DST

(repost for archiving purpose)
[Message number: fare.01]

[1]		  Hello again, you all MOOSE programmers. 
[1.0.1]		We haven't spoken about MOOSE again since July
[1.0.2]		and MOOSE wasn't successfully restarted in September.
[1.1]		  There are reasons why:
[1.1.1]		MOOSE was such a dream OS;
[]	there was no clear goal
[]	and no deadline	to set up this goal or anything.
[1.1.2]		everyone had his own ideas,
[]	but we had no mechanism to take decisions,
[]	so we never knew if our idea was accepted, rejected,
		or subject to some clarification,
[]	and we kept fighting for the same ideas.
[1.1.3]		mail-only communication was too slow.
[1.2]		  I'd like to restart the project, but on saner bases.

[2]		  Thus, 
[2.1]		the goal of the project should be made clear (see [4]).
[2.1.1]		By goal, I mean both
[]	a long term goal (=high-level features of the system),
[]	and a short term goal (=frame for a first implementation).
[2.1.2]		There should be a two-week deadline to set it up definitely.
[2.2]		  Then, we should organize a way to communicate more quickly
		than we	did, and take decisions more efficiently:
[2.2.1]		We should have a database for all the work done, being done,
		or to be done in the system.
[]	The database should be divided in subjects and subsubjects,
		each having its own maintainer.
[]	Each point in the database has its own reference, a reference
		to the message it originates in, to other topics it is
		related	to, to another point that updates it, to points it
		replaces, a flag indicating if it is up to date, a list of
		pros and cons, a list of problems encountered, a reference to
		what is	scheduled about it in the project.
[]	We should ultimately develop our own system to maintain this
		database using MOOSE itself, as a test of MOOSE's efficiency.
[2.2.2]		We should stop redacting messages for just ideas, using some
		codified abbreviations and references to cut the time spent
		typing and not thinking or writing interesting stuff.
[]	All messages should be formatted in an agreed way (for
		example, like this one), to allow easy/automatic retrieval of
[]	standard abbreviations should be a subject in the system, and
		have their own part in the system database and own
[]	all other abbreviations will have to be introduced in the
		beginning of the message.
[2.2.3]		  We should organize a true meeting on a regular basis,
[]	that is at least once per week.
[]	irc (/join #MOOSE) can be a first try;
[]	We can ultimately develop our own software to organize this
		meeting as another proof of MOOSE's efficiency.
[]	For those whose internet connection is firewalled,
		I can provide an unfirewalled rlogin account in France.
		Tell me about it.
[]	Everyone would be meant to have read all the common (mail)
		messages before we begin the meeting;
[]	the meeting would be divided into discussions of limited
		subjects, with an order of the day.
[]	The order of the day is established (and possibly dynamically
		modified) by a president of the meeting.
[]	The above president is arbitrarily chosen on the previous
		meeting, with a list of replacements in case of.
[]	If need be, each subject is itself managed by the subject's
		maintainer with the president being a referee.
[]	At the end of each discussion, we should vote to take any
		decision, report it to later in the meeting after another
		discussion, or report it to a further meeting after new
		information is gathered.
[]	At the end of the meeting, we schedule each one's work until
		the next meeting and agree on deadlines and next meeting's
[]	Each maintainer must update his part of the database to
		reflect what was said during the meeting (the discussion
		would have better been logged, then).
[]	the maintained version of the database is permanently made
		available to all of us by ftp.

[3]		So, what I propose to you:
[3.1]		write me (or write the mailing-list if it still exists) about
		your intentions and suggestions.
[3.1.1]		Even write just to say hello, or say you can't join, or say
		you find me stupid or crazy or anything.
[3.1.2]		Please give your coordinates and tell what system you are
		using since last year, if you like it and such.
[3.2]		On saturday may 7th and/or 14th (or even before, just to try),
		use irc and "/join #MOOSE" to have a first meeting.
[3.3]		Read [4] as a first proposition.

[4]		Here is my personal goal for this system.
[4.1]		The system should include features never gathered in any
		existing system made available, else we'd better switch to
		the system that already gathers those features.
[4.2]		We manipulate objects (or whatever you call them) as a
		universal system-wide abstraction.
[4.2.1]		An object is completely determined by the value some other
		objects called functions or annotations have on them.
[4.2.2]		You can't consider the whole of an object, as the number of
		(virtual) annotations is infinite. So you always consider a
		special ASPECT of the object, which is a finite set of
		annotations: you must know the frontier, the limits of the
[4.2.3]		Until an object's definition has been CLOSED, it may still be
		modified by another object (e.g. the human user);
[]	when it is closed, it may be specialized for efficiency, i.e.
		compiled with more or less "optimizations".
[]	The user interface allows to edit objects according to their
		current structure, but as long as the object's class hasn't
		been closed, you can still modify its structure. This is the
		essence of human interaction: you act on open objects.
[]	You can also reopen (a copy of) an object that has been
		closed for writing, or annotate an object by a compiled
		version of its current value.
[]	By default, the system is open to the human user, thus
[4.2.4]		The system is a dynamic database of such objects.
[]	This database can be shared between several users, each
		having/being a (potentially) different point of view on the
		same objects.
[]	This sharing is simultaneous, which means a multi-* (tasked,
		threaded) system.
[]	That the database implementation is distributed or not does
		not enter these specifications.
[]	You can ask it which objects verify such criterion, that is,
		you can invert the relation
		"C is the value of function A on B"
		in a finite time for the set of considered A and B.
[4.3]		The system should be high level, that is, very abstract.
[4.3.1]		This does not mean that low-level things are banned from the
		system. On the opposite, this means that same high-level
		concepts can have plenty of different low-level realization,
		and not only one as before; efficiency details can be thought
		of afterwards and separately in each particularization.
[4.3.2]		This means the language, as discussed in [4.4], should not
		enforce its own implementation for abstract types, but rather
		let the user implement his own.
[]	Again, this does not mean you will have to write each time
		both the high-level definition and the low-level
		implementation each time you define a new object (as current
		OO languages want you to do), as the language system
		(interpreter/compiler/whatever) can automatically provide one
		for you.
[]	This works by annotating an object by several functionally
		equivalent versions, though not as efficient according to
		the particularization you want to give it. An "equivalence"
		constructor is a very important construct in the language.
		Thus you can equate an object to its implementation in
		several different languages (or many times the same in
		different ways), not all of which may be understandable by
		the version of the system you're working on (e.g. an equate
		of a function in english gives a good documentation, even
		if ununderstandable by any computer system yet).
[]	Of course, such equates can or not be automatically generated
		and/or modified by the language system.
[4.3.3]		The system should not provide a purely high-level language
		interface, but also have precompiled code standards.
[]	For portability of precompiled code, some intermediate
		byte-code would just be great for distribution of code.
[]	Mutual protection of objects from others can be done both
		at run-time and compile time. Removing run-time checking
		is a great factor of speed and space optimization. Thus,
		Running objects without (or with limited) run-time protection
		is an important feature to provide to the loader.
[]	This does not at all mean that we have a source of unsecurity
		in the system, as the compiler ensures that all checks
		removed are checks that prove always ok. This means the
		high-level language to low-level translator (and even the
		annotated low-level) provides full checking (i.e. we really
		have a high-level language, not a low-level hack like "C++").
[]	we stress that [4.3.1] must be understood so that not only the
		implementation language and algorithm, but also the
		abstract-object/implementation-realization correspondance,
		i.e. the calling convention, can change. Thus, proposed
		implementations in libraries/precompiled versions of objects
		will have been optimized internally, and the linker will
		automatically generate the code to call an imported function.
[]	More general than a linker is a code specializer (partial
		evaluator), that also contains the "optimizing" module: it
		takes a generic object and some additional bindings, and
		returns a new version of the object specialized with those
[4.3.4]		My conclusion is that providing a dynamic compiler/linker is
		the true heart of the system.
[]	The traditional service-providing "kernel" is only a (basic,
		necessary) library, a replaceable extension to the system.
[4.4]		The language issue is an important one.
[4.4.1]		I've not found any existing language that allows all such
[]	No language I know, but FORTH which in its standard
		definitions is too low-level, and smalltalk, which I don't
		know well enough, is reflexive enough to allow a self-growing
[4.4.2]		Thus, I think we'll have to write our own language.
[]	Again, the language the system is written is of foremost
		importance about how the system behaves: the semantics of the
		language that interfaces the system limit that of the system
		itself (for instance, Unix' error handling, parallelism and
		self-growingness are very burdensome and difficult to use
		because such things are	unexpressible in a simple way in
[4.4.3]		In any case, we can't write anything less horrible and
		burdensome than Unix if we base on something like "C"
		(or even C++) for our system.
[]	This does not mean we cannot use "C" to write a simple
		implementation of our language in [see 4.5.1], only that "C"
		will not be the standard way to interface the system; different
		implementations may provide different calls for "C" programs.
[4.5]		The target platform for our first implementation should be
		a common one.
[4.5.1]		Currently, this means either use a (more or less) POSIX
		compliant system (such as Linux on PCs or recent Unices on
		any machine, and even NT !) as a base for a MOOSE subsystem,
[4.5.2]		or write the kernel in i386 assembly,
[4.5.3]		or write it for PowerPCs,
[4.5.4]		I think implementing first on another platform would be a
		waste of time.

[5]		I hope to hear from you soon.
[5.1]		Whatever you answer, good luck for you !

--    ,        	                                ,           _ v    ~  ^  --
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
--                                      '                   / .          --
MOOSE project member. OSL developper.                     |   |   /
Dreams about The Universal (Distributed) Database.       --- --- //
Snail mail: 6, rue Augustin Thierry 75019 PARIS FRANCE   /|\ /|\ //
Phone: 033 1 42026735                                    /|\ /|\ /