MOOSE [fare.02]

[Francois Rideau]

[Message number: fare.02]

------------------------------------------------------------------------------
[Summary of sections]
Each section can be saved as a separate document.

- Reply to Michael's last long message:
- MOOSE Administration:		How to organize work.
- MOOSE People:			Who is currently on MOOSE.
- MOOSE Howto:			How to currently participate in MOOSE.
- MOOSE ToDo:			A ToDo list for MOOSE.
- MOOSE Glossary:		subjects, maintaining.
- MOOSE Specificating tools:	This file format; the language to use.
- MOOSE pre-Specifications:	MOOSE software/hardware requirements.
- MOOSE Manifesto:		A first draft.


------------------------------------------------------------------------------
[Reply to Michael's last long message]
Foreword:
 I have not found any divergence of opinion from Michael's letter.
I'm just answering some questions. I've cut, pasted and modified some of his
letter in the other sections.

> (1)
> Re irc, (a) I can't make the 7th (I'm on a camp) but can make the 14th.
 An administrative problem (account suspended !) forbid me to 
 connect on the 14th. But I'll be there again on the 21th.

> 	  (b) How does one irc?
see section [MOSE Howto].


> I would prefer to have the questionthe other way around -- are there 
> existing systems that we can build on?
> (see section (3)XXX)
see section [MOOSE pre-Specifications]

>> [4.3.3.2.1]
>> (compile-time security can allow limited run-time checking, and require
>>  volontary checking from the user code)
> If you want to be able to run C programs (which is a useful thing to be able
> to do as there's a lot of useful software (eg. TeX, numerous programming
> languages) in C) you have to provide some form of hardware protection.
see section [MOOSE pre-Specifications]

> -------------------------

> (2) Organisation matters
> 
> 	* What happenned to the replies to Dennis' original post?
> 		(the ``what would you put in a dream OS?'')

I kept all the messages I got in a >1 MB text file.
I will make it available by anonymous ftp at frmap711.mathp7.jussieu.fr:
pub/moose, or at least in ~rideau/pub/moose for account ftp. I'll then
add you to my .rhost (tell me your addresses).

> 	* We should put another call for people on comp.os.whatever
Yes, as soon as possible. But I think we should first write some kind of
manifesto.

> 	* Communication *is* our weakness -- unfortunately mails
> 		aren't effective -- long messages are hard to read
> 		and short messages don't explain well.
> 		I don't know how well irc/talk will help.
> 		One possibility is making use of documents -- when you want
> 		to propose something write a document (and mail the 
> 		postscript) that explains it well with examples.
  Yeah.
  What we'd need is some tool to edit documents as a database (most of the
time, documents can be decomposed into smaller parts). Editing may be
done both remotely (=large transactions) or with a real-time server (you
can then see each other's modifications in real-time, which is better than
talking). Maybe this should be our first application project.
  As for what we can currently do, I still propose subjects and maintainers
with 

> 	* The role of prototyping --
  I think it's time an entire OS be programmed with complete
high-level specifications _AND_ proof it complies exactly the specs. This
is the idea of many new "formal programming" tools.
  At work, I'm working on "B", such a commercial language, but it somehow
sucks (even if full of darn good ideas) and will be very expensive; There's
also Coq, the prover for CAML, but if very powerful, it seems too
lambda-calculus oriented (no clean support of side-effects); other
Lisp-based provers seem not much different from Coq, and heavier due to Lisp
semantics (just the same as Lisp seen from CAML).
  The idea behind those languages are that you write your programs in such
a way that writing it is at the same time proving that it matches its
specification. Your enter the program and/or the specification, and the
environment produces and/or verifies the proof, or finds a counter-example
for your program (or may even hang indefinitely and/or give up).
  I think if we're using an existing language, it must allow in an internal
way at least a back door to proving its specification, and if possible
integrate this idea deeply. Object orientedness (that unfortunately CAML
lacks), is what allows orthogonal proving of things of orthogonal concerns.
I know of no free OO language that includes proofs in its scope.
  If we're on for a new language, we must at least prepare for such things.
  See the (draft) Manifesto.


> 	* As Fare says, we should maintain a history of our work and 
> 		design decisions.
See section [MOOSE Administration] about subjects and maintainers.

