Language or OS ?

[winikoff@cs.mu.oz.au]

> 
> > 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.

Examples? Please?
My understanding is that "OO = ADT + Inheritance"

> 
> 
> > 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?

> 
> > 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):

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.

> > 	* 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 ...

> > 	* 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.

> > 	* Doesn't require designing a common format for ADTs
> 	It still does.

But it's internal to the implementation.

> 
> > 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.

> > 	* 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 ?

Yes.
It's yet more work though ...
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.

> 
> 
> > 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.

It makes a lot of difference -- the OS way involves a lot more work because 
were starting from bare metal.
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 p[ossibility 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.

Next things to do:
(1) More debate :-)
(2) Forming a list of requirements for languages (and for the OS version?)


> 
> 
> > Michael
> 
>