Language or OS ?

[winikoff@cs.mu.oz.au]

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

I'd prefer if you mailed it. 
Thanks!

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

The library is the interface.
You have appropriate library routines and these are implemented in terms of 
message passing.

>   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

It's not yechy if it's hidden (ie, automatically generated, you never see
the code and it behaves in the right way)

Efficiency would be a problem for fine grain objects.

Context switching is more of a problem here ...

> 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

Yes, but the interface can be a very simple set of calls.
(say, five calls)
You can add these calls to any language.
naloguous to the way Linda adds parallel processing to any language by adding
4/5 calls.

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

As compared with writting something on top of bare metal?
Particularly IBM-PC bare metal? :-)

I agree it could be worse under a badly suited OS.

That's why we don't choose a badly suited OS.

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

Must go.

I'll reply to the rest later.

I've FTP'ed some papers on a persistant OS which I'll read soon.

Michael