So What ?

[Francois Rideau]

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