> (2.1) Reuse
> 
> 	Why are we writing an OS from scratch?
> 	If it is possible we could save a lot of time by taking an existing
> 	OS as a basis.
Agreed.

> 	One option that may or may not be possible is to provide objects
> 	by adding a library or a server to an existing OS.
> 	Another option is to get source code for a curent free OS and use 
> 	that as a starting point -- if nothing else we save having to 
> 	write low level device drivers (boring stuff)
Both options should be studied. I don't think we can decide before we have
gathered troops, and all have seen the proposed basis.
But I think in both cases will be the problem of the flat,
unprotected memory model offered by C. See section [MOOSE Specificating tools]
paragraph [MOOSE and "C"] about it.


> 	BTW, have people heard of VSTa? It's a copylefted microkernel that's
> 	small and runs on 386s it provides multiprocessing and virtual memory.
> 	Source is available and is fairly short.
> 	(2700 lines of portable C, 750 lines of 386 specific C, 400 lines
> 		of assembler)
I'll be ftping it.



------------------------------------------------------------------------------
[MOOSE Administration]


List of official subjects with (current) maintainer
===================================================
- MOOSE People			Fare		Members & contacts
- MOOSE Manifesto		Fare		Our goals and means
- MOOSE Administration		Fare		How we organize
- MOOSE Specificating tools	Fare		What will we use ?
- MOOSE pre-Specifications	Fare		A first wish/hate list.
- MOOSE Glossary		Fare		Internal vocabulary explained
- MOOSE Howto			Fare		How to reach each other
- MOOSE ToDo			Fare		What next to do
Note: I'd be quite happy to give away as much of this work as possible,
  to anyone else participating.

Proposed mechanism:
------------------
>From now on, each subject will have a file, and modifications should be sent
to the maintainer as diff files from the current "official" one, which will
be made available by ftp.
See the Howto section about FTPing.

MOOSE Sites:
-----------
Currently:	None
To be:		I'll be asking for a MOOSE account, anonymous ftp, and/or
		mailing list on frmap711.mathp7.jussieu.fr;
		if you can ask for such services elsewhere, maybe it's better.

References:
----------
	* The archive of the MOOSE mailing list will be available
	 from frmap711.mathp7.jussieu.fr, in ~rideau/pub/moose
	* Self papers are available from self.stanford.edu:pub/papers
	* VSTa is available from ftp.cygnus.com
	* Linux is available from tsx-11.mit.edu

------------------------------------------------------------------------------
[MOOSE People]
Have answered positively:
- Michael Winikoff
- JJ. Lay
- David Garfield
- Fare Rideau (me)
Hey ! That's only three of us !

Have answered negatively:
- Gary D. Duzan (gary@dsh.org), now uses 386 NetBSD
- Peter Mueller

