From rideau@mathp7.jussieu.fr Tue May 31 08:42:59 1994
Return-Path: <rideau@mathp7.jussieu.fr>
Received: from shiva.jussieu.fr by frmap711.mathp7.jussieu.fr (4.1/jn910403)
	  at Tue, 31 May 94 08:42:57 +0200
Received: from nef.ens.fr by shiva.jussieu.fr
	  (8.6.8/jtpda-4.0) with SMTP; Tue, 31 May 1994 08:44:42 +0200
Received: from clipper.ens.fr (clipper-gw.ens.fr) by nef.ens.fr (5.65c8/ULM-1.0)
	Id AA25608 ; Tue, 31 May 1994 08:42:55 +0200
Received: from nef.ens.fr by clipper.ens.fr (4.1/version 1.10 of 88/05/05)
 	id AA27207; Tue, 31 May 94 08:42:54 +0200
Received: from shiva.jussieu.fr by nef.ens.fr (5.65c8/ULM-1.0)
	Id AA25604 ; Tue, 31 May 1994 08:42:53 +0200
Received: from frmap711.mathp7.jussieu.fr by shiva.jussieu.fr
	  (8.6.8/jtpda-4.0) with SMTP; Tue, 31 May 1994 08:44:29 +0200
Received: by frmap711.mathp7.jussieu.fr (4.1/jn910403)
	  at Tue, 31 May 94 08:42:42 +0200
From: rideau@mathp7.jussieu.fr (Francois Rideau)
Message-Id: <9405310642.AA20178@frmap711.mathp7.jussieu.fr>
Subject: [fare-01] MOOSEing again
To:	moose-programmers@sfu.ca (Moose),
	garfield@sra.com (David Garfield),
	winikoff@nulga.cs.mu.oz.au (Michael Winikoff),
        csjjlay@mtsu.edu (JJ Lay), rideau@ens.fr (Fare),
        ANDREASA@fenris.dhhalden.no (Andreas Arff),
        danodom@matt.ksu.ksu.edu (Dan Odom),
        dmarer@td2cad.intel.com (Dennis Marer),
        haydedr@wkuvx1.bitnet (Ross Hayden),
	mckeeveb@sfu.ca (Bob McKeever),
	gary@dsh.org (Gary Duzan),
        newlin@ecn.purdue.edu (John Newlin)
	mueller@sc.ZIB-Berlin.DE (Peter Mueller),
	fate@ccwf.cc.utexas.edu (Eric),
	dspascha@eos.ncsu.edu
Date: Tue, 31 May 94 8:42:41 MET DST
X-Mailer: ELM [version 2.3 PL11]
Status: OR

(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                                    /|\ /|\ / 



From beig@clipper.ens.fr Wed May 11 19:30:44 1994
Return-Path: <beig@clipper.ens.fr>
Received: from shiva.jussieu.fr by frmap711.mathp7.jussieu.fr (4.1/jn910403)
	  at Wed, 11 May 94 19:30:39 +0200
Received: from nef.ens.fr by shiva.jussieu.fr
	  (8.6.8/jtpda-4.0) with SMTP; Wed, 11 May 1994 19:32:09 +0200
Received: from clipper.ens.fr (clipper-gw.ens.fr) by nef.ens.fr (5.65c8/ULM-1.0)
	Id AA05371 ; Wed, 11 May 1994 18:43:23 +0200
Received: from nef.ens.fr by clipper.ens.fr (4.1/version 1.10 of 88/05/05)
 	id AA02169; Fri, 29 Apr 94 03:28:41 +0200
Received-Date: Fri, 29 Apr 94 03:28:41 +0200
Received: from mulga.cs.mu.OZ.AU by nef.ens.fr (5.65c8/ULM-1.0)
	Id AA05201 ; Fri, 29 Apr 1994 03:28:40 +0200
Received: from munta.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA17453
	Fri, 29 Apr 1994 11:28:17 +1000 (from winikoff)
Received: by munta.cs.mu.OZ.AU (8.6.8.1/slave-1.1)
	id LAA07575; Fri, 29 Apr 1994 11:28:17 +1000
Received: from mulga.cs.mu.OZ.AU by munta.cs.mu.OZ.AU with SMTP (8.6.8.1/slave-1.1)
	id LAA07559; Fri, 29 Apr 1994 11:27:42 +1000
Received: by mulga.cs.mu.OZ.AU (5.83--+1.3.1+0.50); id AA17417
	Fri, 29 Apr 1994 11:27:31 +1000 (from Postmaster)
Date: Fri, 29 Apr 1994 11:27:31 +1000
From: Mail Delivery Subsystem <Postmaster@cs.mu.oz.au>
Subject: Returned mail: Host unknown
Message-Id: <9404290127.17414@mulga.cs.mu.OZ.AU>
To: winikoff@cs.mu.oz.au
Sender: root@clipper.ens.fr
Status: OR

   ----- Transcript of session follows -----
554 <rideau@clipper.eus.fr>... 550 Host unknown (Authoritative answer from name server)

------- Received message follows ----

Received: from munta.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA17414
	Fri, 29 Apr 1994 11:27:31 +1000 (from winikoff)
Return-Path: <winikoff>
Received: by munta.cs.mu.OZ.AU (8.6.8.1/slave-1.1)
	id LAA07556; Fri, 29 Apr 1994 11:27:30 +1000
From: winikoff@cs.mu.OZ.AU
Message-Id: <199404290127.7556@munta.cs.mu.OZ.AU>
Subject: MOOSE and Hi!
To: rideau@clipper.eus.fr
Date: Fri, 29 Apr 94 11:27:30 EST
X-Mailer: ELM [version 2.3 PL11]


Hi!

I got your letter.
I'm currently very busy trying to finish a paper by tommorow so I'll
reply at length early next week.

My address is winikoff@cs.mu.oz.au (same as winikoff@mulga.cs.mu.oz.au)

I'm currently doing a PhD at Melbourne Uni in Linear Logic Programming
(Deriving/Designing/Implementing a logic programmning language based on 
linear rather than classical logic)

Michael -- more soon ...


------- Received message ends    ----



From beig@clipper.ens.fr Wed May 11 19:28:33 1994
Return-Path: <beig@clipper.ens.fr>
Received: from shiva.jussieu.fr by frmap711.mathp7.jussieu.fr (4.1/jn910403)
	  at Wed, 11 May 94 19:28:24 +0200
Received: from nef.ens.fr by shiva.jussieu.fr
	  (8.6.8/jtpda-4.0) with SMTP; Wed, 11 May 1994 19:29:53 +0200
Received: from clipper.ens.fr (clipper-gw.ens.fr) by nef.ens.fr (5.65c8/ULM-1.0)
	Id AA05391 ; Wed, 11 May 1994 18:43:37 +0200
Received: from nef.ens.fr by clipper.ens.fr (4.1/version 1.10 of 88/05/05)
 	id AA24170; Mon, 2 May 94 12:43:15 +0200
Received-Date: Mon, 2 May 94 12:43:15 +0200
Received: from mulga.cs.mu.OZ.AU by nef.ens.fr (5.65c8/ULM-1.0)
	Id AA24849 ; Mon, 2 May 1994 12:43:10 +0200
Received: from munta.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA20135
	Mon, 2 May 1994 20:43:06 +1000 (from winikoff)
Received: by munta.cs.mu.OZ.AU (8.6.8.1/slave-1.1)
	id UAA25105; Mon, 2 May 1994 20:43:05 +1000
From: winikoff@cs.mu.oz.au
Message-Id: <199405021043.25105@munta.cs.mu.OZ.AU>
Subject: Test?
To: rideau@clipper.ens.fr
Date: Mon, 2 May 94 20:43:05 EST
X-Mailer: ELM [version 2.3 PL11]
Sender: root@clipper.ens.fr
Status: OR


Hi!

Could you give a yell if you get this ..

Thanks!

Michael



From beig@clipper.ens.fr Wed May 11 19:33:33 1994
Return-Path: <beig@clipper.ens.fr>
Received: from shiva.jussieu.fr by frmap711.mathp7.jussieu.fr (4.1/jn910403)
	  at Wed, 11 May 94 19:33:30 +0200
Received: from nef.ens.fr by shiva.jussieu.fr
	  (8.6.8/jtpda-4.0) with SMTP; Wed, 11 May 1994 19:34:59 +0200
Received: from clipper.ens.fr (clipper-gw.ens.fr) by nef.ens.fr (5.65c8/ULM-1.0)
	Id AA05441 ; Wed, 11 May 1994 18:45:03 +0200
Received: from nef.ens.fr by clipper.ens.fr (4.1/version 1.10 of 88/05/05)
 	id AA21172; Thu, 5 May 94 02:18:53 +0200
Received-Date: Thu, 5 May 94 02:18:53 +0200
Received: from uu5.psi.com by nef.ens.fr (5.65c8/ULM-1.0)
	Id AA05739 ; Thu, 5 May 1994 02:18:53 +0200
Received: from dsh.UUCP by uu5.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP;
        id AA03043 for ; Wed, 4 May 94 19:55:45 -0400
Received: by dragon.dsh.org (Smail3.1.28.1 #5)
	id m0pyqlm-0000JAC; Wed, 4 May 94 19:54 EDT
Message-Id: <m0pyqlm-0000JAC@dragon.dsh.org>
To: rideau@clipper.ens.fr (Francois-Rene Rideau)
Subject: A Dead Moose
Date: Wed, 04 May 94 19:54:26 -0400
From: "Gary D. Duzan" <gary@dragon.dsh.org>
Sender: root@clipper.ens.fr
Status: OR


   Just wanted to answer your mail. It isn't every day I get a
letter from France. :-) I'm still stuck at DSH running a Banyan
Vines network.  My account at UDel finally got axed, but I have
Mail and News here via UUCP. So IRC, talk, etc., are out for now,
but the State's Internet gateway is coming up slowly, and I am
hoping to move to another job somewhere.
   Linux, eh? I'm running NetBSD, myself. I decided on it because
it is built for portability, and I may want to get a RISC box in
the future. Right now I have it running at work on a 486/33 and
at home on my new 486DX2/66. I thought I might do some hacking on
it, but I don't know if I really want to take the time to pick up
all the internals of the massive mess that is Unix.
   But as far as building a new system goes, I've decided that
necessity really is the mother of invention, and I don't have a
personal need for a new operating system right now. If I were a
grad student in computer science, I'd be more than happy to
work on such a project, but as it is I don't think I would be
able to give the project the attention it deserves. Besides, I
probably don't really have the experience I should have going
into it.
   Enough excuses? :-) Good hearing from you again.

                                      Gary D. Duzan
                         Humble Practitioner of the Computer Arts





From beig@clipper.ens.fr Wed May 11 19:33:40 1994
Return-Path: <beig@clipper.ens.fr>
Received: from shiva.jussieu.fr by frmap711.mathp7.jussieu.fr (4.1/jn910403)
	  at Wed, 11 May 94 19:33:32 +0200
Received: from nef.ens.fr by shiva.jussieu.fr
	  (8.6.8/jtpda-4.0) with SMTP; Wed, 11 May 1994 19:35:01 +0200
Received: from clipper.ens.fr (clipper-gw.ens.fr) by nef.ens.fr (5.65c8/ULM-1.0)
	Id AA05449 ; Wed, 11 May 1994 18:45:07 +0200
Received: from nef.ens.fr by clipper.ens.fr (4.1/version 1.10 of 88/05/05)
 	id AA03129; Thu, 5 May 94 06:57:54 +0200
Received-Date: Thu, 5 May 94 06:57:54 +0200
Received: from mulga.cs.mu.OZ.AU by nef.ens.fr (5.65c8/ULM-1.0)
	Id AA12268 ; Thu, 5 May 1994 06:57:49 +0200
Received: from munta.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA25162
	Thu, 5 May 1994 14:57:43 +1000 (from winikoff)
Received: by munta.cs.mu.OZ.AU (8.6.8.1/slave-1.1)
	id OAA25385; Thu, 5 May 1994 14:57:44 +1000
From: winikoff@cs.mu.oz.au
Message-Id: <199405050457.25385@munta.cs.mu.OZ.AU>
Subject: Re: Contretest !
To: rideau@clipper.ens.fr (Francois-Rene Rideau)
Date: Thu, 5 May 94 14:57:44 EST
In-Reply-To: <9405042238.AA19126@clipper.ens.fr>; from "Francois-Rene Rideau" at May 5, 94 12:38 am
X-Mailer: ELM [version 2.3 PL11]
Sender: root@clipper.ens.fr
Status: OR

> 
> > Hi!
> > 
> > Could you give a yell if you get this ..
> 
> YAHOO !!!
> Happy to hear from you !
> 
> > Thanks!
> 
> <I> Thank you. You're the only one who did (could?) reply.

that bad?!

> But even if alone, I'd continue my way to what I now call (my own idea of)
> MOOSE. Look out for an incoming MOOSE message.

Yup.
I've got it.
I'm away this weekend (rehearsal camp)
I've collected some thoughts on paper and will post them to you with comments
on your mail soon (monday latest)
BTW, have you heard/seen VSTa?

> 
> > Michael
> Have a happy winter !
> 
> --    ,        	                                ,           _ 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                                    /|\ /|\ /
> 

________________________________________________________________________________
Michael Winikoff 		winikoff@cs.mu.oz.au
Computer science postgrad. University of Melbourne, Australia. 	
Fac me cocleario vomere! (Gag me with a spoon)
CA/B1 iv++ u c 2/2/2 r f+ h p o+ s+ d y? PDS CWF 


From mckeeveb@sfu.ca Sat May 14 21:42:16 1994
Return-Path: <mckeeveb@sfu.ca>
Received: from shiva.jussieu.fr by frmap711.mathp7.jussieu.fr (4.1/jn910403)
	  at Sat, 14 May 94 21:42:06 +0200
Received: from nef.ens.fr by shiva.jussieu.fr
	  (8.6.8/jtpda-4.0) with SMTP; Sat, 14 May 1994 21:43:33 +0200
Received: from clipper.ens.fr (clipper-gw.ens.fr) by nef.ens.fr (5.65c8/ULM-1.0)
	Id AA16177 ; Sat, 14 May 1994 21:42:01 +0200
Received: from nef.ens.fr by clipper.ens.fr (4.1/version 1.10 of 88/05/05)
 	id AA25528; Sat, 14 May 94 21:41:57 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
	Id AA16169 ; Sat, 14 May 1994 21:41:57 +0200
Received: from knuth.mtsu.edu (knuth.mtsu.edu [161.45.1.1]) by whistler.sfu.ca with SMTP (8.6.8/SFU-2.6H)
  id MAA18634 for <moose-programmers@sfu.ca> (from csjjlay@knuth.mtsu.edu); Sat, 14 May 1994 12:39:07 -0700
