OS design...

[zccap74]

>Fare

>Using again the LCD approach is just reinventing Unix, poorly. Plus, it
forcing
everyone to go through that common (forcibly poor) semantics is quite a waste,
when the actual languages that will communicate have semantics near to each
other and far away from the common denominator (which is also why CORBA sucks).
The only right approach is to allow users/programmers to specify explicit
"semantic bridges" between pairs of languages; these induce a category of
languages with compositions of specified bridges as functors. Various
heuristics
may help semi-automatically find a bridge between two languages that fits the
user's needs, assuming the initial graph is connected. Having a LCD is just
having the initial graph be a "star", which is quite a naive approach.

>David Jeske

>I've come to the same conclusion. However, for all of the reasons you cited in
your email I don't thin kit's practical to come up with a language neutral way
to deal with it.

>I'd much prefer to use a VM which allows extensions for every language. That
way the language can describe it's needs in it's own terms. Sure, it can
describe a basic implementation in terms of some lowest common demomenator,
however, then someone can later go in and optimize the LISP case if they so
choose.

>There is a fine line, when doing this, between just distributing >source, and
coming up with a usefully abstract but specific VM >representation. For many
languages/applications, people are not >comfortable releasing source, thus the
need for some compiled form.

>-- Jecel

>In short - any distribution system that depends on people getting things right
will only work some of the time.

Ok,so it seems like the way forward is a semantic-bridge "language" (for want
of
a better word) that includes a descriptive framework (meta-model) such that
each
object or group of objects exists in an 'executable software distribution
model'

ie. a higher-order extensional modular state that contains a global ID, is
secure
and can be filtered according to the users wishes.

Now, on a practical side, this "language" needs to be extensible with type
constraints imposed AS IT IS EXTENDED, to allow a consistent "interface". Why
advovate LISP with extensions Fare? Why not extend ISL (xerox-parc offering) or
Oberon or BETA or NESL etc?

Basically, if we have a good meta-model, most code can be adapted to feature it
and thus becomes part of the TUNES system as the meta-model controls the
code-object.

I've yet to look at the example from Tril, and how it relates to the above as
I'm
quite busy organising my gymnastics crowd..

Looking forward to the replies...
Alexis