Language or OS ?

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