Language or OS ?

[Francois Rideau]

> 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