MOOSE messages (fwd)

[Francois-Rene Rideau]

Forwarded message:
>From jecel@lsi.usp.br  Sat Oct 29 02:00:18 1994
Received-Date: Sat, 29 Oct 94 02:00:17 +0100
Date: Fri, 28 Oct 94 17:07:19 EDT
From: jecel@lsi.usp.br (Jecel Mattos de Assumpcao Jr.)
Subject: MOOSE messages
To: rideau@clipper
Reply-To: jecel@lsi.usp.br
Message-Id: <9410281907.AA02952@ofelia>
X-Envelope-To: rideau@clipper.ens.fr


Hello,

I have merged my comments to your messages into one long chunk
to make things easier. You can forward this to the MOOSE list,
if you like.

> Subject: MOOSE project status
> 
> As I recall you, the MOOSE project is the project for a computing system
> (not only what is commonly called operating system) with
> [ MOOSE basic features deleted to save spave ]
> 
> The critical points are
> * the type system, which should be generic enough to allow *any* language to
>  use directly system types; types must thus be parametrizable.

Maybe it would be better for each language to adapt to the proposed
system as you are not going to reuse much existing code. This is
the approach Microsoft took with OLE, IBM with SOM and OMG's CORBA.

In OOPSLA'94 there was ( I only read about it ) a workshop on language
independent object models.

> * the high-level language, which should allow full use and specification of the
>  system resources.

Hopefully not BASIC, visual or not :-) This is actually very important -
Linux people are now considering using scheme for this ( tcl has come the
closest to an "integration language", so far ).

> * most basic protocols.

This is *very* hard. I guess that is why everyone simply adapts
the Smalltalk-80 classes.

> Well, the MOOSE project (as we still name it) has got (only)
> four members; but I think we may join the PIOS project, which is some nine
> more people, and perhaps the merlin project, which is one more.
> Sorry for the delay, but the language choice is a really big problem.
> 
> [ MOOSE group and PIOS contact deleted ]
> 
> Merlin is Jecel Mattos de Assumpcao Jr. (jecel@lsi.usp.br). There's
> a WWW page that I've not finished reading yet.

There is, unfortunately, very little real information on those pages.
I hope to fix this by the end of next week, but let me make a brief
description of Merlin as related to this discussion:

The aim of the Merlin Project is to develop a computer for novices.
The idea is not to make a watered down traditional system ( like
Jeff Reskin's Cannon Cat ) but rather a powerful and extensible
medium ( like Alan Kay's Dynabook ). The technology used is a
custom implementation of the Self programming language in a system
very much like the description for MOOSE.

This is a *commercial* project ( that is, I mean to make money out
of it ) that will be distributed in two versions:

    - Hacker's Merlin: can be installed on existing computers and
will be distributed for free but without support. Porting to
different machines will be encouraged.

    - User's Merlin: will be embedded in the ROMs of Merlin computers
or licensed computer makers.

Both versions will come with the full *source* code and programming
environment. They should be identical, or at least very alike, except
that any licensed technology ( fractal image compression, for example )
would not be included in the hacker's version.

The reason I am explaining all this is because if MOOSE becomes somehow
linked to Merlin ( which might be great, but see below ) I will have
to rethink the above plans to divide the future profits among the
contributors.

The current status of Merlin is that it is in the late design phase
and in the early coding phase. It has been so far developed on
custom hardware, but will now move to either Sun hardware or a
PowerPC PReP board. Later there will be a port to the 386.

BTW. though I thought that joining Merlin with other projects
was very unlikely, I changed the project's official language
from Portugues to English in February just in case...

> There are also a lot of people interested in MOOSE progress, who may
> be future users or developpers if the system ever gets usable.

A lot of people are having the same ideas. You have done a good
job of getting them together.

> Current status is:
> * only general goal settled
> * ftp site: frmap711.mathp7.jussieu.fr:pub/scratch/rideau/moose/
> 
> 
> Current schedule is:
> 
> Organization:
> * See what if PIOS, MOOSE and/or Merlin will merge

I would love to see that happen, though I don't know yet enough
details to know if it is possible. For my part, I will be glad
to share any information about Merlin.

> * Settle a stable mailing list (ens.fr has got a daemon for such things)
> * See how tight the team can be (i.e. irc meetings or only mail ? ftp sites ?)

How do the Linux people do it? My impression is that they use mail
"channels".

> Contents:
> * See what existing language or OS to use or extend if any; thus study them

I have my opinions on that ( see below )

> * See what platforms are current targets

Though I hate them, PCs are one obvious choice. The problem with writting
an OS for them is the number of drivers you need. But if you start with
IDE hard disks and VGA video cards, you will make most people happy for
a while.

> Any suggestion welcome.

You'll have no lack of them from me, if you really want them ;-)

> Subject: MOOSE ORG: IRC meeting organization
> 
> Now, as for organizing discussions, what about IRC meetings ?
> IRC is the global on-line discussion server. If you do not have access
> to it, you still can rlogin to another member's (eg. me, but the closer,
> the better) account to use it.
> What we need is meetings, i.e. all concerned people should be on-line at
> the same time. So tell me what hours and days are yours so we can gather
> on these days (please use GMT -- accessible through date -u or with
> any clock and dictionary); of course, all meetings should be organized with
> at least 1 week warning. Weekly meetings may be appreciated.

It would not be very practical for me to participate in IRC meetings
from home ( where I work ), but I could arrange to go to the
university and use their computers for that. As I am right in the middle
between the US and Europe, I would say that any time you can agree on
would be fine with me.

> Subject: MOOSE: project organization
> 
> Proposed Organization chart:
> * we divide work between a hierarchical list of subjects.
> * Message "Subject:" field will begin by the list of subjects (well, using
>  abbreviations)

Good idea. I was doing something like this in my project ( sending
mail to myself :-)

> * Each subject has got a maitainer.
> * The maintainer will; who must maintain a file about what was
>  said about the subject.
> * He must provide regularly updated versions through ftp and/or mail.
> * He also must animate the debate about the subject

There should be a full archive of all of the messages in addition
to the file you mentioned. This file, by the way, could be the
seed of the system documentation. In my project I have decided
to do all my documenation in HTML so you can read it with MOSAIC
or NETSCAPE. It is also a very portable way of having text+figures.
My previous Pagemaker and Postscript attempts didn't work out as
well.

> * Decisions are done by a vote of concerned people.
> * If nobody disagrees, the maintainer of a subject may also take decisions.
> * The subject maintainer is responsible for the vote.
> * If no decision is reachable through vote, the maintainer will ultimately
>  choose, or reorganize a new vote later.

This sounds like the usenet system. Very nice, but slow. I think you
will want some details to be decided by groups of one to speed things
up ( obviously the not important parts ).

> * If the maintainer's choice is vetoed by a member, a maintainer for a
>  "higher" subject in the hierarchy is called to decide (or reorganize a vote).
> * Ultimately, an absolute arbitrary judge is to decide (or say who among those
>  who know will decide).
> * The ultimate judge is chosen according to an arbitrary but known in advance
>  method. Suggestions: one of the project founders, and/or a rotation between
>  members. His identity may change with time, as long as there is no way
>  to contest it.
> * Any decision may be later changed if someone can provide new arguments.
> * The same procedure applies for the new decision.
> * The choice for subject maintainers and absolute judge choice method
>  are a decision among others.

Ok - this system of avoiding deadlocks should avoid the speed problems
I mentioned above.

> We still need an initial absolute judge.
> If we join PIOS or Merlin, I'd propose the project initiator, else myself.
> I also propose myself (or anyone willing for that ungrateful job) as a
> maintainer for the organization subject (whose mail symbol will be ORG if
> no one disagrees).

Agreed. You said the subjects will be hierarchical. That means we
would later have ORG.MAILING-LIST and ORG.CONTACTS and things like
that?

> Subject: MOOSE: other existing projects
> 
> (ever sorry for broken english)

My native language is not english either, so I don't mind :-)

> We still do not know what language to use.
> One may think it's a superfluous question, and say that the system should
> be language-independent anyway, but actually it is *not*,
> as the object semantics of the language will limit the object semantics
> of the system.

More or less true. Have you seen how SmalltalkAgents can "talk" with
C on the Machintosh?

> Language suggestions are
> * SELF          a pure OO language

One advantage is that it has a very lightweight object model, which
can simulate more complex ones like Smalltalk's.

> * BETA          a modern OO approach -- BETA is better

I have read the FAQ, but don't know much about it.

> * SML           a strongly-typed functional language

I am impressed with what people have been doing with this
language ( see recent OOPSLA papers ).

> * Scheme        an untyped (but run-time checked) functional language

It looks like Linux is going this route. But they need to settle
on an object standard ( probably CLOS-like, unfortunately ).

> * Sather        an OO language

I didn't see that this really improved on Eiffel as claimed.

> * Gopher        ??
> * Oberon        an OO language and system

I would much prefer this over C++. But I don't like static typing.

> * FORTH         an untyped low-level postfix functional language

I love it! I even designed a FORTH CPU as a graduation project. But
I wouldn't use it for a very dynamic system like MOOSE unless it
was extended to at least a Postscript-like level.

Kyle's TSOL language is like a cross between FORTH and Self. For
those who like Oberon-like things, look at Craig Chamber's Cecil
language ( Craig wrote the second generation Self compiler ).

> Existing systems or projects that may be worth looking at (or may already be
> what we need) are:
> * STAPLE        a (persistent (((lazy (functional language)) based) system))

Never heard of it.

> * TAOS          a distributed system with a portable assembler

This looks great! It is the closest thing yet to what I want. Coming
soon to an Acorn machine near you...

> * Oberon        a OO system

The windowing system looks like a MS Windows 1.0 clone, though us
hackers love how it ties in to the program structure. Small and
fast, but to shallow for my taste.

> * Amoeba        a distributed OS

I think Amoeba is now a commercial product. Helios is a very neat
Amoeba derivative.

> * Grasshopper   a distributed OS

Looks pretty good, specially the persistence part.

> * VSTa          a message-passing micro-kernel-based OS

I have heard of this, but don't know any details.

I can also recomend Sony's Apertos system.

At least some of the above systems are closed ( no sources avaiable
for hacking ).

> All these do not mean we should just choose one and use it as is and/or
> do nothing more (though it may mean it). It means there are already
> lots of things done, and we *must* know what is good about them, and perhaps
> we should use an existing software and "just" extend it. If nothing is usable,
> we'll have to decide everything from scratch (possible, but much more longer to
> do, and error-prone).

I agree that it never hurts to know as many different ways of doing things
as possible. As to starting from scratch, it takes much longer but is not
necessarily more error-prone.

> These lists are of course subject to increase. I'll maintain a better
> annotated list of these. It will be available by ftp in
> frmap711.mathp7.jussieu.fr in pub/scratch/rideau/moose/papers/comparison.

If I new what the criterion for inclusion in the list was, then I
might have other suggestions.

> What we should do is study each of these projects:
> for each language/system considered, one of us must study it, and write
> a short article about what are the software's (mis)features and lacks,
> available implementation, available documentation, and what documentation to
> read first to have an idea, and where to get all of these and who to get in
> touch with about them.

Good plan.

> This means a lot of work. I'll do it, but if I must do it alone, it'll be
> a lot of time before the project decides.

Well, it was you idea ;-). But count on me to help, even if MOOSE and
Merlin don't end up together.

Jecel Assumpcao Jr
<a href=http://www.lsi.usp.br/~jecel/merlin.html>Merlin Computers</a>
+Laboratorio de Sistemas Integraveis - University of Sao Paulo - Brazil
+Pontificia Universidade Catolica de Sao Paulo