MOOSE Project

Francois-Rene Rideau rideau@clipper
Sat, 29 Oct 94 15:47:18 MET

[This is a reply to a message from Chris Harris,;
The message is entirely quoted, together with reply]

> Hello,
>      I've heard a little about MOOSE in the past, but I didn't know it 
> was quite this neat.  =)
  Well, actually, another one began the project (and gave it its name), two
years ago, but the project got a SIGSTOP when summer came, and I had much
trouble trying to gather the team back after that.
  The project died because its goal weren't neat at all; but as the only
continuator, I could have the whole left team agree ;) and could decide the
goals before a new attempt to gather the team.

> Perhaps you're like super-human or something, 
How I'd love to be :)

> but this seems like a rather large project to take on (or even maintain) 
> on your own.
That's why I need help from all over the world.

>  As such, I'd like to get any more details you may have 
> about the project, as I might be interested in joining, if you wouldn't 
> mind.
Not at all !
So details:

1) Organization status.
The MOOSE archive is on*
The mailing list will soon reappear, now at
There are currently 4 MOOSE members, plus (if we merge, which seems to be)
9 PIOS members, and one Merlin member (plus you if you join).

2) Specification status.
The goals are setup (the blurb you got) (I'm writing an argued definitive
version in good english).
The primary target architecture are choosen: a version for 386+ PCs, one
that'll run over POSIX, and one for every architecture a member will be
willing to port it to.
The portable low-level language is still to be choosen, though the original
idea is it will be stack-based.
The big problem is the high-level language to use, though it seems SELF is
a good choice.

3) Distribution policy
What is sure is that some working version will be available for free on the
internet with a GNU (-like?) Copyleft policy, so that we may create a
linux-like community that will support us.
But it looks like some of us would want to make money from a commercial
version of the system, and nobody seems to have a moral objection against
earning money from one's work, as long as no "non-disclosure agreements"
will prevent the system from being spread.

> In particular, I'd like to know what an object is in MOOSE, and
  An object is just anything that you might consider, in a context that
determines its behavior. That is anything that has a value in any language
you use, and that may interact with other objects. Indeed, what actually
defines an object is the behavior when being combined with another one,
whether you call this combination "function application", "taking a member
value", "sending a message", or whatever.
  This is quite unrestrictive, and indeed, a computing system should let the
user be free to choose what kind of objects he'll use.
  But on the other hand, we must still provide some kind of security, of
warranty: firstly, we must provide some standard basic combinators, that
will ensure that any kind of computing may be done; then, we must ensure
that no object will be ever combined with invalid other objects.
  Thus, we must have a system that will ensure program validity, i.e. a
parametrizable type system (and we know from the Curry-Howard isomorphism,
that such type system where types and objects combine freely may be used to
implement all the logic, and any kind of program specification).

> how low-level the stack language is, and what options it supports.
The idea is that the language is portable, generates compact code (for
fast network transfer), and allows efficient implementations. A stack language
seemed an obvious solution, but the TAOS uses a virtual RISC processor, that
maps well on newer RISC architectures; so we're not so sure.

> I won't have a decent system on my hands for a few weeks (I still need to
> find a decent one for a decent price), so I can't do anything right away,
> but I could still take a look.
You needn't code anything to be useful. Suggestions, studies, ideas,
organization work, writing reports, etc: all these are quite useful.

>      As for a high-level language, I would definately look at self, since 
> it presents one of the best object models I've ever seen.  Perhaps models 
> like it will be the way of the future.  Not sure how well it fits the 
> other requirements, though.
It really looks like SELF is a good choice for the system's HLL, or at least
as a basis to it; but there are things I want about the HLL that I don't
think are in plain SELF (though I don't know self well enough):
* differentiate objects from their names
* allow arbitrary annotation
* allow secure validity checks (typing), i.e. semantical checking and not
only name checking.

>      Well, I gotta' run.  Look forward to hearing back from you.
> -Chris

  BTW, as MOOSE may merge with the PIOS and Merlin projects, the name
problem arises; so if you have a good idea for a name, tell it !
  'MOOSE' stood for "Multi* OO OS & Env"
  'PIOS' is for Processor-Independent OS
  At the early MOOSE times, there were also OSPREy (for OS PROject), or
NT-EPT, D/QN, or Vojy (one letter better than MS-DOS, C/PM or Unix),
or 'MTOIS' (pronounce "Empty-O-1-2") "Multi-T* OO Integrated Syst".
  I just proposed 'TUNES': "TUNES is a Useful, Not Expedient, System", which
I like because it has humor, it sounds well (tunes...), it is a GNU-like
recursive acronym, and it expresses system philosophy: strive to be useful,
not to be something easy to program, to sell, or to agree upon, like the usual
commercial stuff or POSIX; and it refers to J.S. Mill's "Utilitarianism".

--    ,        	                                ,           _ v    ~  ^  --
-- Fare -- -- 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                                    /|\ /|\ /