Have not answered:
- All the others (in particular Dennis 8(

Could not be joined:
- Andreas Arff,
- Rob McKeever,
- Dan Odom

Well, we sure should renew Dennis' call on the news, And re-create a mailing
list ! But I think (tell me if you don't agree) we should first write some
kind of a Manifesto.

------------------------------------------------------------------------------
[MOOSE Manifesto]

Status:
------
	everything here is first proposed and thus not yet contradicted.
	Later drafts will be divided according to status.


What is an OS
-------------
	* An OS is essentially a frame for computer programming semantics.
	* It should ideally provide features so that any high-level
	 construct you use can be directly interpretable inside this frame
	 (else you'll have to build your own intermediate system).

What's basically WRONG about currently widely available OSes
------------------------------------------------------------
	* Current OSes are all based upon "C", and C's semantics is the frame.
	 This means no protection apart from huge processes, difficult error
	 recovery and parallelization, flat memory model, no easy reflexivity
	 (=producing code from code), no true dynamic (runtime) linking/code
	 enhancement.
	* The OS also offers standard libraries and tools of code&data that
	 handle common user data. Most of it is dedicated to manage special
	 cases of argument and error verifying and reporting (not even
	 handling !) and I/O multiplexing (which does not save you from
	 doing your own I/O multiplexing as no generic tool is provided).
	* Due to C heaviness, most of current OS is a burdensome multiplexer/
	 demultiplexer and straightforward call translator, that is very
	 difficult to extend.
	* Due to C poor error handling, processes shouldn't be expected to
	 be permanent AND carry important data. Modified data must thus be
	 saved on disk regularly; but disk security and error handling must
	 then be assumed by the user program, and it must rewrite entirely
	 its data saving library as no generic data saving is available.
	 Modified code that was a challenge to produce is a double challenge
	 to save. That means any complicated object persistency is very
	 difficult and heavy to obtain (but not impossible) under these OSes.
	 Databases are heavy and very prudently used applications, whereas
	 the good ol' text editor becomes the tool of choice for everyday
	 small databasing.
	* Due to poor C parallelizability, distributing data (not to talk
	 about code !) on a parallel machine and/or on a network is another
	 kind of challenge, and can't be done directly (doing it IS rewriting
	 an OS layer). That's why we always hear about the centralized
	 "client/server" model as the state-of-the-art technique, whereas it
	 is only the (reliable but) stupid slow straitforward oldest technique
	 available for sharing data.


What is OOness
--------------
	* Object-orientedness is a means by which all this multiplexing stuff
	 is done by the language implementing system, not by the program
	 writer.
	* an OO OS will provide a generic multiplexing/demultiplexing
	 interface able to understand all kinds of high-level and low-level
	 calling convention, and that's all.
	* An OO OS is NOT only an OS internally written in an OO language
	 making maintenance simpler but not changing the interface.
	 It's an OS whose entire interface is designed in an OO way; if it's
	 written in an OO language, it must still export the OO facilities
	 dynamically (which means an open language with partial evaluation
	 and/or reflexivity, which C++ is not, for instance).
	* Libraries (purely low-level libraries corresponding to what's
	 called drivers on older OSes) are just objects that can connect to
	 this interface.
	* The interface provide standard nodes to connect on. This
	 actually is a conventional mechanism orthogonal to the interface
	 implementation itself. Standard libraries connect on the other side
	 of these nodes, to provide their standard services.

What is persistency
-------------------
	* Persistency is having objects survive a session. i.e. when you
	 shut down the system and relaunch it, the object is still here.
	* Code may be persistent as well as any other object: you shutdown
	 the computer, but your computation will automatically go on when
	 you launch the system again. A "save game" option in a game will
	 thus simply consist in saving the running game object (a "save
	 session" option is the same for any software).
	* The system thus behaves like an object-oriented database, that it
	 actually is.

What is secure formal programming
---------------------------------
	* Formalization/Prototyping: when designing a program, you put
	 together both the code and some specifications about what it should
	 do. The system constructively verifies that the code complies to the
	 specification.
	* In such a way, the compiler can ensure there will be no run-time
	 failure or bugs (unless both the code AND the specification are
	 jointly buggy) and/or tell exactly where to add error managing.
	* Of course, a danger comes from low-level I/O drivers not being
	 well specified, but we can under-specify them if it suffices to our
	 needs.
	* Underspecifying (telling the computer "trust that code anyway if
	 you can't prove its correctness) is the way we'll use when we don't
	 have time to prove our software.
	* Undercoding (telling the computer "if you can't figure out how to
	 do it, ask the user to do it manually and just verify the result")
	 is the common way to have secure but not completely automatized
	 programming.

MOOSE semantics
---------------
    Object-Orientedness
	* MOOSE considers interfaced objects. Each such object must abide
	 by the laws of MOOSEing. Other objects don't quite exist for MOOSE.
	* Interfaced objects can be any size, tiny to huge. Of course, it
	 is costly interfacing tiny objects, but you only need interface
	 them 'til they are linked. If they are linked once, just forget
	 the interface; if they are linked very often, the interface is
	 worth its cost.
	* Linking objects one with the other is one function of the OS.
	 Another one is to close existing links. An object that does no
	 more export some information may then be optimized so that this
	 information disappears if not used internally. This process is
	 done automatically and at run-time. That's partial evaluation.
	* Information exported by interfaced objects:
	 - external objects accessed.
	 - internal objects exported.
	 - properties required and or provided by these objects. This allow
	  a proof of object linking correctness, a great concern for
	  reliable software. This is the main entrance of

    Secure formal programming
	* The system will provide standard nodes to verify or produce
	 code and/or specifications that comply to each other.
	* When linking objects, it will ensure the correctness of the
	 linking (whereas the only correctness in current languages is
	 typechecking, which is quite good but just not enough in the
	 general case: it's a formal lossy interpretation, some
	 deterministic hence under- specification).

    Persistency
	* Not only can the system link, but it also can unlink (still)
	 exported objects, and save each object separately on disk.
	* The OS itself provide a way to ensure consistency of the
	 saved data. Data written on permanent media (disks) will not
	 be acknowledged, and older versions not erased, unless it has been
	 marked consistent by the system.
	* It also ensures that data is saved regularly, thus
	 achieving true reliable persistency.

    Parallelization
	* Many objects live and evolve at the same time.
	* This means the system is somehow "multitasking" as it simultaneous
	 objects can be computing without waiting for all the others to have
	 finished.
	* ...Garbage collecting...
	* ...sharing context
	* ...extending and overriding one's own context...
	* ...accessing another one's context (if exported)...
	* ...system verified linking preconditions on exports
	  can ensure arbitrarily secure exports, not only
	  stupid sstrwxrwxrwx rights...



------------------------------------------------------------------------------
[MOOSE pre-Specifications]

Agreed:	(not contradicted, defended by both Michael and I)
======	(must be voted again in next meeting to become official)

Destination Platform:
--------------------
	* Portable,
	* but initially concentrate on 386/486 with view to later porting.
	* A virtual memory protection mechanism is assumed
	 (or will be software emulated _yeech_)

Copyright policy:
----------------
	* Copyrighted, but Free
	 (well at least to any not-for-profit person or institution; we may
	 delay our choice about distributing MOOSE to companies).

Features:
--------
	See the MOOSE Manifesto

Compatibility:
-------------
	* To be able to reuse existing software we want software compatability.
	* Any compatibility is wishful for a wide acceptancy by the public;
	 but it should NOT be a priority by any means.
	* Unix compatability can be provided with a library that maps
	 unix calls to Moose system calls.
	* DOS compability requires simulating a DOS machine hardware since
	 DOS programs will make hardware access.
	* If any compatibility is to be implemented, we should begin with
	 limited Unix compatibility (perhaps the same part as used by
	 documented no-hacking DOS, so that using roughly the same call
	 mapping will serve us in using DOS no-IO programs like TASM !).
	* In any way, multiple libraries and/or compiler modules can later
	 provide compatibility with any OS (which is now called
	 "personalities").

Security:
--------
	* Not yet discussed

User Interface:
--------------
	* Not deemed important for the moment;
	* can be designed later.


Proposed:	(not contradicted, will be agreed after next meeting)
========

REUSE EXISTING WORK:
-------------------
Idea [mike-001]:
	 At least for a first implementation,
	"I suggest we start with an existing OS (possibly VSTa) and add
	class/object support either at the kernel level or as a server."

PROs:
	* we don't have the resources to create	everything.
	 We should reuse existing work -- I'll
 		expand on this below.
(I just add)
	* And even if we have, it's stupid not to concentrate
	 on the essential, i.e. the MOOSE semantics, not device drivers.



discussed:	(multiple options are proposed, we'll have to choose
=========	 or delay choice on next meeting)

Existing OS to use as a basis to our work:	(NOT cross-devlpt platform)
-----------------------------------------
Options:

(I)	Use plain DOS and use a DPMI DOS extender
Status:	None for, all against. Will be rejected.
PROs:	* widely available platform
	* easy to convince people trying it.
CONs:	* Unix is more available.
	* living together with DOS is a pain in the a*s.

(II)	Use plain BIOS and use real mode for I/O.
Status:	None for, all against. Will be rejected.
PROs:	* we don't rewrite the most basic I/O.
	* No DOS to let live as with (I)
	* We can choose our own memory model, not pure unprotected flat.
CONs:	* We rewrite all specific I/O but disk I/O.
	* We must live with the BIOS (easier than the DOS, though).
	* no local I/O drivers as with (I).
	* (III) seems easier and better.

(III)	Modify VSTa
Status:	not discussed enough (only Michael saw it)
PROs:	* No I/O to rewrite
CONs:	? Are we still able to choose our memory model ?

(IV)	Use POSIX-compliant software (i.e. Linux, SunOS, etc) as a platform
Status:	not discussed enough
PROs:	* Most widely available platform (on the PC's, use Linux or perhaps
	 BSD)
CONs:	* we must REinterface all the huge U**x C library for our needs.
	 particularly the terminal and/or (later) graphical library; and
	 all these have VERY complicated semantics.
	* we must abide by C's semantics (especially the flat unprotected
	 memory model -- or can you handle page faults resulting from
	 mmap() ???)

Object file format:
------------------
Requirements:
	* Our object file format must be full-featured for saving
	 persistent object-oriented stuff in a hardware independent
	 way.
Options:
	* Using SOM (IBM's OO specification stuff) as an OO interface and
	 object file format.
	 [find the specifications by ftp on cil.org]
	* Use Meme as an object file format. Meme is a hardware
	 independant FORTH-based file format originally designed for
	 networking real-time Virtual Reality (4D graphics) software.
	 The 4D-graphics is copyrighted, but the object file format may
	 not be. Contact the author on comp.lang.forth (I have his address
	 somewhere).

------------------------------------------------------------------------------
[MOOSE Specificating tools]


THE BIG QUESTION, always discussed, and not agreed upon already:
===============================================================
  Of course, we must use some high-level tools to build MOOSE
(we're not going to program it directly in hexadecimal as in the
early Apple ][ days !). So,

	<<WHAT ARE OUR LANGUAGE REQUIREMENTS ?>>
	<<KNOWING THAT, WHAT HIGH-LEVEL LANGUAGE(S) TO CHOOSE ?>>

LANGUAGE REQUIREMENTS:
=====================
The language issue is central in the OS.
All the OS' semantics will depend on the choice of the language.

Ideally, the semantics of the two should be equivalent: that is, any
 construct made available by one must be directly mappable on the constructs
 of the other (that it will actually be thus mapped is another question).

	* Of course any existing language may be implemented over the
	 system (it's Turing-equivalent, and offers the usual IO facilities).
	* The problem is which language will match the OS' semantics.
	* It appears that the language should be open, offer partial
	 evaluation, admit side-effects and parallel processing, object
	 annotation. It should rely on primitives simple enough so that
	 program specifications are a feasible thing, yet offer a back door
	 to unsafe programming (unless we're specifying the whole hardware
	 before we write anything in the language using the given hardware).

Big Questions:
-------------
Q1	* What kind of interface and functionality do we want/need?
A1 (partial answer)
	* NEED: None; a turing machine (what current OSes already provide)
	 is enough for all possible computing in the world.
	* WANT: hey, that's the point. We're so free we must restrict
	 oneselves. We can choose our own bounds.

Q2	How does adding classes/objects to the system work?
R2	That's what we'll be discussing below.


Features thrown out:
-------------------

(temp. note: I've put there text from Michael's letter, and almost all the
		4.3 from my previous letter)

*** Door to a secure parallel execution in an OO language *** [first proposed]
Michael original: (not contradicted, enhanced by Fare next)
	* We need memory management and memory protection.
	* We want multitasking.
	* A simple kernel would support these standard things and in
	 addition would recognize ``objects'' and ``classes''

Fare's Proposed enhancement: (not contradicted; to be agreed upon on next
				meeting)
	* why not have multitasking, memory management and protection
	 as objects among others (well, with a low-level implementation,
	 but the same interface to the kernel) ?
	* Our kernel would just be the object/class calling convention.
	 All other features will be considered the run-time library.
	* There will be objects to manage tasks and memory management.
	 The kernel itself may not even be conscious of these, only knowing
	 about how to call other objects !

PROs:	* We need the language to be parallel-execution aware, as if we
	 want multitasking, we should be able to declare in a simple way
	 what objects are shared (C's shared memory segments: _yeech_, and
	 unsecure).

*** Low-level ability *** [proposed twice]
	* low-level things cannot be banned from the system.
	 On the opposite, this means a same high-level concepts can have
	 plenty of different low-level realization,
	 and not only one as on older low-level languages;
	 efficiency details can be thought of afterwards and
	 separately in each particularization.

*** High-level -> low-level mapping *** [proposed twice]
	* This means the language, 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
	 straightforwardly (or subtlely :) computed 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.
	* 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.

*** Security *** [proposed twice]
	* 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.
	* Again this can be done by annotating objects by property they
	 do or should have, then relying on properties they have been
	 *proved* to have to eliminate checks when implementing them.
	* A super-user is someone the computer trusts enough to consider
	 that some property is proved just because the super-user told him
	 so insistently.

*** Partial evaluation ***
	* 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.
	* A dynamic compiler/linker is the true heart of the system, while
	 the traditional service-providing "kernel" is only a (basic,
	 necessary) library, a replaceable extension to the system.

*** Annotations ***
	* We saw that all these features could be implemented on a kernel
	 that only manages ANNOTATIONS: you annotate an object by how to
	 use it, what properties it has, etc.
	* You may almost freely add annotations to any object you are given
	 access, and modify them in a *LOCAL* scope. Accessing a more global
	 scope is done by using objects exporting side-effects.


Objects & Classes:
-----------------
Michael:
  What is an class? From the point of view of the kernel,
 it's a piece of code with
	(a) multiple entry points
	(b) An attached description of these entry points and their types.
	(c) An indication of inheritance (more thought needed on this one)
  What is an object? From the point of view of the kernel it's a data region
 with an associated class.
  The kernel lets us install new classes into the inheritance hierarchy.
  The kernel lets us create objects (instances of classes)
  The kernel lets us call the methods of objects.

Fare:
 To be more general,
	* A class is a standardized interface to services.
	* The kernel IS exactly the mechanism that given an object and a class,
	 allows one to access the services for the object.
	* Those services may be extensions to an existing class' services.
	 That's "Inheritance".
	* More generally, one of those services may return another standard
	 interface, i.e. another "class". This exported class is embedded in
	 the first one.
	* A class may embed zero, one, or more other classes; it may even
	 embed the same class in different ways (e.g. a Double Queue can embed
	 a queue in one direction and a queue in the other).
	* Having classes and objects dynamically appearing in the system is
	 equivalent to our language being reflexive: you can write code from
	 inside the language; there is a class describing classes, and so on.


CHOICE OF LANGUAGE
------------------

WRITING OUR OWN LANGUAGE+PROGRAMMING ENVIRONMENT
------------------------------------------------
Prerequisite:
	* if the language appears to be the central step forward in MOOSE,
Status:
	proposed by Michael, 100% backed by me (Fare)
Idea:
	* we can even just design a language, a programming environment
	 and a shared library so that programs written in our language
	 would be nice and have all the facilities the OS should be
	 providing.
PROs:
	* by writing it on a common powerful platform (e.g. some Unix).
	* This implementation wouldn't need to worry about
	(e.g.) handling other languages and could be relatively portable.
CONs:
	* Using an existing platform means we do not control all the hardware
	 and particularly memory mapping and error catching.
	* It also means all kind of clumsiness while remapping MOOSE calls
	 into the host system calls, but that's the price to pay.
	* designing a language would take longer than learning an existing one.


*** If we decide that the language is not central to our project we should
*** try hard to use an existing language.

USING PLAIN "C"
---------------
Idea:	Write all the OS in plain "C"
Status:	no one supports it. I (Fare) am 100% against it.
PROs:	* We do not have to design or even learn a new language
	* C already exists and is widely available, and even quite "portable".
CONs:	* C's semantics are completely different from OO, parallel,
	 error-aware, persistent, annotated, specifiable, partial-evaluation
	 semantics.
	* Interfacing our C code in an such a way will be a pain in the
	 ass, while what are we going to interface it to ? Are we writing
	 an OS without client ?
	* If we stick to C's semantics, we are not likely to do better than
	 hUgeNIX.
	* Available "C"s are huge (see GCC).


USING CAML
----------
Idea:	* Write all the OS using "CAML-light"
	* CAML-light is a language based on typed lambda calculus, with
	 full support for side effects, and support for modules being
	 added.
	* Any CAML-light program is secure (but perhaps for memory
	 overflow ?) (unless you load code manually from disk...).
	* It works on any 32 or 64 bit Unix system, and even on 16-bit
	 DOS or with 32-bit DOS extender, as it's written in C and CAML.
	* See caml-light 0.6 on ftp.inria.fr

Status:	proposed by Fare, just in case it may interest someone
PROs:	* There are (small) doors to allow persistency (any object can be
	 saved on disk) and parallelism (there exist some multi-threading
	 patch somewhere), partial evaluation (though not lazy evaluation)
	 with lambda-calculus, etc.
	* Libraries to access system calls are available; you can link
	 (specially written) C code with CAML code. Interface to system
	 calls already exist.
	* Two CAML->C compilers exist, so the code may be efficient anyway.
CONs:	* CAML's OOness is very clumsy (currently being developped) at the
	 time.
	* Security is good, but may be VERY hard to enhance (or we may
	 add it in the CAML machine itself)
	* Annotating objects is possible, must be declared with the object.
	* CAML is far from the low-level.
	* CAML's semantic is good, but not exactly what we need, so either
	 we use plain CAML, and there's some inadaptation, or we write another
	 language on top of CAML, and that's somehow inefficient, or we take
	 CAML and modify it, but that's difficult.


USING SELF
----------
Status:	Proposed by Michael
PROs/CONs:	Can you send me your PRO's and CON's, please Michael ?
		What do current SELF implementation rely upon ?
		How does it match our requirements ?
		What does it look like ?
Michael's Suggestion:
	* Look at Self (OOPSLA '87, Sigplan 22:12 -- I think it's FTPable)
		Self is an OO language that uses a simpler alternative to
		inheritance.


Low level language tool used to implement the low level part of the OS:
======================================================================
Prerequisite:
	We're not already using a language on an existing platform.

Using TASM at first
-------------------
Prerequisite:
	if we happen to use the i386 as a basis on the assembly level;
	we write some important part of the system in assembly and/or we
	use a memory model other than pure flat memory model.
Idea:
	I think we can use TASM (Turbo Assembler, by Borland),
	and replace it later by our own integrated OO assembler library.
Status:
	first proposed, not yet contradicted; prerequisite in discussion.
PROs:
	* TASM is a powerful assembler for the lowest level part of MOOSE
	 on i386 (both real mode and protected mode), whose high-level
	 features are unique among existing low-level-able assemblers
	 (*arbitrary multiple segments*, powerful macros among which
	 I've written @IF @THEN @ELSE @ENDIF, Print "hello", for runtime,
	 etc).
	* If we can skip its features hopefully, we can replace it by as86
	 for real mode and gas for protected mode (flat model only). but I
	 don't think this is much feasible, unless the assembly part is
	 minimal, which surely means we use an existing language with its
	 own memory management (which surely is not easy to use in a
	 secure multithreading way).
CONs:
	* MASM (Microsoft Macro assembler) may be more used among us, and
	 as TASM has a MASM-compatible mode, we may prefer to use MASM.
	* The main problem is it's commercial software. That it runs under
	 DOS should not be a problem. It's real-mode only (at least for older
	 versions) with no direct I/O, so should work under any DOS emulator.

A FORTH-like thing
------------------
Idea:	* Use a (32 bit)word-aligned direct threaded language as a basis. This
	 reduces underlying hardware dependencies and need for a powerful
	 assembler (or even for an assembler at all, outside quick interrupt
	 driven I/O loops).
Status:	* first proposed, not yet contradicted.
PROs:	* It's quick and cheap to write, easily extensible, and nobody
	 forbids writing a compiler that'll produce machine code from our
	 language later.
	* The threaded code can point to "C" void(void) code or code written
	 in any language (use of global variables as the machine' state).
	* We're not stuck with C's limited semantics as of parallel
	 programming & error recovery, etc.
CONs:	* Speed may be reduced as compared as using a existing "optimizing"
	 compiler for a common language (e.g. GCC).


Using "C"
---------
Idea:	* Implementing the language completely in C.
Status:	* Put there so that we do not forget any solution.
PROs:	* The produced code is somehow faster than if using threaded code.
CONs:	* difficult to maintain, port, or retranslate in our
	language as C's semantics is so different from our own.
	* the threaded code may be more usable afterwards, and we
	 may compile it one day, whereas all effort put in C will
	 be lost.


------------------------------------------------------------------------------
[MOOSE ToDo]

More or less in the order:
* See that we do agree on something useful.
* Write a Manifesto.
* Contact people on the net.
* Decide the platform/basis to use for MOOSE.
* Produce a standard for formatting internal documents.
* Fully Design our language and/or OO interface.
* Write a sample application using it
 (a multi-simultaneous-user editor and/or database ?)
* Write it.


------------------------------------------------------------------------------
[MOOSE Howto]

E-MAIL
======
  E-Mail means electronic mail.
  We assume here you're on the Internet.
  There used to be an automatic list moose-programmers@sfu.ca, but it doesn't
seem to work anymore.
  So here are the (hopefully) connected ones (only the first three answer):

  winikoff@munta.cs.mu.oz.au,
  csjjlay@mtsu.edu,
  rideau@clipper.ens.fr,
  ANDREASA@fenris.dhhalden.no,
  dmarer@td2cad.intel.com,
  garfield@sra.com,
  haydedr@wkuvx1.bitnet,
  mckeeveb@sfu.ca,
  newlin@ecn.purdue.edu


IRC
===
  One way to join MOOSE is to use the Internet Relay Chat system.
Please man irc (or take it from an ftp site, like sunsite.unc.edu).
  Well, first check if an irc executable is available on your site
(it must be irc or ircii). If it is, just launch it. Change your IRC
nickname with command nick (e.g. /nick Fare) or change the variable
IRCNAME. Then, join the MOOSE channel (e.g. /join #_MOOSE) and when
you're done, quit (/quit). If I'm not on #_MOOSE, I may be on #Linux.
Beware ! There's already some bizarre hacker periodically using and
*blocking* #MOOSE (his nickname is Moose), so we shouldn't use it.
If anyone has any other channel name to propose, tell it.
Try /whois Fare to see if I'm here, and /msg Fare Hello ! to attract
my attention. /help may be a useful command for beginners.


------------------------------------------------------------------------------
[MOOSE Glossary]

Maintainers:
===========
The MOOSE project is divided into subjects.
Each subject is managed by a maintainer, who must regularly (at least
after & before each meeting) update a database of all that's been said,
unsaid, decided, undecided, settled or projected about the subject. He
must tell what's been definitely decided; he must show as objectively as
possible each one's arguments pro and con each topic discussed; he must
point to history of each change or decision; he must collaborate with the
ToDo list to make know the status of his subject.
Maintaining is writing such


Idea status
===========
Some idea in the MOOSE project can have several status:
* finished/(well)implemented
	Not only is the idea in the specifications,
	but it also has been implemented !
* defined
	The idea has been agreed and has found its path in
	the official MOOSE specifications.
* agreed
	The idea was voted and accepted, or not contradicted for
	enough time.
* proposed
	was proposed and not contradicted.
	After next meeting, if still not contradicted, agreed.
* discussed
	was proposed, and discussed.
	must be voted or its decision delayed at next meeting
* rejected
	The idea was voted, and rejected.
* not defined yet:
	Nobody has talked about such a thing being or not in the project.
	of course, we're not maintaining a list of such ideas 8)
* defined not to be
	The official specifications reject such an idea.

Idea Number
===========
The originator of the idea give it a unique absolute number for further
discussion and vote (the net is slow enough so that saving many sentences
for one reference is good !). Further comments are added under the idea and
given a paragraph number under the idea.

------------------------------------------------------------------------------

Well, please excuse me for the extended delay (my account has been
momentarily suspended, then I added my own delay 8-( ).
Mail really is too slow.
Really, that's a long message.
Well, whatever happens, good luck to you all !

BTW:
could everyone of you upload all his references to ~rideau/pub/moose in
frmap711.mathp7.jussieu.fr ? I'll (momentarily) set my passwd to MoOsE,
so that you can all login. I'll try to open an official MOOSE account there.
Please, do not make me fired of this account 8-?

--    ,        	                                ,           _ 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                                    /|\ /|\ /