Reply to the reply

[winikoff@cs.mu.oz.au]

Hi!

I've read through your mail.

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.

This can be built on top of an existing OS by using a library.

This could also be done by designing a language that provided this facility.

Ie. Language OR OS are both valid solutions.

TRadeoffs:

Language:
	* Cleaner
	* Less low level work
	* Nicer sementics for data sharing 
	* Can't reuse code in other languages
	* Doesn't require designing a common format for ADTs
OS:
	* Lower level
	* Data passing is limited to primitive types (int, char, float, bool)
	* 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.

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)


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

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.

Michael
PS. For examples of systems based on the language approach see LISP machines,
FORTH machines, the smalltalk environment, Logix, even BASIC machines :-)