Received: by knuth.mtsu.edu (Smail3.1.28.1 #17)
	id m0q2PY8-000AVgC; Sat, 14 May 94 14:39 CDT
Message-Id: <m0q2PY8-000AVgC@knuth.mtsu.edu>
From: csjjlay@knuth.mtsu.edu (JJ Lay)
Subject: Who is still here?
To: moose-programmers@sfu.ca (MOOSE Programmers)
Date: Sat, 14 May 1994 14:39:04 -0500 (CDT)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 835       
Status: OR

Greetings fellow MOOSErs!

I am still going over the latest email I received.  I'm just curious how many people are still involved?

                                                 ------
                                                 JJ Lay

------------------------------------------------------------------------------
JJ Lay                                           Ingram Merchandising Services
AS/400 Programmer/Analyst                        Seven Ingram Blvd
and father to be!                                La Vergne, TN  37086
csjjlay@mtsu.edu                                 1-800-284-3455 x2118
------------------------------------------------------------------------------
"Marriage is a noble institution...  If you want to be institutionalized
the rest of your life!" -Dr. Paul Hutcheson, MTSU Computer Science Dept

From mckeeveb@sfu.ca Sun May 15 22:50:29 1994
Return-Path: <mckeeveb@sfu.ca>
Received: from shiva.jussieu.fr by frmap711.mathp7.jussieu.fr (4.1/jn910403)
	  at Sun, 15 May 94 22:50:19 +0200
Received: from nef.ens.fr by shiva.jussieu.fr
	  (8.6.8/jtpda-4.0) with SMTP; Sun, 15 May 1994 22:51:49 +0200
Received: from clipper.ens.fr (clipper-gw.ens.fr) by nef.ens.fr (5.65c8/ULM-1.0)
	Id AA13359 ; Sun, 15 May 1994 22:50:14 +0200
Received: from nef.ens.fr by clipper.ens.fr (4.1/version 1.10 of 88/05/05)
 	id AA25746; Sun, 15 May 94 22:50:10 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
	Id AA13355 ; Sun, 15 May 1994 22:50:12 +0200
Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8]) by whistler.sfu.ca with SMTP (8.6.8/SFU-2.6H)
  id NAA12223 for <moose-programmers@sfu.ca> (from davgar!davgar.arlington.va.us!david@uunet.UU.NET); Sun, 15 May 1994 13:46:50 -0700
Received: from uucp4.uu.net by relay3.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA17481; Sun, 15 May 94 16:46:50 -0400
Received: from davgar.UUCP by uucp4.uu.net with UUCP/RMAIL
        ; Sun, 15 May 1994 16:46:50 -0400
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Sun, 15 May 1994 16:41:55 EDT
Date:      Sun, 15 May 1994 16:41:41 EDT
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2dd68914.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: "Moose Project" <moose-programmers@sfu.ca>
Subject:   Re: Who is still here?
Status: OR

On Sat, 14 May 1994 14:39:04 -0500 (CDT), "JJ Lay" <csjjlay@knuth.mtsu.edu> wrote:
> Greetings fellow MOOSErs!
>
> I am still going over the latest email I received.  I'm just curious how
> many people are still involved?
>
>                                                  ------
>                                                  JJ Lay

Well, I am still here.

