[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;
[1.1.1.1] there was no clear goal
[1.1.1.2] and no deadline to set up this goal or anything.
[1.1.2] everyone had his own ideas,
[1.1.2.1] but we had no mechanism to take decisions,
[1.1.2.2] so we never knew if our idea was accepted, rejected,
or subject to some clarification,
[1.1.2.3] 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
[2.1.1.1] a long term goal (=high-level features of the system),
[2.1.1.2] 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.
[2.2.1.1] The database should be divided in subjects and subsubjects,
each having its own maintainer.
[2.2.1.2] 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.
[2.2.1.3] 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.
[2.2.2.1] All messages should be formatted in an agreed way (for
example, like this one), to allow easy/automatic retrieval of
references.
[2.2.2.2] standard abbreviations should be a subject in the system, and
have their own part in the system database and own
maintainer.
[2.2.2.3] 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,
[2.2.3.1] that is at least once per week.
[2.2.3.2] irc (/join #MOOSE) can be a first try;
[2.2.3.3] We can ultimately develop our own software to organize this
meeting as another proof of MOOSE's efficiency.
[2.2.3.4] For those whose internet connection is firewalled,
I can provide an unfirewalled rlogin account in France.
Tell me about it.
[2.2.3.5] Everyone would be meant to have read all the common (mail)
messages before we begin the meeting;
[2.2.3.6] the meeting would be divided into discussions of limited
subjects, with an order of the day.
[2.2.3.7] The order of the day is established (and possibly dynamically
modified) by a president of the meeting.
[2.2.3.7] The above president is arbitrarily chosen on the previous
meeting, with a list of replacements in case of.
[2.2.3.8] If need be, each subject is itself managed by the subject's
maintainer with the president being a referee.
[2.2.3.9] 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.
[2.2.3.10] At the end of the meeting, we schedule each one's work until
the next meeting and agree on deadlines and next meeting's
president.
[2.2.3.11] 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).
[2.2.3.12] 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
object.
[4.2.3] Until an object's definition has been CLOSED, it may still be
modified by another object (e.g. the human user);
[4.2.3.1] when it is closed, it may be specialized for efficiency, i.e.
compiled with more or less "optimizations".
[4.2.3.2] 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.
[4.2.3.3] 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.
[4.2.3.4] By default, the system is open to the human user, thus
self-growing.
[4.2.4] The system is a dynamic database of such objects.
[4.2.4.1] This database can be shared between several users, each
having/being a (potentially) different point of view on the
same objects.
[4.2.4.2] This sharing is simultaneous, which means a multi-* (tasked,
threaded) system.
[4.2.4.3] That the database implementation is distributed or not does
not enter these specifications.
[4.2.4.4] 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.
[4.3.2.1] 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.
[4.3.2.2] 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).
[4.3.2.3] 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.
[4.3.3.1] For portability of precompiled code, some intermediate
byte-code would just be great for distribution of code.
[4.3.3.2] 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.
[4.3.3.2.1] 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++").
[4.3.3.3] 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.
[4.3.3.4] 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
bindings.
[4.3.4] My conclusion is that providing a dynamic compiler/linker is
the true heart of the system.
[4.3.4.1] 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
abstractions.
[4.4.1.1] 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
system.
[4.4.2] Thus, I think we'll have to write our own language.
[4.4.2.1] 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
"C").
[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.
[4.4.3.1] 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 !
[signature]
-- , , _ 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 /|\ /|\ /