Language or OS ?
Fri, 27 May 94 13:52:42 EST
> > 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.
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.
> > 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
> > * 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
> * __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
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
> 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 ?
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
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