Is anyone still `involved'?

I would think that if this project is to continue a new (generally
argeed on) declaration of direction may be needed, along with possibly
a new call for participation and/or call for ideas.

--David Garfield
-- 
David Garfield
Email: david@davgar.arlington.va.us or david%davgar@uunet.uu.net or
       ...!uunet!davgar!david or garfield@verdi.sra.com

From mckeeveb@sfu.ca Mon May 16 06:55:40 1994
Return-Path: <mckeeveb@sfu.ca>
Received: from shiva.jussieu.fr by frmap711.mathp7.jussieu.fr (4.1/jn910403)
	  at Mon, 16 May 94 06:55:32 +0200
Received: from nef.ens.fr by shiva.jussieu.fr
	  (8.6.8/jtpda-4.0) with SMTP; Mon, 16 May 1994 06:57:05 +0200
Received: from clipper.ens.fr (clipper-gw.ens.fr) by nef.ens.fr (5.65c8/ULM-1.0)
	Id AA22726 ; Mon, 16 May 1994 06:55:26 +0200
Received: from nef.ens.fr by clipper.ens.fr (4.1/version 1.10 of 88/05/05)
 	id AA13716; Mon, 16 May 94 06:55:25 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
	Id AA22722 ; Mon, 16 May 1994 06:55:24 +0200
Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8]) by whistler.sfu.ca with SMTP (8.6.8/SFU-2.6H)
  id VAA24638 for <moose-programmers@sfu.ca> (from davgar!davgar.arlington.va.us!david@uunet.UU.NET); Sun, 15 May 1994 21:53:05 -0700
Received: from uucp3.uu.net by relay3.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA06579; Mon, 16 May 94 00:53:06 -0400
Received: from davgar.UUCP by uucp3.uu.net with UUCP/RMAIL
        ; Mon, 16 May 1994 00:53:04 -0400
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Mon, 16 May 1994 00:42:56 EDT
Date:      Mon, 16 May 1994 00:42:52 EDT
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2dd6f9d1.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: "Moose Project" <moose-programmers@sfu.ca>
Subject:   Re: Test ...
Status: OR

On Mon, 16 May 94 10:24:30 EST, winikoff@cs.mu.OZ.AU wrote:
> 
> Hi!
> 
> Test.
> 
> Did people get my earlier mail? (the long one)
> 
> Michael

I received your message in reply to '[fare-01]' twice.  I received a 
copy at the office (garfield@verdi.sra.com), and several days later I 
received a bounce by way of cs.mu.oz.au -> sfu.ca -> cs.mu.oz.au -> 
sfu.ca -> me.

David
-- 
David Garfield
Email: david@davgar.arlington.va.us or david%davgar@uunet.uu.net or
       ...!uunet!davgar!david or garfield@verdi.sra.com

From mckeeveb@sfu.ca Mon May 16 07:27:26 1994
Return-Path: <mckeeveb@sfu.ca>
Received: from shiva.jussieu.fr by frmap711.mathp7.jussieu.fr (4.1/jn910403)
	  at Mon, 16 May 94 07:27:15 +0200
Received: from nef.ens.fr by shiva.jussieu.fr
	  (8.6.8/jtpda-4.0) with SMTP; Mon, 16 May 1994 07:28:48 +0200
Received: from clipper.ens.fr (clipper-gw.ens.fr) by nef.ens.fr (5.65c8/ULM-1.0)
	Id AA23476 ; Mon, 16 May 1994 07:27:14 +0200
Received: from nef.ens.fr by clipper.ens.fr (4.1/version 1.10 of 88/05/05)
 	id AA13998; Mon, 16 May 94 07:27:11 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
	Id AA23472 ; Mon, 16 May 1994 07:27:10 +0200
Received: from sc.ZIB-Berlin.DE (sc.ZIB-Berlin.DE [130.73.108.1]) by whistler.sfu.ca with SMTP (8.6.8/SFU-2.6H)
  id WAA25355 for <moose-programmers@sfu.ca> (from mueller@sc.ZIB-Berlin.DE); Sun, 15 May 1994 22:25:02 -0700
Received: from ave.ZIB-Berlin.DE by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/03.06.93)
	id AA05985; Mon, 16 May 94 07:24:59 +0200
Received: from avex.ZIB-Berlin.DE 
        by ave.ZIB-Berlin.DE (4.1/SMI-4.0/24.6.93)
	id AA02155; Mon, 16 May 94 07:24:58 +0200
Date: Mon, 16 May 94 07:24:58 +0200
From: mueller@sc.zib-berlin.de (Peter Mueller)
Message-Id: <9405160524.AA02155@ave.ZIB-Berlin.DE>
To: moose-programmers@sfu.ca
Subject: Re: Who is still here?
Status: OR

Sorry,

but I'm off. I've no time for MOOSEing, anymore.

Reagrds, (best luck to all of you, who are planning to reincarnate the
project)

Peter

From mckeeveb@sfu.ca Mon May 16 02:27:08 1994
Return-Path: <mckeeveb@sfu.ca>
Received: from shiva.jussieu.fr by frmap711.mathp7.jussieu.fr (4.1/jn910403)
	  at Mon, 16 May 94 02:27:00 +0200
Received: from nef.ens.fr by shiva.jussieu.fr
	  (8.6.8/jtpda-4.0) with SMTP; Mon, 16 May 1994 02:28:32 +0200
Received: from clipper.ens.fr (clipper-gw.ens.fr) by nef.ens.fr (5.65c8/ULM-1.0)
	Id AA16842 ; Mon, 16 May 1994 02:26:55 +0200
Received: from nef.ens.fr by clipper.ens.fr (4.1/version 1.10 of 88/05/05)
 	id AA01120; Mon, 16 May 94 02:26:50 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
	Id AA16838 ; Mon, 16 May 1994 02:26:52 +0200
Received: from mulga.cs.mu.OZ.AU (mulga.cs.mu.OZ.AU [128.250.1.22]) by whistler.sfu.ca with SMTP (8.6.8/SFU-2.6H)
  id RAA17701 for <moose-programmers@sfu.ca> (from winikoff@cs.mu.OZ.AU); Sun, 15 May 1994 17:24:45 -0700
From: <winikoff@cs.mu.oz.au>
Received: from munta.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA02810
	Mon, 16 May 1994 10:24:30 +1000 (from winikoff)
Received: by munta.cs.mu.OZ.AU (8.6.8.1/slave-1.1)
	id KAA02478; Mon, 16 May 1994 10:24:30 +1000
Message-Id: <199405160024.2478@munta.cs.mu.OZ.AU>
Subject: Test ...
To: moose-programmers@sfu.ca (Moose)
Date: Mon, 16 May 94 10:24:30 EST
X-Mailer: ELM [version 2.3 PL11]
Status: OR


Hi!

Test.

Did people get my earlier mail? (the long one)

Michael


From winikoff@cs.mu.oz.au Wed May 18 06:26:18 1994
Return-Path: <winikoff@cs.mu.oz.au>
Received: from shiva.jussieu.fr by frmap711.mathp7.jussieu.fr (4.1/jn910403)
	  at Wed, 18 May 94 06:26:02 +0200
Received: from mulga.cs.mu.OZ.AU by shiva.jussieu.fr
	  (8.6.8/jtpda-4.0) with SMTP; Wed, 18 May 1994 06:27:35 +0200
From: winikoff@cs.mu.oz.au
Received: from munta.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA19162
	Wed, 18 May 1994 14:25:54 +1000 (from winikoff)
Received: by munta.cs.mu.OZ.AU (8.6.8.1/slave-1.1)
	id OAA21434; Wed, 18 May 1994 14:25:53 +1000
Message-Id: <199405180425.21434@munta.cs.mu.OZ.AU>
Subject: Re: Test ...
To: rideau@mathp7.jussieu.fr (Francois Rideau)
Date: Wed, 18 May 94 14:25:52 EST
In-Reply-To: <9405161115.AA16794@frmap711.mathp7.jussieu.fr>; from "Francois Rideau" at May 16, 94 1:15 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

> 
> > Hi!
> > 
> > Test.
> > 
> > Did people get my earlier mail? (the long one)
> 
> I fear not.
> 
> > Michael
> 
> --    ,        	                                ,           _ 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                                    /|\ /|\ /
> 

------ CUT HERE -------

Hi all!

Contents:

(1) Comments on Fare
(2) Organisation matters
	(2.1) Reuse
(3) Objectives
(4) Role of OO
(5) Suggested starting point for a design

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

(1) Comments on Fare
I agree with Fare's comments on why Moose didn't work first time around.
I hate the formatting used for the message -- it made it very hard to read.
You can easily refer to a message number and a line number without having
to label each line.
Re irc, (a) I can't make the 7th (I'm on a camp) but can make the 14th.
	(b) How does one irc?
> [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.
> 

I would prefer to have the questionthe other way around -- are there 
existing systems that we can build on?

(see section (3)XXX)

> [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++").

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.

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

(2) Organisation matters

	* What happenned to the replies to Dennis' original post?
		(the ``what would you put in a dream OS?'')
	* We should put another call for people on comp.os.whatever
	* 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.
	* The role of prototyping -- it will help a *LOT* if we knock
		up prototypes of proposed ideas before spending the time
		implementing them properly. Use of VHLL is suggested here.
		Prototype code could be included in documents.
	* REUSE EXISTING WORK -- we don't have the resources to create
		everything. We should reuse existing work -- I'll 
		expand on this below.
	* As Fare says, we should maintain a history of our work and 
		design decisions.

(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.
	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)

	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)


	A third possibility for MOOSE is to design a language, a programming
	environment and a sharred library so that programs written in our
	language would be nice and have all the facilities the OS should be 
	providing. This implementation wouldn't need to worry about
	(eg) handling other languages and could be relatively portable.

	If we decide that the language is not central to our project we should
	try hard to use an existing language.
	At a guess I'd say that designing a language would take longer then
	learning an existing one.

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

(3) Objectives
	Agreed upon:
	* Portable but initially concentrate on 386/486 with view to 
		later porting
	* Free
	* Multitasking
	* Virtual memory and memory protection
	* Object Oriented (see section 4)

	To be able to reuse existing software we want software compatability.
	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.
	I'd suggest just doing (limited) UNix compatability since it's simpler.

	NOTE: The set of system calls offered isn't that important since
		(a) A programming language should offer it's own calls and
			let the implementation map them to the OS calls
		(b) One can provide libraries that give different 
			personalities
	      Likewise the UI isn't important since it can easily be replaced.
	      [Note: when I say not important here I mean not important to 
	       the design of the kernel and the essential OOness of the system]

	What is our audience? This will dictate whether we aim for multiuser 
		and security.

	BTW, just as asides... 
	(1) a small efficient unix compatibl OS *would* be useful.
	(2) We are not building another Xinu/Minix so simplicity is not 
		the most important thing
		(This is one thing I was wrong about earlier)

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

(4) Role of OO

There are a number of definitions of an OO OS.
	(a) OS is viewed as a running program in an OO language
	(b) replace the notion of a process and file by objects -- so we 
		have data and code toghether. This is examplified
		(at the UI level) by the Mac.
	(c) The OS is internally written in an OO language making maintenance
		simpler but not changing the interface --- this is NOT what
		we're after.

Suggstions:
	* 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.
	* How does adding classes/objects to the system work? 
		What kind of interface and functionality do we want/need?


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

(5) Suggested starting point for a design

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''

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.

I suggest we start with an existing OS (possibly VSTa) and add class/object 
support either at the kernel level or as a server.


-------------
References:
Self papers are available from 
	self.stanford.edu:pub/papers
VSTa is available from
	ftp.cygnus.com
	

Michael
winikoff@cs.mu.oz.au (mail to mulga still works, if you want to talk 
			to me try winikoff@munta.cs.mu.oz.au)

From rideau@mathp7.jussieu.fr Fri May 20 23:51:47 1994
Return-Path: <rideau@mathp7.jussieu.fr>
Received: from shiva.jussieu.fr by frmap711.mathp7.jussieu.fr (4.1/jn910403)
	  at Fri, 20 May 94 23:51:33 +0200
Received: from nef.ens.fr by shiva.jussieu.fr
	  (8.6.8/jtpda-4.0) with SMTP; Fri, 20 May 1994 23:53:04 +0200
Received: from clipper.ens.fr (clipper-gw.ens.fr) by nef.ens.fr (5.65c8/ULM-1.0)
	Id AA06737 ; Fri, 20 May 1994 23:51:25 +0200
Received: from nef.ens.fr by clipper.ens.fr (4.1/version 1.10 of 88/05/05)
 	id AA12638; Fri, 20 May 94 23:51:19 +0200
Received: from shiva.jussieu.fr by nef.ens.fr (5.65c8/ULM-1.0)
	Id AA06733 ; Fri, 20 May 1994 23:51:21 +0200
Received: from frmap711.mathp7.jussieu.fr by shiva.jussieu.fr
	  (8.6.8/jtpda-4.0) with SMTP; Fri, 20 May 1994 23:50:19 +0200
Received: by frmap711.mathp7.jussieu.fr (4.1/jn910403)
	  at Fri, 20 May 94 23:48:08 +0200
From: rideau@mathp7.jussieu.fr (Francois Rideau)
Message-Id: <9405202148.AA16524@frmap711.mathp7.jussieu.fr>
Subject: MOOSE [fare.02]
To: garfield@sra.com (David Garfield), winikoff@cs.mu.oz.au (Michael Winikoff),
        csjjlay@mtsu.edu (JJ Lay), rideau@ens.fr (Fare),
        ANDREASA@fenris.dhhalden.no (Andreas Arff),
        danodom@matt.ksu.ksu.edu (Dan Odom),
        dmarer@td2cad.intel.com (Dennis Marer),
        haydedr@wkuvx1.bitnet (Ross Hayden), mckeeveb@sfu.ca (Bob McKeever),
        newlin@ecn.purdue.edu (John Newlin)
Date: Fri, 20 May 94 23:48:07 MET DST
X-Mailer: ELM [version 2.3 PL11]
Status: OR

[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                                    /|\ /|\ /

From winikoff@cs.mu.oz.au Sat May 21 08:36:07 1994
Return-Path: <winikoff@cs.mu.oz.au>
Received: from shiva.jussieu.fr by frmap711.mathp7.jussieu.fr (4.1/jn910403)
	  at Sat, 21 May 94 08:36:01 +0200
Received: from mulga.cs.mu.OZ.AU by shiva.jussieu.fr
	  (8.6.8/jtpda-4.0) with SMTP; Sat, 21 May 1994 08:37:37 +0200
From: winikoff@cs.mu.oz.au
Received: from munta.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA28309
	Sat, 21 May 1994 16:35:50 +1000 (from winikoff)
Received: by munta.cs.mu.OZ.AU (8.6.8.1/slave-1.1)
	id QAA04890; Sat, 21 May 1994 16:35:50 +1000
Message-Id: <199405210635.4890@munta.cs.mu.OZ.AU>
Subject: Re: VSTa
To: rideau@mathp7.jussieu.fr (Francois Rideau)
Date: Sat, 21 May 94 16:35:50 EST
In-Reply-To: <9405202305.AA19389@frmap711.mathp7.jussieu.fr>; from "Francois Rideau" at May 21, 94 1:05 am
X-Mailer: ELM [version 2.3 PL11]
Status: OR

> 
> I could not find VSTa in ftp.cygnus.com;

I think its
ftp.cygnus.com:/vandys/vsta

> can you help me find it ?
> Thanks.
> 

I've printed out you're reply -- I'm busy at the moment (marking, finishingf
debugging some C (blech!) etc.) I should be able to finish reading it and 
replying before the end of the week.

BTW, I like having PROS and CONS ... good idea!

Michael


From newlin@lexmark.com Sun May 22 21:12:47 1994
Return-Path: <newlin@lexmark.com>
Received: from shiva.jussieu.fr by frmap711.mathp7.jussieu.fr (4.1/jn910403)
	  at Sun, 22 May 94 21:12:46 +0200
Received: from interlock.lexmark.com by shiva.jussieu.fr
	  (8.6.8/jtpda-4.0) with SMTP; Sun, 22 May 1994 21:14:18 +0200
Received: by interlock.lexmark.com id AA08943
  (InterLock SMTP Gateway 1.1 for rideau@mathp7.jussieu.fr);
  Sun, 22 May 1994 15:12:30 -0400
Received: by interlock.lexmark.com (Internal Mail Agent-1);
  Sun, 22 May 1994 15:12:30 -0400
From: newlin@lexmark.com (John Newlin)
Message-Id: <9405221909.AA23329@pad.prtdev.lexmark.com>
Subject: moosing
To: rideau@mathp7.jussieu.fr (Francois Rideau)
Date: Sun, 22 May 94 15:09:39 EDT
In-Reply-To: <9405202148.AA16524@frmap711.mathp7.jussieu.fr>; from "Francois Rideau" at May 20, 94 11:48 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

Fare,

  I hate to say it, but I've lost interest in moosing.

Good luck with the project!

Cheers,

-John


From dgodom@ksu.ksu.edu Sun May 22 21:35:39 1994
Return-Path: <dgodom@ksu.ksu.edu>
Received: from shiva.jussieu.fr by frmap711.mathp7.jussieu.fr (4.1/jn910403)
	  at Sun, 22 May 94 21:35:37 +0200
Received: from grunt.ksu.ksu.edu by shiva.jussieu.fr
	  (8.6.8/jtpda-4.0) with ESMTP; Sun, 22 May 1994 21:37:11 +0200
Received: from nbc.ksu.ksu.edu by grunt.ksu.ksu.edu (8.6.8/1.34)
	id OAA00693; Sun, 22 May 1994 14:35:28 -0500
From: dgodom@ksu.ksu.edu (Dob)
Received: by nbc.ksu.ksu.edu (8.6.8/1.34)
	id OAA19515; Sun, 22 May 1994 14:35:27 -0500
Message-Id: <199405221935.OAA19515@nbc.ksu.ksu.edu>
Subject: Re: MOOSE - ACK ???
To: rideau@mathp7.jussieu.fr (Francois Rideau)
Date: Sun, 22 May 1994 14:35:27 -0500 (CDT)
In-Reply-To: <9405220154.AA24966@frmap711.mathp7.jussieu.fr> from "Francois Rideau" at May 22, 94 03:54:30 am
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1228      
Status: OR


> The MOOSE project is (hopefully) being revived and reorganized in a more
> constructive way. If you can read this, can you mail me back to tell me
> if you will/won't/can't join ?
> Thank you, and good luck whatever you become.

Nifty.  I'd love to work on MOOSE;  I think that our main problem before
was that nobody knew what was going on :-)

As you apparantly know, my address has changed from danodom@ksu.ksu.edu
to dgodom@ksu.ksu.edu.  This account is liable to go bye-bye at any
time, though (it belongs to a relative), but if the MOOSE project
becomes a non-profit organization I can get more-or-less permanent
access to another set of machines (there is a policy at Fort Hays State
University that the members of any non-profit organization who live in
this county can gain access to computing resources for use in activities
related to their organization) (how was that for a run-on sentence? :-).

Anyway, count me in, for now.  I think that the members of the MOOSE
Project Mark II should all get together on IRC or something some time
soon to discuss organization, philosophy, and distribution of the work
load; if we are still going to split in to teams, I'd like to be on
the design team.

Later on,

---> Dan

From rideau@mathp7.jussieu.fr Tue May 24 20:27:44 1994
Return-Path: <rideau@mathp7.jussieu.fr>
Received: from shiva.jussieu.fr by frmap711.mathp7.jussieu.fr (4.1/jn910403)
	  at Tue, 24 May 94 20:27:30 +0200
Received: from nef.ens.fr by shiva.jussieu.fr
	  (8.6.8/jtpda-4.0) with SMTP; Tue, 24 May 1994 20:29:09 +0200
Received: from clipper.ens.fr (clipper-gw.ens.fr) by nef.ens.fr (5.65c8/ULM-1.0)
	Id AA07817 ; Tue, 24 May 1994 20:27:27 +0200
Received: from nef.ens.fr by clipper.ens.fr (4.1/version 1.10 of 88/05/05)
 	id AA07949; Tue, 24 May 94 20:27:24 +0200
Received: from shiva.jussieu.fr by nef.ens.fr (5.65c8/ULM-1.0)
	Id AA07809 ; Tue, 24 May 1994 20:27:25 +0200
Received: from frmap711.mathp7.jussieu.fr by shiva.jussieu.fr
	  (8.6.8/jtpda-4.0) with SMTP; Tue, 24 May 1994 20:28:10 +0200
Received: by frmap711.mathp7.jussieu.fr (4.1/jn910403)
	  at Tue, 24 May 94 20:26:13 +0200
From: rideau@mathp7.jussieu.fr (Francois Rideau)
Message-Id: <9405241826.AA22459@frmap711.mathp7.jussieu.fr>
Subject: Meeting on Saturday 01:00 am GMT ?
To: david@davgar.arlington.va.us (David Garfield),
        winikoff@cs.mu.oz.au (Michael Winikoff), csjjlay@mtsu.edu (JJ Lay),
        dgodom@nbc.ksu.ksu.edu (Dan Odom), rideau@ens.fr (Fare),
        ANDREASA@fenris.dhhalden.no (Andreas Arff),
        dmarer@intel.com (Dennis Marer), haydedr@wkuvx1.bitnet (Ross Hayden),
        BobMcKee@mathp7.jussieu.fr
Date: Tue, 24 May 94 20:26:12 MET DST
X-Mailer: ELM [version 2.3 PL11]
Status: OR

I think it's time for a MOOSE meeting on IRC.

Here is a first scheduling for a Rendez-vous:
	Saturday May 28 01:00am GMT.
(!) That's
	Friday May 27 8:00pm or 9:00pm for our American friends,
	Saturday May 28 11:00am in Australia for Michael,
and	Saturday May 28 03:00am in France for Me )-8

So please tell me if you can or not connect, if you suggest another schedule,
etc. 

Also state your usual (or to be usual) IRC nickname (first try to connect
IRC), and/or possible talk address, so perhaps we can meet beforehand.
[MY irc nickname is "Fare", and my talkable address is rideau@frmap711...
see below]

As for anything you may have missed, you can get it by anonymous ftp at
frmap711.mathp7.jussieu.fr in pub/scratch/rideau/moose.

P.S.: Here is a exerpt from the MOOSE files.
------------------------------------------------------------------------------
[MOOSE People]
Have answered positively:
- winikoff@munta.cs.mu.oz.au (Michael Winikoff)
- csjjlay@mtsu.edu (JJ. Lay)
- david@davgar.arlington.va.us (David Garfield)
- dgodom@nbc.ksu.ksu.edu (Dan Odom)
- rideau@clipper.ens.fr (Fare Rideau) (me)
Hey ! That's only five of us !

Have answered negatively:
- Gary D. Duzan (gary@dsh.org), now uses 386 NetBSD
- Peter Mueller (mueller@sc.ZIB-Berlin.DE)
- John Newlin (newlin@ecn.purdue.edu)

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

Could not be joined:
- Dennis Marer (was dmarer@td2cad.intel.com)
- Andreas Arff (was ANDREASA@fenris.dhhalden.no)
- Rob McKeever (was mckeeveb@sfu.ca)
- Dr. Ross Hayden (was haydedr@wkuvx1.bitnet)

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

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

From winikoff@cs.mu.oz.au Wed May 25 06:51:49 1994
Return-Path: <winikoff@cs.mu.oz.au>
Received: from shiva.jussieu.fr by frmap711.mathp7.jussieu.fr (4.1/jn910403)
	  at Wed, 25 May 94 06:51:37 +0200
Received: from mulga.cs.mu.OZ.AU by shiva.jussieu.fr
	  (8.6.8/jtpda-4.0) with SMTP; Wed, 25 May 1994 06:53:16 +0200
From: winikoff@cs.mu.oz.au
Received: from munta.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA00777
	Wed, 25 May 1994 14:51:14 +1000 (from winikoff)
Received: by munta.cs.mu.OZ.AU (8.6.8.1/slave-1.1)
	id OAA09939; Wed, 25 May 1994 14:51:12 +1000
Message-Id: <199405250451.9939@munta.cs.mu.OZ.AU>
Subject: Re: Meeting on Saturday 01:00 am GMT ?
To: rideau@mathp7.jussieu.fr (Francois Rideau)
Date: Wed, 25 May 94 14:51:11 EST
In-Reply-To: <9405241826.AA22459@frmap711.mathp7.jussieu.fr>; from "Francois Rideau" at May 24, 94 8:26 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

> 
> I think it's time for a MOOSE meeting on IRC.
> 
> Here is a first scheduling for a Rendez-vous:
> 	Saturday May 28 01:00am GMT.
> (!) That's
> 	Friday May 27 8:00pm or 9:00pm for our American friends,
> 	Saturday May 28 11:00am in Australia for Michael,

I've got a rehearsal from 10-12.


> and	Saturday May 28 03:00am in France for Me )-8
> 
> So please tell me if you can or not connect, if you suggest another schedule,

irc isn't installed on our machines.

> etc. 
> 
> Also state your usual (or to be usual) IRC nickname (first try to connect
> IRC), and/or possible talk address, so perhaps we can meet beforehand.
> [MY irc nickname is "Fare", and my talkable address is rideau@frmap711...
> see below]
> 
> As for anything you may have missed, you can get it by anonymous ftp at
> frmap711.mathp7.jussieu.fr in pub/scratch/rideau/moose.
> 
> P.S.: Here is a exerpt from the MOOSE files.
> ------------------------------------------------------------------------------
> [MOOSE People]
> Have answered positively:
> - winikoff@munta.cs.mu.oz.au (Michael Winikoff)
> - csjjlay@mtsu.edu (JJ. Lay)
> - david@davgar.arlington.va.us (David Garfield)
> - dgodom@nbc.ksu.ksu.edu (Dan Odom)
> - rideau@clipper.ens.fr (Fare Rideau) (me)
> Hey ! That's only five of us !
> 
> Have answered negatively:
> - Gary D. Duzan (gary@dsh.org), now uses 386 NetBSD
> - Peter Mueller (mueller@sc.ZIB-Berlin.DE)
> - John Newlin (newlin@ecn.purdue.edu)
> 
> Have not answered:
> - All the others (in particular Dennis 8(
> 
> Could not be joined:
> - Dennis Marer (was dmarer@td2cad.intel.com)
> - Andreas Arff (was ANDREASA@fenris.dhhalden.no)
> - Rob McKeever (was mckeeveb@sfu.ca)
> - Dr. Ross Hayden (was haydedr@wkuvx1.bitnet)
> 
> ------------------------------------------------------------------------------
> 
> --    ,        	                                ,           _ 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                                    /|\ /|\ /
> 

________________________________________________________________________________
Michael Winikoff 		winikoff@cs.mu.oz.au
Computer science postgrad. University of Melbourne, Australia. 	
CC/B1 iv++ u c 2/2/2 r f+ h p o+ s+ d y? PDS CWF 
Todays Syllogism:
	A. That which the vast majority does is, by definition, mediocre.
	B. The vast majority of programming is done in C today.
	C. Ergo, C programming is mediocrity.


From mckeeveb@sfu.ca Wed May 25 07:36:10 1994
Return-Path: <mckeeveb@sfu.ca>
Received: from shiva.jussieu.fr by frmap711.mathp7.jussieu.fr (4.1/jn910403)
	  at Wed, 25 May 94 07:35:52 +0200
Received: from nef.ens.fr by shiva.jussieu.fr
	  (8.6.8/jtpda-4.0) with SMTP; Wed, 25 May 1994 07:37:33 +0200
Received: from clipper.ens.fr (clipper-gw.ens.fr) by nef.ens.fr (5.65c8/ULM-1.0)
	Id AA23520 ; Wed, 25 May 1994 07:35:50 +0200
Received: from nef.ens.fr by clipper.ens.fr (4.1/version 1.10 of 88/05/05)
 	id AA10511; Wed, 25 May 94 07:35:49 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
	Id AA23516 ; Wed, 25 May 1994 07:35:47 +0200
Received: from mulga.cs.mu.OZ.AU (mulga.cs.mu.OZ.AU [128.250.1.22]) by whistler.sfu.ca with SMTP (8.6.8/SFU-2.6H)
  id WAA08518 for <moose-programmers@sfu.ca> (from winikoff@cs.mu.OZ.AU); Tue, 24 May 1994 22:33:31 -0700
From: <winikoff@cs.mu.oz.au>
Received: from munta.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA03073
	Wed, 25 May 1994 15:32:56 +1000 (from winikoff)
Received: by munta.cs.mu.OZ.AU (8.6.8.1/slave-1.1)
	id PAA12993; Wed, 25 May 1994 15:32:55 +1000
Message-Id: <199405250532.12993@munta.cs.mu.OZ.AU>
Subject: Reply to the reply
To: moose-programmers@sfu.ca (Moose)
Date: Wed, 25 May 94 15:32:54 EST
Cc: rideau@ens.fr (fare)
X-Mailer: ELM [version 2.3 PL11]
Status: OR



Hi!

I've read through your mail.

IMHO the fundamental shift is from viewing a program as something which starts
executiong at a "main()" to something that offers a number of entry points.

This is essentially an ADT.

This can be built on top of an existing OS by using a library.

This could also be done by designing a language that provided this facility.

Ie. Language OR OS are both valid solutions.

TRadeoffs:

Language:
	* Cleaner
	* Less low level work
	* Nicer sementics for data sharing 
	* Can't reuse code in other languages
	* Doesn't require designing a common format for ADTs
OS:
	* Lower level
	* Data passing is limited to primitive types (int, char, float, bool)
	* Can use code from any language (well, the compiler has to be modifeid
		to generate ADT formats rather than normal executbls)
	* We need a format for communicating ADTs -- what operations they
		allow, what types these operations take etc.

Attempting to achieve fine grain objects in an OS approach requires solving the
problem of sharing non primitive data between ADTs written in different 
languages -- this is tricky (ie a research area)


Other comments .... having transparent backing store would be nice BUT would
be hell for recoverability/reliabilty/robustness -- unless extreme care is taken
with recovery any system crash could leave the machine unbootable ...

Note that APIs and UIs are interchangeable in modern OS'es so more and more the
OS is becoming irrelevant to the user ... the two "features" that can't be 
achieved by layering another API/UI on top and which are important are:
	SECURITY
	RELIABILITY/ROBUSTNESS
	EFFICIENCY

Thus (assuming we choose to take the OS approach rather than the language one)
if we take a base OS that is efficient, reliable and secure then adding a 
library would probly give us 90% of what we want.

Michael
PS. For examples of systems based on the language approach see LISP machines,
FORTH machines, the smalltalk environment, Logix, even BASIC machines :-)


From rideau@mathp7.jussieu.fr Fri May 27 01:20:07 1994
Return-Path: <rideau@mathp7.jussieu.fr>
Received: from shiva.jussieu.fr by frmap711.mathp7.jussieu.fr (4.1/jn910403)
	  at Fri, 27 May 94 01:19:48 +0200
Received: from nef.ens.fr by shiva.jussieu.fr
	  (8.6.8/jtpda-4.0) with SMTP; Fri, 27 May 1994 01:21:29 +0200
Received: from clipper.ens.fr (clipper-gw.ens.fr) by nef.ens.fr (5.65c8/ULM-1.0)
	Id AA05808 ; Fri, 27 May 1994 01:19:46 +0200
Received: from nef.ens.fr by clipper.ens.fr (4.1/version 1.10 of 88/05/05)
 	id AA27416; Fri, 27 May 94 01:19:41 +0200
Received: from shiva.jussieu.fr by nef.ens.fr (5.65c8/ULM-1.0)
	Id AA05802 ; Fri, 27 May 1994 01:19:43 +0200
Received: from frmap711.mathp7.jussieu.fr by shiva.jussieu.fr
	  (8.6.8/jtpda-4.0) with SMTP; Fri, 27 May 1994 01:18:29 +0200
Received: by frmap711.mathp7.jussieu.fr (4.1/jn910403)
	  at Fri, 27 May 94 01:16:07 +0200
From: rideau@mathp7.jussieu.fr (Francois Rideau)
Message-Id: <9405262316.AA06581@frmap711.mathp7.jussieu.fr>
Subject: Re: Language or OS ?
To: winikoff@cs.mu.oz.au
Date: Fri, 27 May 94 1:16:07 MET DST
Cc: garfield@verdi.sra.com (David Garfield),
        winikoff@cs.mu.oz.au (Michael Winikoff), csjjlay@mtsu.edu (JJ Lay),
        dgodom@nbc.ksu.ksu.edu (Dan Odom), rideau@ens.fr (Fare),
        ANDREASA@fenris.dhhalden.no (Andreas Arff),
        dmarer@intel.com (Dennis Marer), haydedr@wkuvx1.bitnet (Ross Hayden),
        mckeeveb@sfu.ca (Rob McKeever), moose-programmers@sfu.ca
In-Reply-To: <199405250532.12993@munta.cs.mu.OZ.AU>; from "winikoff@cs.mu.oz.au" at May 25, 94 3:32 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

> IMHO the fundamental shift is from viewing a program as something which
> starts
> executiong at a "main()" to something that offers a number of entry points.
> 
> This is essentially an ADT.

There are discussions at my school about what OO means. It seems from what
they say that OO can provide more than ADTs, by means of genericity --
higher order programming.


> This can be built on top of an existing OS by using a library.
This would be more than a library -- a full runtime & compiler.

> This could also be done by designing a language that provided this facility.


> Ie. Language OR OS are both valid solutions.
> 
> TRadeoffs:
> 
> Language:
Working on TOP of an existing OS (aka Unix clone):
> 	* Cleaner
	Using (being built on top of) the semantics for "C" memory management
	is anything but clean.
> 	* Less low level work
	Translating Unix calls to OO calls __will__ be some kind of low-level
	stuff.
> 	* Nicer semantics for data sharing 
	Why ? The language semantics are the same anyway !
> 	* Can't reuse code in other languages
	Yes and no -- you can externally link the runtime with outer modules.
> 	* Doesn't require designing a common format for ADTs
	It still does.

> OS:
(i.e. rewriting the low-level management of interobject communication &
mutual protection).

> 	* Lower level
	Yeah, very dirty, unportable work.
	more time before a first workable version comes out, but then its
	cleaner.
	* __much__ quicker (?) on the machine where it is implemented,
	__much__ lower (i.e. null speed) on any other.
> 	* Data passing is limited to primitive types (int, char, float, bool)
	Why so ? The system can be layered so 
> 	* Can use code from any language (well, the compiler has to be modifeid
> 		to generate ADT formats rather than normal executbls)
> 	* We need a format for communicating ADTs -- what operations they
> 		allow, what types these operations take etc.
	We do need one anyway.


> Attempting to achieve fine grain objects in an OS approach requires 
> solving the
> problem of sharing non primitive data between ADTs written in different 
> languages -- this is tricky (ie a research area)
No problem if _we_ provide the right compilers (could be all using the same
back-end).
Even ANSI "C" allows enhanced restrictions (no pointer arithmetic outside
a allocated array, and such things).

> Other comments .... having transparent backing store would be nice BUT would
> be hell for recoverability/reliabilty/robustness -- unless extreme care is
> taken
> with recovery any system crash could leave the machine unbootable ...
It's fairly possible to have a transactional persistent object (file) system:
do not validate a change before it is complete (i.e. leaves the machine in a
valid state). Databases do it everyday, why not us ?


> Note that APIs and UIs are interchangeable in modern OS'es so more and
> more the
> OS is becoming irrelevant to the user ... the two "features" that can't be 
> achieved by layering another API/UI on top and which are important are:
> 	SECURITY
> 	RELIABILITY/ROBUSTNESS
> 	EFFICIENCY


> Thus (assuming we choose to take the OS approach rather than the language one)
> if we take a base OS that is efficient, reliable and secure then adding a 
> library would probly give us 90% of what we want.

  I think both approaches are feasible and interesting. The solution should be
voted after all the members have exposed the condition in which they can work
on either solution.
  In either case, we'll have to provide language service to the OS, or to
simulate OS service in the language run-time, so this really is a policy
question.

  The more important question is
*IS THERE ALREADY A LANGUAGE THAT FITS OUR REQUIREMENTS ?*
  What about Ellie, Sather, Eiffel, a FORTH or Postscript extension,
smalltalk, SML or CAML, Lisp or Scheme and so on ?


> Michael



From mckeeveb@sfu.ca Fri May 27 01:23:53 1994
Return-Path: <mckeeveb@sfu.ca>
Received: from shiva.jussieu.fr by frmap711.mathp7.jussieu.fr (4.1/jn910403)
	  at Fri, 27 May 94 01:23:27 +0200
Received: from nef.ens.fr by shiva.jussieu.fr
	  (8.6.8/jtpda-4.0) with SMTP; Fri, 27 May 1994 01:25:09 +0200
Received: from clipper.ens.fr (clipper-gw.ens.fr) by nef.ens.fr (5.65c8/ULM-1.0)
	Id AA05837 ; Fri, 27 May 1994 01:23:26 +0200
Received: from nef.ens.fr by clipper.ens.fr (4.1/version 1.10 of 88/05/05)
 	id AA27469; Fri, 27 May 94 01:23:21 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
	Id AA05833 ; Fri, 27 May 1994 01:23:23 +0200
Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by whistler.sfu.ca with ESMTP (8.6.8/SFU-2.6H)
  id QAA17442 (from rideau@mathp7.jussieu.fr); Thu, 26 May 1994 16:17:26 -0700
Received: from frmap711.mathp7.jussieu.fr by shiva.jussieu.fr
	  (8.6.8/jtpda-4.0) with SMTP; Fri, 27 May 1994 01:18:29 +0200
Received: by frmap711.mathp7.jussieu.fr (4.1/jn910403)
	  at Fri, 27 May 94 01:16:07 +0200
From: rideau@mathp7.jussieu.fr (Francois Rideau)
Message-Id: <9405262316.AA06581@frmap711.mathp7.jussieu.fr>
Subject: Re: Language or OS ?
To: winikoff@cs.mu.oz.au
Date: Fri, 27 May 94 1:16:07 MET DST
Cc: garfield@verdi.sra.com (David Garfield),
        winikoff@cs.mu.oz.au (Michael Winikoff), csjjlay@mtsu.edu (JJ Lay),
        dgodom@nbc.ksu.ksu.edu (Dan Odom), rideau@ens.fr (Fare),
        ANDREASA@fenris.dhhalden.no (Andreas Arff),
        dmarer@intel.com (Dennis Marer), haydedr@wkuvx1.bitnet (Ross Hayden),
        mckeeveb@sfu.ca (Rob McKeever), moose-programmers@sfu.ca
In-Reply-To: <199405250532.12993@munta.cs.mu.OZ.AU>; from "winikoff@cs.mu.oz.au" at May 25, 94 3:32 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

> IMHO the fundamental shift is from viewing a program as something which
> starts
> executiong at a "main()" to something that offers a number of entry points.
> 
> This is essentially an ADT.

There are discussions at my school about what OO means. It seems from what
they say that OO can provide more than ADTs, by means of genericity --
higher order programming.


> This can be built on top of an existing OS by using a library.
This would be more than a library -- a full runtime & compiler.

> This could also be done by designing a language that provided this facility.


> Ie. Language OR OS are both valid solutions.
> 
> TRadeoffs:
> 
> Language:
Working on TOP of an existing OS (aka Unix clone):
> 	* Cleaner
	Using (being built on top of) the semantics for "C" memory management
	is anything but clean.
> 	* Less low level work
	Translating Unix calls to OO calls __will__ be some kind of low-level
	stuff.
> 	* Nicer semantics for data sharing 
	Why ? The language semantics are the same anyway !
> 	* Can't reuse code in other languages
	Yes and no -- you can externally link the runtime with outer modules.
> 	* Doesn't require designing a common format for ADTs
	It still does.

> OS:
(i.e. rewriting the low-level management of interobject communication &
mutual protection).

> 	* Lower level
	Yeah, very dirty, unportable work.
	more time before a first workable version comes out, but then its
	cleaner.
	* __much__ quicker (?) on the machine where it is implemented,
	__much__ lower (i.e. null speed) on any other.
> 	* Data passing is limited to primitive types (int, char, float, bool)
	Why so ? The system can be layered so 
> 	* Can use code from any language (well, the compiler has to be modifeid
> 		to generate ADT formats rather than normal executbls)
> 	* We need a format for communicating ADTs -- what operations they
> 		allow, what types these operations take etc.
	We do need one anyway.


> Attempting to achieve fine grain objects in an OS approach requires 
> solving the
> problem of sharing non primitive data between ADTs written in different 
> languages -- this is tricky (ie a research area)
No problem if _we_ provide the right compilers (could be all using the same
back-end).
Even ANSI "C" allows enhanced restrictions (no pointer arithmetic outside
a allocated array, and such things).

> Other comments .... having transparent backing store would be nice BUT would
> be hell for recoverability/reliabilty/robustness -- unless extreme care is
> taken
> with recovery any system crash could leave the machine unbootable ...
It's fairly possible to have a transactional persistent object (file) system:
do not validate a change before it is complete (i.e. leaves the machine in a
valid state). Databases do it everyday, why not us ?


> Note that APIs and UIs are interchangeable in modern OS'es so more and
> more the
> OS is becoming irrelevant to the user ... the two "features" that can't be 
> achieved by layering another API/UI on top and which are important are:
> 	SECURITY
> 	RELIABILITY/ROBUSTNESS
> 	EFFICIENCY


> Thus (assuming we choose to take the OS approach rather than the language one)
> if we take a base OS that is efficient, reliable and secure then adding a 
> library would probly give us 90% of what we want.

  I think both approaches are feasible and interesting. The solution should be
voted after all the members have exposed the condition in which they can work
on either solution.
  In either case, we'll have to provide language service to the OS, or to
simulate OS service in the language run-time, so this really is a policy
question.

  The more important question is
*IS THERE ALREADY A LANGUAGE THAT FITS OUR REQUIREMENTS ?*
  What about Ellie, Sather, Eiffel, a FORTH or Postscript extension,
smalltalk, SML or CAML, Lisp or Scheme and so on ?


> Michael



From winikoff@cs.mu.oz.au Fri May 27 05:41:25 1994
Return-Path: <winikoff@cs.mu.oz.au>
Received: from shiva.jussieu.fr by frmap711.mathp7.jussieu.fr (4.1/jn910403)
	  at Fri, 27 May 94 05:41:19 +0200
Received: from mulga.cs.mu.OZ.AU by shiva.jussieu.fr
	  (8.6.8/jtpda-4.0) with SMTP; Fri, 27 May 1994 05:42:59 +0200
From: winikoff@cs.mu.oz.au
Received: from munta.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA11848
	Fri, 27 May 1994 13:41:07 +1000 (from winikoff)
Received: by munta.cs.mu.OZ.AU (8.6.8.1/slave-1.1)
	id NAA09399; Fri, 27 May 1994 13:41:05 +1000
Message-Id: <199405270341.9399@munta.cs.mu.OZ.AU>
Subject: Re: Meeting on Saturday ?
To: rideau@mathp7.jussieu.fr (Francois Rideau)
Date: Fri, 27 May 94 13:41:05 EST
In-Reply-To: <9405262255.AA06543@frmap711.mathp7.jussieu.fr>; from "Francois Rideau" at May 27, 94 12:55 am
X-Mailer: ELM [version 2.3 PL11]
Status: OR

> 
> >> I think it's time for a MOOSE meeting on IRC.
> >> 
> >> Here is a first scheduling for a Rendez-vous:
> >> 	Saturday May 28 01:00am GMT.
> >> (!) That's
> >> 	Friday May 27 8:00pm or 9:00pm for our American friends,
> >> 	Saturday May 28 11:00am in Australia for Michael,
> >
> > I've got a rehearsal from 10-12.
> Can it be done sooner ?

Not really -- I've got a rehearsal tonight too ...
the week before concerts are allways a bad time ... :-)

> E.g., two hours sooner, that is Friday, 23:00 GMT ?
> later would be hard for our american friends (please answer, US MOOSErs !).
> 
> As the list (moose-programmers@sfu.ca) may
> 
> > irc isn't installed on our machines.
>   Ahem. What type of machine is it ?

I've got access to SGIs and various Suns (workstations and servers)
Also DECstations.

>   Well, after all you should recompile anyway.
>   All you need is being able to telnet your nearest irc server (I dunno what
> it is -- it's in australia; but you can always connect to sil.polytechnique.fr
> if to nothing else).

I'm not going to have time to do this before saturday.
:-(


From winikoff@cs.mu.oz.au Fri May 27 05:53:10 1994
Return-Path: <winikoff@cs.mu.oz.au>
Received: from shiva.jussieu.fr by frmap711.mathp7.jussieu.fr (4.1/jn910403)
	  at Fri, 27 May 94 05:53:02 +0200
Received: from mulga.cs.mu.OZ.AU by shiva.jussieu.fr
	  (8.6.8/jtpda-4.0) with SMTP; Fri, 27 May 1994 05:54:39 +0200
From: winikoff@cs.mu.oz.au
Received: from munta.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA12256
	Fri, 27 May 1994 13:52:44 +1000 (from winikoff)
Received: by munta.cs.mu.OZ.AU (8.6.8.1/slave-1.1)
	id NAA10054; Fri, 27 May 1994 13:52:43 +1000
Message-Id: <199405270352.10054@munta.cs.mu.OZ.AU>
Subject: Re: Language or OS ?
To: rideau@mathp7.jussieu.fr (Francois Rideau)
Date: Fri, 27 May 94 13:52:42 EST
In-Reply-To: <9405262316.AA06581@frmap711.mathp7.jussieu.fr>; from "Francois Rideau" at May 27, 94 1:16 am
X-Mailer: ELM [version 2.3 PL11]
Status: OR

> 
> > IMHO the fundamental shift is from viewing a program as something which
> > starts
> > executiong at a "main()" to something that offers a number of entry points.
> > 
> > This is essentially an ADT.
> 
> There are discussions at my school about what OO means. It seems from what
> they say that OO can provide more than ADTs, by means of genericity --
> higher order programming.

Examples? Please?
My understanding is that "OO = ADT + Inheritance"

> 
> 
> > This can be built on top of an existing OS by using a library.
> This would be more than a library -- a full runtime & compiler.

Why?

> 
> > This could also be done by designing a language that provided this facility.
> 
> 
> > Ie. Language OR OS are both valid solutions.
> > 
> > TRadeoffs:
> > 
> > Language:
> Working on TOP of an existing OS (aka Unix clone):

No, the underlying OS is irrelavent -- in a highlevel language you don't often
direcly use UNix system calls, likewise, in a safe language (eg ML) run time
errors do not occur so the lack of protection is not an issue.

> > 	* Cleaner
> 	Using (being built on top of) the semantics for "C" memory management
> 	is anything but clean.
> > 	* Less low level work
> 	Translating Unix calls to OO calls __will__ be some kind of low-level
> 	stuff.
> > 	* Nicer semantics for data sharing 
> 	Why ? The language semantics are the same anyway !

As compared with having multiple languages -- in a (eg) LISP machines I can 
pass lists around. In an OS you need to somehow pass around data that will
make senseto programs written in Prolog, ML, C++ and Oberon ...

> > 	* Can't reuse code in other languages
> 	Yes and no -- you can externally link the runtime with outer modules.

Sorry, me being unclear -- I meant "reuse" in the sense of being first
class citizens -- being able to have *objects* written  in other languages.

> > 	* Doesn't require designing a common format for ADTs
> 	It still does.

But it's internal to the implementation.

> 
> > OS:
> (i.e. rewriting the low-level management of interobject communication &
> mutual protection).
> 
> > 	* Lower level
> 	Yeah, very dirty, unportable work.
> 	more time before a first workable version comes out, but then its
> 	cleaner.
> 	* __much__ quicker (?) on the machine where it is implemented,
> 	__much__ lower (i.e. null speed) on any other.
> > 	* Data passing is limited to primitive types (int, char, float, bool)
> 	Why so ? The system can be layered so 

How? 
You can have OBJECTS representing compound data structure and pass references
to these objects around.
You can't pass raw data that's compound though.

> > 	* Can use code from any language (well, the compiler has to be modifeid
> > 		to generate ADT formats rather than normal executbls)
> > 	* We need a format for communicating ADTs -- what operations they
> > 		allow, what types these operations take etc.
> 	We do need one anyway.
> 
> 
> > Attempting to achieve fine grain objects in an OS approach requires 
> > solving the
> > problem of sharing non primitive data between ADTs written in different 
> > languages -- this is tricky (ie a research area)
> No problem if _we_ provide the right compilers (could be all using the same
> back-end).
> Even ANSI "C" allows enhanced restrictions (no pointer arithmetic outside
> a allocated array, and such things).
> 
> > Other comments .... having transparent backing store would be nice BUT would
> > be hell for recoverability/reliabilty/robustness -- unless extreme care is
> > taken
> > with recovery any system crash could leave the machine unbootable ...
> It's fairly possible to have a transactional persistent object (file) system:
> do not validate a change before it is complete (i.e. leaves the machine in a
> valid state). Databases do it everyday, why not us ?

Yes.
It's yet more work though ...
Also, you need to have applications be aware of the system and let the system
know when they've finished a change and it can be committed...

One thing that would be nice to get right is file locking -- Unix semantics
are disgusting. The Amiga gets it right.

> 
> 
> > Note that APIs and UIs are interchangeable in modern OS'es so more and
> > more the
> > OS is becoming irrelevant to the user ... the two "features" that can't be 
> > achieved by layering another API/UI on top and which are important are:
> > 	SECURITY
> > 	RELIABILITY/ROBUSTNESS
> > 	EFFICIENCY
> 
> 
> > Thus (assuming we choose to take the OS approach rather than the language one)
> > if we take a base OS that is efficient, reliable and secure then adding a 
> > library would probly give us 90% of what we want.
> 
>   I think both approaches are feasible and interesting. The solution should be
> voted after all the members have exposed the condition in which they can work
> on either solution.
>   In either case, we'll have to provide language service to the OS, or to
> simulate OS service in the language run-time, so this really is a policy
> question.

It makes a lot of difference -- the OS way involves a lot more work because 
were starting from bare metal.
By building on top of an OS we start at a high level -- this does mean some 
things won't be doable but it saves us a lot of time.

Another p[ossibility is to take the language approach as a "fast prototype"
for the final product which would be an OS ... comments?

> 
>   The more important question is
> *IS THERE ALREADY A LANGUAGE THAT FITS OUR REQUIREMENTS ?*
>   What about Ellie, Sather, Eiffel, a FORTH or Postscript extension,
> smalltalk, SML or CAML, Lisp or Scheme and so on ?

Depends on the actual requirements.
For instance, is safety a requirement? If so, LISP/Scheme/Smalltalk/etc. fail.
I think some of the languages come quite close.

Next things to do:
(1) More debate :-)
(2) Forming a list of requirements for languages (and for the OS version?)


> 
> 
> > Michael
> 
> 


From dgodom@ksu.ksu.edu Sun May 29 23:38:38 1994
Return-Path: <dgodom@ksu.ksu.edu>
Received: from shiva.jussieu.fr by frmap711.mathp7.jussieu.fr (4.1/jn910403)
	  at Sun, 29 May 94 23:38:26 +0200
Received: from grunt.ksu.ksu.edu by shiva.jussieu.fr
	  (8.6.8/jtpda-4.0) with ESMTP; Sun, 29 May 1994 23:40:10 +0200
Received: from nbc.ksu.ksu.edu by grunt.ksu.ksu.edu (8.6.8/1.34)
	id QAA00534; Sun, 29 May 1994 16:38:21 -0500
From: dgodom@ksu.ksu.edu (Dob)
Received: by nbc.ksu.ksu.edu (8.6.8/1.34)
	id QAA07355; Sun, 29 May 1994 16:38:20 -0500
Message-Id: <199405292138.QAA07355@nbc.ksu.ksu.edu>
Subject: Re: MOOSE - ACK ???
To: rideau@mathp7.jussieu.fr (Francois Rideau)
Date: Sun, 29 May 1994 16:38:20 -0500 (CDT)
In-Reply-To: <9405241736.AA21369@frmap711.mathp7.jussieu.fr> from "Francois Rideau" at May 24, 94 07:36:24 pm
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1047      
Status: OR


>   Currently, only 5 members have answered positively (4 answered negatively),
> the others couldn't be joined or did not asnwer, particularly Dennis. You
> can find all the info about MOOSE by anonymous ftp on
> frmap711.mathp7.jussieu.fr in pub/scratch/rideau/moose.

Unfortunately, I was informed of a possible job opportunity about an hour
after I told you I was free to do MOOSE :-(  :-)  :-|.  I may still
be able to, even if I gain employment;  I'll know within two weeks.

> That's what I'm up to, but the problem is Michael Winikoff is in Australia,
> while I'm in Europe and everybody else in the states. Can you be logged
> on friday, around 9 pm ? It will be on #MOOSE, or #_MOOSE if the usual
> squatter (ircnick: moose) sets up his private invite-only channel.
> You can contact me as Fare if I'm logged in (/msg Fare Hello !^G^G^G^G^G).

Well, heh, I could have been, but I didn't log on last week for the above-
mentioned reason and didn't get the notice until today; sorry :-(.

BTW, Fare, were you a #unix regular at one time?

From rideau Mon May 30 16:44:59 1994
Return-Path: <rideau>
Received: by frmap711.mathp7.jussieu.fr (4.1/jn910403)
	  at Mon, 30 May 94 16:44:55 +0200
From: rideau (Francois Rideau)
Message-Id: <9405301444.AA11731@frmap711.mathp7.jussieu.fr>
Subject: Re: MOOSE - ACK
To: dgodom@ksu.ksu.edu (Dob)
Date: Mon, 30 May 94 16:44:55 MET DST
Cc: rideau (Francois Rideau)
In-Reply-To: <199405292138.QAA07355@nbc.ksu.ksu.edu>; from "Dob" at May 29, 94 4:38 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

> Well, heh, I could have been, but I didn't log on last week for the above-
> mentioned reason and didn't get the notice until today; sorry :-(.
> 
Unfortunately, the meeting couldn't be done anyway )-8

> BTW, Fare, were you a #unix regular at one time?
Err, I've been there some time, but the traffic is now on #root instead.
Find me with /w Fare (or Fare- if someone else is Fare, which never happened),
or on #MOOSE (or #_MOOSE ?). I also join #linux, #root or #unix sometimes.

Well, whatever happens, to you and/or to MOOSE, good luck !


From rideau Tue May 31 08:35:56 1994
Subject: Re: Language or OS ?
To: winikoff@cs.mu.oz.au
Date: Tue, 31 May 94 8:35:56 MET DST
In-Reply-To: <199405270352.10054@munta.cs.mu.OZ.AU>; from "winikoff@cs.mu.oz.au" at May 27, 94 1:52 pm
X-Mailer: ELM [version 2.3 PL11]

------------------------------------------------------------------------------
If you don't have time to read a section, read it later, but you can
skip it and read next section.

------------------------------------------------------------------------------
[MOOSE status]

Only Michael and I are currently speaking in channel MOOSE.

Three (3) other people are reported to read.
So what do you all think about the discussion ? Do you approve ?
Can you connect on IRC ? If yes, when ? What is your common nickname ?

I think we must soon repost a message in the news to renew the team.
How would you modify the current Manifesto ?
What Language and/or OS requirements are yours ?


------------------------------------------------------------------------------
[reply to Michael]

">>>" is Michael Winikoff
">>" is me
">" is Michael again


>>> IMHO the fundamental shift is from viewing a program as something which
>>> starts
>>> executiong at a "main()" to something that offers a number of entry points.
>>> 
>>> This is essentially an ADT.
(yes).
>> There are discussions at my school about what OO means. It seems from what
>> they say that OO can provide more than ADTs, by means of genericity --
>> higher order programming.

> Examples? Please?
> My understanding is that "OO = ADT + Inheritance"

Ahem.
I'm writing for my school a "Why OO ?" file that I'll put in the frmap711
anonymous ftp site (pub/scratch/rideau/moose/papers) tonight. Tell me if you
prefer that I post it.

As for Genericity, ADT's are all the low-level "OS" part of MOOSE need to
recognize. Genericity as attained at the Language level (of course, the
low-level must be such that the implementation be efficient).



>>> This can be built on top of an existing OS by using a library.
>> This would be more than a library -- a full runtime & compiler.
> Why?

  Because we can't just provide low-level message-passing without an interface
to use it.
  With respect to this, VSTa is currently a nice, but quite unusable, and
perhaps even ridiculous system ! I don't even know if its message passing
semantics is good, because I can't use it ! As for the implementation,
using "C" main() multiplexing is as yechy as OO programming can be. And as
for efficiency, having a "C" program with its own main() for each object in
the system will prove quite inefficient.

  Thus, in any case, an OO (Operating) System with any will of efficiency
and/or usability should provide a human-accessible interface to its OO
features. Such interface _IS_ a language. Implementing it _IS_ providing
a full runtime and compiler for the language, whatever language it is.
Of course you can choose as a language a subset of an existing language,
but you then will have unsecurity, unefficiency, unbearable and unefficient
redundancy, etc (see my Why OO paper).


>>> This could also be done by designing a language that provided
>>> this facility.
Yep.
But what I'm saying is that in any case we must provide a language
(either old or new), so the problem is how much low level our implementation
will be.
The choice will rely on our requirements for the language, on the
expected efficiency, on the target platform choosen.



>>> Ie. Language OR OS are both valid solutions.
>>> 
>>> TRadeoffs:
>>>

>>> Language:
>> Working on TOP of an existing OS (aka Unix clone):
> 
> No, the underlying OS is irrelavent
> -- in a highlevel language you don't often
> direcly use UNix system calls, likewise, in a safe language (eg ML) run time
> errors do not occur so the lack of protection is not an issue.

  Err, not exactly, as implementing a system on top of a platform with very
foreign semantics can prove very long, difficult, unsecure and/or inefficient.
  And well, I said "Unix" because that's the most portable platform to me.
  Of course we can ultimately use any platform as a basis, if it allows use to
use the needed hardware capabilities (keyboard, text screen, hopefully sound
and graphics, possibly networking).


So,

Working on TOP of an existing OS (e.g. Unix clone)
>>> 	* Cleaner
>> 	Using (being built on top of) the semantics for "C" memory management
>> 	is anything but clean.
>>> 	* Less low level work
>> 	Translating Unix calls to OO calls __will__ be some kind of low-level
>> 	stuff.
>>> 	* Nicer semantics for data sharing 
>> 	Why ? The language semantics are the same anyway !
>
> As compared with having multiple languages -- in a (eg) LISP machines I can
> pass lists around. In an OS you need to somehow pass around data that will
> make senseto programs written in Prolog, ML, C++ and Oberon ...
  Err, In an OS, those language will have been implemented so as to
understand the data passed by the OS, and not the opposite, as far as I know.
  But, well, yes, if we build a language, we can choose the data sharing
semantics we want (I think that's what we both want to say).

>>> 	* Can't reuse code in other languages
>> 	Yes and no -- you can externally link the runtime with outer modules.
>
> Sorry, me being unclear -- I meant "reuse" in the sense of being first
> class citizens -- being able to have *objects* written  in other languages.

My point is, in Unix, Lisp and such are NOT first class citizens. Only
"C" is a first class citizen. And well, yes, MOOSE as an OS could provide
more liberty to implement other languages as "first class citizens", but only
a language matching MOOSE's semantics can use all his citizenship rights
without clumsy library calls, but even then, new compiler (at least backends)
would have to be built.


>>> 	* Doesn't require designing a common format for ADTs
>> 	It still does.
> 
> But it's internal to the implementation.
Not more than with the OS too !

To me, the main point is:
	* We work on an abstraction of the harware layer; so
	- it's as portable as the OS, i.e. we don't have to write
	our own drivers and kernels to support further hardware platforms,
	as soon as the OS is implemented on these platform.
	- we are limited by the OS' limitations on hardware access and
	semantics (for protection, file access, and inter-process
	communication et al.).

>>> OS:
>> (i.e. rewriting the low-level management of interobject communication &
>> mutual protection).
>> 
>>> 	* Lower level
>> 	Yeah, very dirty, unportable work.
>> 	more time before a first workable version comes out, but then its
>> 	cleaner.
>> 	* __much__ quicker (?) on the machine where it is implemented,
>> 	__much__ lower (i.e. null speed) on any other.

>>> 	* Data passing is limited to primitive types (int, char, float, bool)
>> 	Why so ? The system can be layered so 
>
> How?
> You can have OBJECTS representing compound data structure and pass references
> to these objects around.
> You can't pass raw data that's compound though.
Well, you can have (non micro-kernel based) OS modules that will recognize
compound types. And pass structured objects from process objects to others.

>>> 	* Can use code from any language (well, the compiler has to be modifeid
>>> 		to generate ADT formats rather than normal executbls)
Yep, and even if you write a language, you can well rewrite compilers for
existing languages as well to share the same low-level implementation and
communication scheme, so this argument isn't that persuasive to me.

>>> 	* We need a format for communicating ADTs -- what operations they
>>> 		allow, what types these operations take etc.
>> 	We do need one anyway.
But if we have a language layer, we can change the underlying ADT format
and keep all previous work that was translated in this language.

>>> Attempting to achieve fine grain objects in an OS approach requires 
>>> solving the
>>> problem of sharing non primitive data between ADTs written in different 
>>> languages -- this is tricky (ie a research area)
>> No problem if _we_ provide the right compilers (could be all using the same
>> back-end).
>> Even ANSI "C" allows enhanced restrictions (no pointer arithmetic outside
>> a allocated array, and such things).

>>> Other comments .... having transparent backing store would be nice
>>> BUT would
>>> tbe hell for recoverability/reliabilty/robustness -- unless extreme care is
>>> taken
>>> with recovery any system crash could leave the machine unbootable ...
>> It's fairly possible to have a transactional persistent object (file)
>> system:
>> do not validate a change before it is complete (i.e. leaves the machine in a
>> valid state). Databases do it everyday, why not us ?
>
> Yes.
> It's yet more work though ...
It's more than difficult to _add_ to an existing system, but
not that much difficult if it's thought about from the beginning, and
the language semantics include such things.


> Also, you need to have applications be aware of the system and let the system
> know when they've finished a change and it can be committed...
> 
> One thing that would be nice to get right is file locking -- Unix semantics
> are disgusting. The Amiga gets it right.
I dunno the Amiga way. Can you explain it ?
Whatever the Amiga does, I think a transaction aware language/interface is
far cleaner than a locking solution.

>>> Note that APIs and UIs are interchangeable in modern OS'es so more and
>>> more the
>>> OS is becoming irrelevant to the user ... the two "features" that can't be
>>> achieved by layering another API/UI on top and which are important are:
>>> 	SECURITY
>>> 	RELIABILITY/ROBUSTNESS
>>> 	EFFICIENCY

>>> Thus (assuming we choose to take the OS approach rather than the
>>> language one)
>>> if we take a base OS that is efficient, reliable and secure then adding a
>>> library would probly give us 90% of what we want.
Yes, but what if our OO semantics are too far away from the OS' semantics,
or worse, if the difference is subtle ?

>>   I think both approaches are feasible and interesting. The solution
>> should be voted after all the members have exposed the condition in which
>> they can work on either solution.
>>   In either case, we'll have to provide language service to the OS, or to
>> simulate OS service in the language run-time, so this really is a policy
>> question.
>
> It makes a lot of difference -- the OS way involves a lot more work because
> were starting from bare metal.
yep.
> By building on top of an OS we start at a high level -- this does mean some 
> things won't be doable but it saves us a lot of time.
>
> Another possibility is to take the language approach as a "fast prototype"
> for the final product which would be an OS ... comments?


>>   The more important question is
>> *IS THERE ALREADY A LANGUAGE THAT FITS OUR REQUIREMENTS ?*
>>   What about Ellie, Sather, Eiffel, a FORTH or Postscript extension,
>> smalltalk, SML or CAML, Lisp or Scheme and so on ?
> 
> Depends on the actual requirements.
> For instance, is safety a requirement? If so, LISP/Scheme/Smalltalk/etc.
> fail.
> I think some of the languages come quite close.
To me, safety is a requirement in any multi-* system. Multiple users/tasks
must be protected one from the other.


> Next things to do:
> (1) More debate :-)
> (2) Forming a list of requirements for languages (and for the OS version?)
Yep.
That's on (or so I hope )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                                    /|\ /|\ /

From mckeeveb@sfu.ca Wed May 25 19:39:18 1994
Return-Path: <mckeeveb@sfu.ca>
Received: from shiva.jussieu.fr by frmap711.mathp7.jussieu.fr (4.1/jn910403)
	  at Wed, 25 May 94 19:39:14 +0200
Received: from nef.ens.fr by shiva.jussieu.fr
	  (8.6.8/jtpda-4.0) with SMTP; Wed, 25 May 1994 19:40:54 +0200
Received: from clipper.ens.fr (clipper-gw.ens.fr) by nef.ens.fr (5.65c8/ULM-1.0)
	Id AA16955 ; Wed, 25 May 1994 19:39:09 +0200
Received: from nef.ens.fr by clipper.ens.fr (4.1/version 1.10 of 88/05/05)
 	id AA07521; Wed, 25 May 94 19:39:06 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
	Id AA16932 ; Wed, 25 May 1994 19:38:40 +0200
Received: from ndlc.occ.uky.edu (ndlc.occ.uky.edu [128.163.193.10]) by whistler.sfu.ca with SMTP (8.6.8/SFU-2.6H)
  id KAA10710 for <moose-programmers@sfu.ca> (from ross@occ.uky.edu); Wed, 25 May 1994 10:35:04 -0700
Subject: Moose mailings
To: moose-programmers@sfu.ca
Date: Wed, 25 May 1994 12:33:58 -0500 (CDT)
From: Ross Hayden <ross@occ.uky.edu>
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 413       
Message-Id:  <9405251234.aa24137@ndlc.occ.uky.edu>
Status: OR

Hello all!

I was once haydedr@wkuvx1.wku.edu, or @wkuvx1.bitnet, on the moose mailing
list.

I no longer have time to participate in the project, but I wish you all 
luck!

Fare, thank you very much for the letter I received from you.  It was
interesting to receive mail from abroad.

Thanks,
Ross
-- 
Ross Hayden, Systems Programmer                   ross@ndlc.occ.uky.edu
The National Distance Learning Center

From winikoff@cs.mu.oz.au Tue May 31 08:57:19 1994
Return-Path: <winikoff@cs.mu.oz.au>
Received: from shiva.jussieu.fr by frmap711.mathp7.jussieu.fr (4.1/jn910403)
	  at Tue, 31 May 94 08:57:03 +0200
Received: from mulga.cs.mu.OZ.AU by shiva.jussieu.fr
	  (8.6.8/jtpda-4.0) with SMTP; Tue, 31 May 1994 08:58:47 +0200
From: winikoff@cs.mu.oz.au
Received: from munta.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA00375
	Tue, 31 May 1994 16:56:18 +1000 (from winikoff)
Received: by munta.cs.mu.OZ.AU (8.6.8.1/slave-1.1)
	id QAA10414; Tue, 31 May 1994 16:56:16 +1000
Message-Id: <199405310656.10414@munta.cs.mu.OZ.AU>
Subject: Re: Language or OS ?
To: rideau@mathp7.jussieu.fr (Francois Rideau)
Date: Tue, 31 May 94 16:56:16 EST
Cc: winikoff@cs.mu.oz.au (Michael David WINIKOFF)
In-Reply-To: <9405310635.AA20088@frmap711.mathp7.jussieu.fr>; from "Francois Rideau" at May 31, 94 8:35 am
X-Mailer: ELM [version 2.3 PL11]
Status: OR

> 
> > Examples? Please?
> > My understanding is that "OO = ADT + Inheritance"
> 
> Ahem.
> I'm writing for my school a "Why OO ?" file that I'll put in the frmap711
> anonymous ftp site (pub/scratch/rideau/moose/papers) tonight. Tell me if you
> prefer that I post it.

I'd prefer if you mailed it. 
Thanks!

> 
> As for Genericity, ADT's are all the low-level "OS" part of MOOSE need to
> recognize. Genericity as attained at the Language level (of course, the
> low-level must be such that the implementation be efficient).
> 
> >>> This can be built on top of an existing OS by using a library.
> >> This would be more than a library -- a full runtime & compiler.
> > Why?
> 
>   Because we can't just provide low-level message-passing without an interface
> to use it.

The library is the interface.
You have appropriate library routines and these are implemented in terms of 
message passing.

>   With respect to this, VSTa is currently a nice, but quite unusable, and
> perhaps even ridiculous system ! I don't even know if its message passing
> semantics is good, because I can't use it ! As for the implementation,
> using "C" main() multiplexing is as yechy as OO programming can be. And as

It's not yechy if it's hidden (ie, automatically generated, you never see
the code and it behaves in the right way)

Efficiency would be a problem for fine grain objects.

Context switching is more of a problem here ...

> for efficiency, having a "C" program with its own main() for each object in
> the system will prove quite inefficient.
> 
>   Thus, in any case, an OO (Operating) System with any will of efficiency
> and/or usability should provide a human-accessible interface to its OO
> features. Such interface _IS_ a language. Implementing it _IS_ providing

Yes, but the interface can be a very simple set of calls.
(say, five calls)
You can add these calls to any language.
naloguous to the way Linda adds parallel processing to any language by adding
4/5 calls.

> a full runtime and compiler for the language, whatever language it is.
> Of course you can choose as a language a subset of an existing language,
> but you then will have unsecurity, unefficiency, unbearable and unefficient
> redundancy, etc (see my Why OO paper).
> 
> 
> >>> This could also be done by designing a language that provided
> >>> this facility.
> Yep.
> But what I'm saying is that in any case we must provide a language
> (either old or new), so the problem is how much low level our implementation
> will be.
> The choice will rely on our requirements for the language, on the
> expected efficiency, on the target platform choosen.
> 
> 
> 
> >>> Ie. Language OR OS are both valid solutions.
> >>> 
> >>> TRadeoffs:
> >>>
> 
> >>> Language:
> >> Working on TOP of an existing OS (aka Unix clone):
> > 
> > No, the underlying OS is irrelavent
> > -- in a highlevel language you don't often
> > direcly use UNix system calls, likewise, in a safe language (eg ML) run time
> > errors do not occur so the lack of protection is not an issue.
> 
>   Err, not exactly, as implementing a system on top of a platform with very
> foreign semantics can prove very long, difficult, unsecure and/or inefficient.

As compared with writting something on top of bare metal?
Particularly IBM-PC bare metal? :-)

I agree it could be worse under a badly suited OS.

That's why we don't choose a badly suited OS.

>   And well, I said "Unix" because that's the most portable platform to me.
>   Of course we can ultimately use any platform as a basis, if it allows use to
> use the needed hardware capabilities (keyboard, text screen, hopefully sound
> and graphics, possibly networking).
> 
> 

Must go.

I'll reply to the rest later.

I've FTP'ed some papers on a persistant OS which I'll read soon.

Michael


From rideau@mathp7.jussieu.fr Tue Jun  7 08:24:10 1994
Return-Path: <rideau@mathp7.jussieu.fr>
Received: from shiva.jussieu.fr by frmap711.mathp7.jussieu.fr (4.1/jn910403)
	  at Tue, 7 Jun 94 08:23:58 +0200
Received: from nef.ens.fr by shiva.jussieu.fr
	  (8.6.8/jtpda-4.0) with SMTP; Tue, 7 Jun 1994 08:25:48 +0200
Received: from clipper.ens.fr (clipper-gw.ens.fr) by nef.ens.fr (5.65c8/ULM-1.0)
	Id AA06633 ; Tue, 7 Jun 1994 08:23:57 +0200
Received: from nef.ens.fr by clipper.ens.fr (4.1/version 1.10 of 88/05/05)
 	id AA22328; Tue, 7 Jun 94 08:23:55 +0200
Received: from shiva.jussieu.fr by nef.ens.fr (5.65c8/ULM-1.0)
	Id AA06625 ; Tue, 7 Jun 1994 08:23:55 +0200
Received: from frmap711.mathp7.jussieu.fr by shiva.jussieu.fr
	  (8.6.8/jtpda-4.0) with SMTP; Tue, 7 Jun 1994 08:23:07 +0200
Received: by frmap711.mathp7.jussieu.fr (4.1/jn910403)
	  at Tue, 7 Jun 94 08:20:54 +0200
From: rideau@mathp7.jussieu.fr (Francois Rideau)
Message-Id: <9406070620.AA12805@frmap711.mathp7.jussieu.fr>
Subject: So What ?
To: garfield@verdi.sra.com (David Garfield),
        winikoff@cs.mu.oz.au (Michael Winikoff), csjjlay@mtsu.edu (JJ Lay),
        dgodom@nbc.ksu.ksu.edu (Dan Odom), rideau@ens.fr (Fare),
        ANDREASA@fenris.dhhalden.no (Andreas Arff),
        dmarer@intel.com (Dennis Marer), haydedr@wkuvx1.bitnet (Ross Hayden),
        mckeeveb@sfu.ca (Rob McKeever)
Date: Tue, 7 Jun 94 8:20:54 MET DST
X-Mailer: ELM [version 2.3 PL11]
Status: OR

------------------------------------------------------------------------------e
[Project Status]

It seems that again, the project is getting asleep.

Well, only Michael and I have been producing anything, and nothing was
decided as we are waiting for further feedback from the others.

Moreover, it seems that there are many OO OS projects in the world
that we could join instead of continuing "alone", while if we are to
continue MOOSE, we don't even know what will be our language (if we're
not building a new one, which we all hope not).

Could you all tell your current mind, try to contact some of these
other projects, and try to summarize ?

All the papers I've written and the mailing-list archive
are available by ftp:frmap711.mathp7.jussieu.fr:/pub/scratch/rideau/moose

Have been added in the papers directory:
WhyOO			a new manifesto draft. See next message...
ExistingLanguage	is meant to summarize what each suggested language
			is worth to the project.
OtherProjects		points to other projects related to MOOSE

------------------------------------------------------------------------------
[Just small Suggestions]

* If we are to hack an existing OS kernel, instead of VSTa, I'd propose
building a Linux userfs. Linux will be slower, but it has far more extended
hardware & software support. Userfs should allow the same kind of (well, yes,
much slower), but should allow the same kind of plan9 like interface.
that's only a prototype, isn't it ?).

* As for an instruction set abstraction layer, I'll propose some kind of
FORTH language. Later, this code can be compiled; but interpreted FORTH
code is reputed to be only 10 times slower than optimized code, while FORTH
can still be efficiently -compilation - later.;;;;;;;;;;

* If we are to revamp our own hardware layer, I've already written a boot
loader with TASM for the PC (unhappily, it has nothing to boot for now, but
a small message shower).

------------------------------------------------------------------------------
[Always talking with Michael]
>> I'm writing for my school a "Why OO ?" file that I'll put in the frmap711
>> anonymous ftp site (pub/scratch/rideau/moose/papers) tonight. Tell me if
>> you prefer that I post it.
Unfortunately, it's still not finished; but (almost) all the ideas are there,
are added in a P.S. draft.

> I'd prefer if you mailed it. 
Ok. That's in the following post.


>>>>> This can be built on top of an existing OS by using a library.
>>>> This would be more than a library -- a full runtime & compiler.
>>> Why?
>> Because we can't just provide low-level message-passing without an
>> interface to use it.
> The library is the interface.
> You have appropriate library routines and these are implemented in terms of
> message passing.
>
I see what you mean. that seems ok to me. But I'll then emit two statements:
1) building only the library and not runtime & compiler means we have found
a language whose runtime&compiler already correspond to our requirements.
I insist that this does not only mean that the language is ok, but also that
the runtime system it provides does suit us with respect to security,e
memory management, thread support, error recovery et al.
2) if message passing is completely hidden by your library, then why do you
need message passing at all ? Thus, if message passing is to be included in
the MOOSE specifications, it must be a central feature, not just an
implementation trick.

What I mean is that we should *NOT* adopt any language that is low-level
with respect to structure implementation, as that would mean the user will
have to be aware of the actual system implementation to use it, and worse,
that eventual user hacks will force us to keep this implementation as part of
the specification if we want further downward compatibility.


>>   With respect to this, VSTa is currently a nice, but quite unusable, and
>> perhaps even ridiculous system ! I don't even know if its message passing
>> semantics is good, because I can't use it ! As for the implementation,
>> using "C" main() multiplexing is as yechy as OO programming can be. And as
>
> It's not yechy if it's hidden (ie, automatically generated, you never see
> the code and it behaves in the right way)
It's hidden from the shell user, not from the programmer at any level that
really allows OOP, persistency, and such. Of course, we can write a language
that will hide it from the programmer.

> Efficiency would be a problem for fine grain objects.
Yep, and if we want a unified framework for object, I think (at least at
language and OS specification level) we should not build any barrier between
small objects and big ones.

> Context switching is more of a problem here ...
yep, if all objects are to be implemented that way...


>> for efficiency, having a "C" program with its own main() for each object in
>> the system will prove quite inefficient.
>
>>   Thus, in any case, an OO (Operating) System with any will of efficiency
>> and/or usability should provide a human-accessible interface to its OO
>> features. Such interface _IS_ a language. Implementing it _IS_ providing
>
> Yes, but the interface can be a very simple set of calls.
> (say, five calls)
> You can add these calls to any language.
> naloguous to the way Linda adds parallel processing to any language by adding
> 4/5 calls.
>
Take any language, add 4/5 calls -- that's a kludge, a dirty work-around, no
real fix for language misdesign: if there is to be parallel processing, how
is data to be shared ? All the scope rules must be revamped, or data passed
exclusively through the calls. Then you spend more time in the calls than
doing things. Yurk ! Of course, adding those calls is better than nothing...

>> a full runtime and compiler for the language, whatever language it is.
>> Of course you can choose as a language a subset of an existing language,
>> but you then will have unsecurity, unefficiency, unbearable and unefficient
>> redundancy, etc (see my Why OO paper).



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

From rideau@mathp7.jussieu.fr Tue Jun  7 08:24:11 1994
Return-Path: <rideau@mathp7.jussieu.fr>
Received: from shiva.jussieu.fr by frmap711.mathp7.jussieu.fr (4.1/jn910403)
	  at Tue, 7 Jun 94 08:24:00 +0200
Received: from nef.ens.fr by shiva.jussieu.fr
	  (8.6.8/jtpda-4.0) with SMTP; Tue, 7 Jun 1994 08:25:49 +0200
Received: from clipper.ens.fr (clipper-gw.ens.fr) by nef.ens.fr (5.65c8/ULM-1.0)
	Id AA06637 ; Tue, 7 Jun 1994 08:23:58 +0200
Received: from nef.ens.fr by clipper.ens.fr (4.1/version 1.10 of 88/05/05)
 	id AA22329; Tue, 7 Jun 94 08:23:55 +0200
Received: from shiva.jussieu.fr by nef.ens.fr (5.65c8/ULM-1.0)
	Id AA06627 ; Tue, 7 Jun 1994 08:23:55 +0200
Received: from frmap711.mathp7.jussieu.fr by shiva.jussieu.fr
	  (8.6.8/jtpda-4.0) with SMTP; Tue, 7 Jun 1994 08:24:03 +0200
Received: by frmap711.mathp7.jussieu.fr (4.1/jn910403)
	  at Tue, 7 Jun 94 08:21:53 +0200
From: rideau@mathp7.jussieu.fr (Francois Rideau)
Message-Id: <9406070621.AA12815@frmap711.mathp7.jussieu.fr>
Subject: WhyOO (draft)
To: garfield@verdi.sra.com (David Garfield),
        winikoff@cs.mu.oz.au (Michael Winikoff), csjjlay@mtsu.edu (JJ Lay),
        dgodom@nbc.ksu.ksu.edu (Dan Odom), rideau@ens.fr (Fare),
        ANDREASA@fenris.dhhalden.no (Andreas Arff),
        dmarer@intel.com (Dennis Marer), haydedr@wkuvx1.bitnet (Ross Hayden),
        mckeeveb@sfu.ca (Rob McKeever)
Date: Tue, 7 Jun 94 8:21:52 MET DST
X-Mailer: ELM [version 2.3 PL11]
Status: OR

------------------------------------------------------------------------------
Why do we need Object-Orientedness and such other programming paradygms ?
=========================================================================

  99,9% of programming  time throughout the world is spent doing again and
again the same basic things.
  Of course, you can't escape asking students to repeat what the elders did so
they can understand it and interiorize the constraints of computing. The
problem is student programming represent less than 50% of programming time,
which means even professional people are spending most of their time writing
again and again new versions of earlier works, nothing really "worth" the time
they spend -- moreover, new work is often done by students or their elder
equivalent, researchers, which aggravate the time share professionals spend
doing things really new.
  Now, after all, you may think that such a situation creates jobs, so is
desirable; so why bother ?
  Well, rewriting is a serious problem for everyone: first of all, rewriting
is a loss of time, that make programming delays quite longer, thus are verye
costly; more costly even is the fact that rewriting is an error prone
operation and anytime while rewriting, one may introduce errors very difficult
to trace and remove; the most costly aspect is the time limitation of the
results of programming effort, for the rewriting scheme does make your
investment valuable for very short periods only -- until you have to reinvest
the same sum to rewrite again; moreover, even if produced code is actually
safe and bug free, the technique used to write it is so unsafe that external
programmers can't possibly trust it. Finally, good programmers (those who like
their activity) don't like spending most of their time for such trivial
problems, and would like to spend it for real, higher, theoretical or human,
problems. Actually, there are just as many of these problems as trivial ones
(infinity), but much less are solved because the trivial ones get all the
programmers' attention.
  Therefore, now we can assume that it is proved that code rewriting is a bad
thing, and that we thus want the opposite: code *reuse*. But how can we reuse
code without spreading errors in reused code, without introducing errors due
to misunderstanding of old code, and without escaping code obsolescence ?

  The first most common way to reuse code is to rely on standard libraries.
You wait for the function you need to be included in the standard library
and use it as the manual describes it. Unhappily, standards are long to come,
are longer to be implemented the way they are documented. By that time, you
will have needed new non-standard feature, and will have had to implement them
or to use non-standard libraries. So this kind of code reuse isn't the
solution. Moreover, it relies heavily on a central agency for editing revised
versions of the standard library. This does not mean no effort must be done
to build such a library, as a library greatly helps communication: it's like
vocabulary and culture; but with only vocabulary, you cannot say any new
thing. To say new things, you need to combine the vocabulary, and that's
grammar -- the structure of the language. For however extended, a library will
never contain all that everyone may want to express.
  It should stressed that computer languages have nothing to do with finished,
static "perfect" computer programs -- those can have been written in any
language, preferably a portable one (that is any ANSI supported language,
i.e. surely "C", even if I'd then prefer FORTH) -- computer languages have to
do with programming, with modifyings programs, creating new programs, not just
watching existing ones. Thus, the qualities of a programming language do not
lie in what can be done with the language (the language being hopefully
Turing-equivalent with libraries to access all the hardware), nor in the
efficiency of a straightforward implementation (a good "optimizing" compiler
can always be achieved and/or speed critical routines can be included in
libraries); they lie in the easiness to express *new* concepts, and to
*modify* existing routines. With this in mind, a programming language is
better than another if it is easier for a human to write a new program or
to modify an existing program, or of course to reuse existing code (which
is some extension to modifying code).

  The second most simple way to reuse code is just to copy-paste it, then
modify it to fit one's new particular purpose. But possible bugs or more
generally lack of features are spread accross the system; that is when you
want to modify a portion of code that was copied and pasted, you're on to
search all copies to modify them in the same way. This can be a very long
and difficult job, which can be another source of errors. Moreover, the
same algorithm may need many modifications to adapt different situations.
Thus this method is definitely bad for anything but reuse of mostly identical
code in another program.
  The next way to reuse code is to have written code that will include
run-time tests for all the different cases you may need in the future and
branch to the right one. This method proves hard, slow, uneasy to use, and/or
produces inefficient code. Moreover, it is very hard to anticipate one's
future needs.
  A variant that combines both previous methods is to group all those similar
code fragments into a library, so that you can both understand all future
cases (well, you can still modify this library if you need it in the future,
but we then see that this method is no heal to a bad designed *language*),
and duplicate code where you need it to achieve some efficiency, and at the
same time confine code propagation is in a known limited area. This means
extending the system's vocabulary on your own (or between you and friends).
As we already have seen, this is a good idea, but again, a base of vocabulary
however big, cannot replace a good grammar; culture can never replace
intelligence; it saves you a lot of work that's already been done by others
(but can be also be costly to acquire -- so don't always want to acquire any
unuseful culture), but won't speed up the remaining work (and as we saw,
there's always remaining work). If you want to dig a very long tunnel, unless
there's already one finished or almost done, you'd better look for efficient
digging machines than for the entrance of a formerly begun gallery.

  Then what are "intelligent" ways to produce reusable, easy to modify code ?
Such a method should allow reusing code without duplicating it, and without
growing it in a both unefficient and uncomplete way: an algorithm should be
written once and for once for all the possible applications it may have.
That's __genericity__.
  First, we see that the same algorithm can apply to arbitrarily complex data
structures; but a piece of code can only handle a finitely complex data
structure; thus to write code with full genericity, we need use code as
parameters, that is, __second order__. In a low-level language (like "C"),
this is done using function pointers.
  We soon see problems that arise from this method, and solutions for them.
The first one is that whenever we use some structure, we have to explicitly
give functions together with it to explain the various generic algorithm
how to handle it. Worse even, a function that doesn't need some access method
about an the structure may be asked to call other algorithms which will
turn to need know this access method; and which exact method it needs may not
be known in advance (because what algorithm will eventually be called is not
known, for instance, in an interactive program). That's why explicitly passing
the methods as parameters is slow, ugly, inefficient; moreover, that's code
propagation (you propagate the list of methods associated to the structure --
if the list changes, all the using code changes). Thus, you mustn't pass
*explicitly* those methods as parameters. You must pass them implicitly;
when using a structure, the actual data and the methods to use it are embedded
together. Such a structure including the data and methods to use it is
commonly called an *object*; the constant data part and the methods,
constitute the *prototype* of the object; objects are commonly grouped into
*classes* made of objects with common prototype and sharing common data.
*This* is the fundamental technique of /Object/-/Oriented/ programming; Well,
some call it that Abstract Data Types (ADTs) and say it's only part of the
"OO" paradygm, while others don't see anything more in "OO". But that's only
a question of dictionary convention. In this paper, I'll call it only ADT,
while "OO" will also include more things. But know that words are not settled
and that other authors may give the same names to different ideas and vice
versa.
   BTW, the same code-propagation argument explains why side-effects are an
especially useful thing as opposed to strictly functional programs (see pure
ML :); of course side effects complicate very much the semantics of
programming, to a point that ill use of side-effects can make a program
impossible to understand and/or debug -- that's what not to do, and such
possibility is the price to pay to prevent code propagation. Sharing *mutable*
data (data subject to side effects) between different embeddings (different
*users*) for instance is something whose semantics still have to be clearly
settled (see below about object sharing).

  The second problem with second order is that if we are to provide functions
other functions as parameter, we should have tools to produce such functions.
Methods can be created dynamically as well as "mere" data, which is all the
more frequent as a program needs user interaction. Thus, we need a way to
have functions not only as parameters, but also as result of other functions.
This is *Higher order*, and a language which can achieve this has a
*reflexive* semantics. Lisp and ML are such languages; FORTH also, whereas
standard FORTH memory management isn't conceived for a largely dynamic use of
such feature in a persistent environment. From "C" and such low-level
languages that don't allow a direct portable implementation of the
higher-order paradygm through the common function pointers (because low-level
code generation is not available as in FORTH), the only way to achieve
higher-order is to build an interpreter of a higher-order language such as
LISP or ML (usually much more restricted languages are actually interpreted,
because programmers don't have time to elaborate their own user customization
language, whereas users don't want to learn a new complicated language for
each different application and there is currently no standard user-friendly
small-scale higher-order language that everyone can adopt -- there are just
plenty of them, either very imperfect or too heavy to include in every
single application).
  With respect to typing, Higher-Order means the target universe of the
language is reflexive -- it can talk about itself.
  With respect to Objective terminology, Higher-Order consists in having
classes as objects, in turn being groupable in *meta-classes*. And we then see
that it _does_ prevent code duplication, even in cases where the code concerns
just one user as the user may want to consider concurrently two -- or more --
different instanciations of a same class (i.e. two *sub-users* may need toe
have distinct but mostly similar object classes). Higher-Order is somehow
allowing to be more than one computing environment: each function has its own
independant environment, which can in turn contain functions.
  As for those who despise higher-order and user-customizability, I shall
reply that there is *NO* frontier between using and programming. Programming
*is* using the computer while using a computer *is* programming it. The only
thing you get by having different languages and interfaces for "programmers"
and mere "users" is building plenty of inefficient languages, and stupefying
all computer users with a lot of unuseful ill-conceived, similar but different
ones. You also make development cycles longer by building hardly crossable
borders between language with different general functionalities, and prevent
much useful work from being done by users intelligent enough to write their
own modules, but who don't have time to write a complete application from
*scratch* (i.e. what is commonly provided to a computer user, including so
called professional quality commercial software), not even considering
making it suitable to exchange data with the other software they must use
("compatible").
  Some say that common users are too stupid to program; that's only despising
them; most of them don't have *time* and *mind* to learn all the subtleties of
advanced programming; but they often do manually emulate macros, and if shown
once how to do it, are very eager to write their own macros/aliases.
  Some fear that authorizing a "mere" user to use a powerful programming
language is the door open to piracy and system crash. Well, if the language
library has such security holes, it's a library misconception; if the language
doesn't allow the design of a secure library, that's a language misconception.
Whatever was misdesigned, it language should be redesigned, amended of
replaced (as should be "C"). If you don't want people to cross an ill-placed
fissured wall, you'd better rebuild a new better placed wall than hire an
army of guards to shoot at people trying to get into the other part of the
misplaced wall, or unwillingly trespassing in a crack -- and in the first
solution, don't forget to also hire people to cope with lacks due to the
wall's misplacement. And if what you want most is nobody trespassing, well,
just forbid people from ever nearing the wall -- don't have them use the
computer.
  The truth is any computer user, whether a programming guru or a novice
user, is somehow trying to communicate with the machine. The easier
communication, the quicker better larger work is getting done.

  To end with genericity, here is some material to feed your thoughts about
the need of system-builtin genericity: let's consider multiplexing.
  For instance, Unix (or worse, DOS) User/shell-level programs are ADTs,
but with only one exported operation, the "C" main() function per executable
file. As such "OS" are huge-grained, with ultra-heavy inter-executable-file
(even inter-same-executable-file-processes) communication semantics no one can
afford one executable per actual operation exported. Thus you'll group
operations into single executables whose main() function will multiplex those
functionalities.
  Also, communication channels are heavy to open, use, and maintain, so you
must explicitly pass all kind of different data&code into single channels by
manually multiplexing them (the same for having heavy multiple files or a
manually multiplexed huge file).
  But the system cannot provide builtin multiplexing code for each single
program that will need it. It does provide code for multiplexing the hardware,
memory, disks, serial, parallel and network lines, screen, sound. POSIX
requirements grow with things a compliant system oughta multiplex; new
multiplexing programs ever appear. So the system grows, while it will never
be enough for user demands as long as *all* possible multiplexing won't have
been programmed, and meanwhile applications will spend most of their time
manually multiplexing and demultiplexing objects not yet supported by the
system.
  Thus, any software development on common OSes is hugeware. Huge in hardware
resource needed (=memory - RAM or HD, CPU power, time, etc), huge in resource
spent, and what is the most important, huge in programming time.
  The problem is current OSes provide no genericity of services. Thus they can
never do the job for you. That why we really NEED *generic* system
multiplexing, and more generally genericity as part of the system. If one
generic multiplexer object was built, with two generic specializations
for serial channels or flat arrays and some options for real-time behaviour
and recovery strategy on failure, that would be enough for all the current
multiplexing work done everywhere.

  So this is for Full Genericity: Abstract Data Types and Higher Order.
Now, if this allows code reuse without code replication -- what we wanted --
it also raises new communication problems: if you reuse objects especially
objects designed far away in space and/or time (i.e. designed by other
people or an other, former, self), you must ensure that the reuse is
consistent, that an object can rely upon a used object's behaviour. This is
most dramatic if the used object (e.g. part of a library) comes to change
and a bug (that you could have been aware of -- a quirk -- and already have
modified your program accordingly) is removed or added. How to ensure object
combinations' consistency ?
  Current common "OO" languages are not doing much consistency checks. At
most, they include some more or less powerful kind of type checking (the most
powerful ones being those of well-typed functional languages like CAML or
SML), but you should know that even powerful, such type checking is not
yet secure. For example you may well expect a more precise behavior from
a comparison function on an ordered class 'a than just being 'a->'a->{LT,EQ,GT}
i.e. telling that when you compare two elements the result can be
"lesser than", "equal", or "greater than": you may want the comparison
function to be compatible with the fact of the class to be actually ordered,
that is x<y & y<z => x<z and such. Of course, a typechecking scheme, which
is more than useful in any case, is a deterministic decision system, and as
such cannot completely check arbitrary logical properties as expressed above
(see your nearest lectures in Logic or Computation Theory). That's why to add
such enhanced security, you must add non-deterministic behaviour to your
consistency checker and/or ask for human help. That's the price for 100%
secure object combining (but not 100% secure programming, as human error is
still possible in misexpressing the requirements for using an object, and
the non-deterministic behovior can require human-forced admission of unproved
consistency checks by the computer).
  This kind of consistency security by logical formal property of code is
called a formal specification method. The future of secure programming lies
in there (try enquire in the industry about the cost of testing and/or
debugging software that can endanger the company or even human lives if ill
written, and insurance funds spent to cover eventual failures -- you'll
understand). Life concerned industries already use such modular formal
specification techniques.
  In any cases, we see that even when such methods are not used automatically
by the computer system, the programmer has to use them manually, by including
the specification in comments and/or understanding the code, so he does
computer work.

  Now that you've settled the skeleton of your language's requirements, you
can think about peripheral deduced problems.





------------------------------------------------------------------------------
[draft]
- not building an artificial border between programmers and users --> not
only the system programming *language* must be OO, but the whole *system*.
- easy user extensibility --> language-level reflexivity.
- sharing mutable data: how ? --> specifications & explicitly mutable/immutable
(or more or less mutation-prone ?) & time & locking -- transactions.
- objects that *must* be shared: all the hardware resources -- disks & al.
- sharing accross time --> persistence
- reaching precision/mem/speed/resource limit: what to do ? --> exceptions
- recovering from exceptional situations: how ? --> continuations (easy if
 higher-order on)
- tools to search into a library --> must understand all kind of morphism in
a logically specified structure.
- sharing accross network -->
 - almost the same: tools for merging code --> that's tricky. Very important
for networks or even data distributed on removable memory (aka floppies) --
each object should have its own merging/recovery method.
- more generally tools for having side effects on the code.




* Structures:
-------------
we consider Logical Structures: each structure contains some types, and
symbols for typed constants, relations, and functions between those types.
Then we know some algebraic properties verified by those objects,
i.e. a structure of typed objects, with a set of constants&functions&relations
symbols, et al.

  A structure A is interpreted in another structure B if you can map the
symbols of A with combinations of symbols of B (with all the properties
conserved). The simplest way to be interpreted is to be included.
  A structure A is a specialization of a structure B if it has the same
symbols, but you know more properties about the represented objects.

* Mutable objects:
------------------
We consider the structure of all the possible states for the object. The
actual state is a specialization of the structure. The changing states
accross time constitute a stream of states.

* Sharing Data
--------------
  The problem is: what to do if someone modifies an object that others see ?
Well, it depends on the object. An object to be shared must have been
programmed with special care.
  The simplest case is when the object is atomic, and can be read or modified
atomically. At one time, the state is well defined, and what this state is
what other sharers see.
  When the object is a rigid structure of atomic objects, well, we assume that
you can lock parts of the object that must be changed together -- in the
meantime, the object is unaccessible or only readable -- and when the
modification is done, everyone can access the object as before. That's
transactions.
  Now, what to do when the object is a very long file (say text), that each
user sees a small part of it (say a full screen of text), and that someone
somewhere adds or deletes some records (say a sentence) ? Will each user's
screen scroll according to the number of records deleted ? Or will they
stay at the same spot ? The later behaviour seem more natural. Thus, a file
has this behaviour that whenever a modification is done, all pointers to the
file must change. But consider a file shared by _all_ the users across a
network. Now, a little modification by someone somewhere will affect
everyone ! That's why both the semantics and implementation of shared objects
should be thought about longly before they are settled.

Problem: recovery
-----------------
What to do when assumptions are broken by higher priority objects ?
e.g. when the user interrupts a real-time process, when he forces a
modification in a otherwise locked file, when the process is out of memory,
etc.
Imagine a real-time process is interrupted: will it continue where is stopped ?
or will it skip what was done during the interruption ?
Imagine the system runs out of memory ? Whose memory are you to reclaim back ?
To the biggest process ? The smallest ? The oldest ? The first to ask for
more ? If objects spawn, thus filling memory (or CPU), how to detect "the one"
responsible and destroy it ?
If an object locks a common resource, and then is itself blocked by a failure
or other unwilling latency, should this transaction be cancelled, so others can
access the resource, or should all the system wait for that single transaction
to end ?

  As for implementation methods, you should always be aware that defining
all those abstraction as the abstractions they are rather than hand-coded
emulation for these allows better optimizations by the compiler, quicker
write phase for the programmer, neater semantics for the reader/reuser,
no implementation code propagation, etc.
  Partial evaluation should also allow specialization of code that don't use
all the language's powerful semantics, so that standalone code be produced
without including the full range of heavy reflexive tools.


------------------------------------------------------------------------------
Summary:
========

* Axioms:
--------
= "No man should do what the computer can do quicker for him (including time
spent to have the computer understand what to do)" -- that's why we need to
be able to give order to the computer, i.e. to program.
= "Do not redo what others already did when you've got more important work" --
that's why we need code reuse.
= "no uncontrolled code propagation" -- that's why we need genericity.
= "security is a must when large systems are being designed" -- that's why we
need strong typechecking and more.
= "no artificial border between programming and using" -- that's why the entire
system should be OO with a unified language system, not just a hidden system
layer.
= "no computer user is an island, entire by itself" -- you'll always have to
connect (through cables, floppies or CD-ROMs or whatever) to external
networks, so the system must be open to external modifications, updates and
such.


  That is, without ADTs, and combinating ADTs, you spend most of your time
manually multiplexing. Without semantic reflexivity (higher order), you spend
most of your time manually interpreting runtime generated code or manually
compiling higher order code. Without logical specification, you spend most of
your time manually verifying. Without language reflexivity, you spend most of
your time building user interfaces. Without small grain, you spend most of
your time emulating simple objects with complex ones. Without persistence,
you spend most of your time writing disk I/O (or worse, net I/O) routines.
Without transactions, you spend most of your time locking files. Without
code generation from constraints, you spend most of your time writing
redundant functions that could have been deduced from the constraints.
  To conclude, there are essentially two things we fight: lack of feature
and power from software, and artificial barriers that misdesign of former
software build between computer objects and others, computer objects and
human beings, and human beings and other human beings.

From rideau@mathp7.jussieu.fr Tue Jun  7 08:29:39 1994
Return-Path: <rideau@mathp7.jussieu.fr>
Received: from shiva.jussieu.fr by frmap711.mathp7.jussieu.fr (4.1/jn910403)
	  at Tue, 7 Jun 94 08:29:19 +0200
Received: from nef.ens.fr by shiva.jussieu.fr
	  (8.6.8/jtpda-4.0) with SMTP; Tue, 7 Jun 1994 08:31:10 +0200
Received: from clipper.ens.fr (clipper-gw.ens.fr) by nef.ens.fr (5.65c8/ULM-1.0)
	Id AA06801 ; Tue, 7 Jun 1994 08:29:19 +0200
Received: from nef.ens.fr by clipper.ens.fr (4.1/version 1.10 of 88/05/05)
 	id AA22344; Tue, 7 Jun 94 08:29:17 +0200
Received: from shiva.jussieu.fr by nef.ens.fr (5.65c8/ULM-1.0)
	Id AA06797 ; Tue, 7 Jun 1994 08:29:17 +0200
Received: from frmap711.mathp7.jussieu.fr by shiva.jussieu.fr
	  (8.6.8/jtpda-4.0) with SMTP; Tue, 7 Jun 1994 08:30:21 +0200
Received: by frmap711.mathp7.jussieu.fr (4.1/jn910403)
	  at Tue, 7 Jun 94 08:28:01 +0200
From: rideau@mathp7.jussieu.fr (Francois Rideau)
Message-Id: <9406070628.AA12889@frmap711.mathp7.jussieu.fr>
Subject: OtherProjects
To: garfield@verdi.sra.com (David Garfield),
        winikoff@cs.mu.oz.au (Michael Winikoff), csjjlay@mtsu.edu (JJ Lay),
        dgodom@nbc.ksu.ksu.edu (Dan Odom), rideau@ens.fr (Fare),
        ANDREASA@fenris.dhhalden.no (Andreas Arff),
        dmarer@intel.com (Dennis Marer), haydedr@wkuvx1.bitnet (Ross Hayden),
        mckeeveb@sfu.ca (Rob McKeever)
Date: Tue, 7 Jun 94 8:28:01 MET DST
X-Mailer: ELM [version 2.3 PL11]
Status: OR

------------------------------------------------------------------------------
[Other Projects related to MOOSE]

Please send me summaries of the OSes and languages you know that can
be related to MOOSE. Please return any useful information.


==============================================================================
=OSes=
======


* Linux *
=========

- What is Linux ?
-----------------
  Linux a *free* 32-bit POSIX compliant (unix clone) OS for i386+
computers.
  It's not Object-Oriented or Persistent at all (though they now try to
have kernel modules), it's not microkernelish (though a port to Mach
is being worked on), it's not portable yet (though a port to the M68K
architecture -- Amigas -- is almost finished, and other ports being
worked on), but well, it runs great, supports a large number of
hardware devices, and almost any Unix-compatible software. It also
has a good DOS "Emulator" (doesn't emulate the CPU).
  If you want a free multitasking 32-bit OS for your PC, Linux is for
you.

- Linux and MOOSE:
------------------
  There are four ways Linux can be used during MOOSE development:
- As a cross-development platform. We can use tools running under Linux
to develop a completely different OS.
- As a basis to modify: we can implement MOOSE as a special Linux kernel-
supported subsystem.
- As a client for a MOOSE filesystem: Linux allows user processes to be
mounted as filesystems. If MOOSE if to offer a file-system like interface,
here is a way to implement it.
- As an OS on top of which to write an application that will emulate
the MOOSE functionalities.

status: world-wide internet individuals project
development language: C
user language: C

news:comp.os.linux.*
email:linux-activists-request@niksula.hut.fi
ftp:ftp.cs.helsinki.fi:/pub/Software/Linux/	original kernel site
ftp:sunsite.unc.edu:/pub/Linux			largest software repository
ftp:tsx-11.mit.edu:/pub/linux			large software repository
ftp:ftp.funet.fi:/pub/OS/Linux			large software repository



* VSTa *
========

- What is VSTa ?
----------------
  A microkernel based free OS.
  It works, but not much hardware or software is supported.
The principle is that from user-level, everything is accessible
through a filesystem like interface (the idea behind Plan9 also),
while a micro-kernel only passes a small number of different
kinds of messages between light processes.
  Moreover, under VSTa, you currently program in "C", so that's
not ideal to build an OO layer; but as the microkernel protocol is
quite simple, we can easily implement any language on top of VSTa
(for the library, that's another thing).

- VSTa and MOOSE
----------------
MOOSE can be implemented as a VSTa server ?

development language: C
user language: C
status: personal project.

ftp:ftp.cygnus.com:/pub/vandys/vsta



* Mach *
========
Microkernel for all kind of OSes.

status: university project, freely distributable with "send modifications
	back" clause.

ftp:*:**/FreeBSD/**



* Watershed *
=============
Persistent OO OS project.

development language: being developped in C.
user language: C for the moment, but without the semantics from the libraries
status: personal project

email: dpw93@ecs.soton.ac.uk (David Wragg)



* GrassHopper *
===============
  Grasshopper is an Australian Project for a Persistent Operating System.
Can anyone contact them and summarize ?

development language: C (?)
user language: ?
status: university project

email:johnr@cs.su.oz.au
http://www.gh.cs.su.oz.au/Grasshopper


* Plan9
=======
It's an OS all functionalities made available through a
Unix-filesystem-like interface.
status: University Project
development language: C
user language: C 



* PC Geos
=========
  Geos is a *commercial* OS, which already implements some
advanced Persistence and OO ideas (?). Anyone has seen it working ?

status: commercial software.

news:comp.*.geos
ftp:130.219.44.141:/pub/geos.


