OS design... (fwd)

[Francois-Rene Rideau]

Dear Alexis,
  well, first, I think you should use a better mailer and/or better
mail quoting manners -- your mail is unreadable.


>>: Jecel
>: Alexis

>> In short - any distribution system that depends on people getting things
>> right will only work some of the time.
>
> is juice considered to be the best way currently of distributing code?

Juice only covers extensional issues: internal semantics of code being
transported. It covers it well, but it doesn't cover intensional issues:
the externalities that David talked about (dependencies, paths, etc),
which are also what Jecel sees that fails about most package systems.
This is a difficult, but completely independent, language issue:
how do we manage consistent intensional naming and/or
extensional specification of modules accross machines?

We need to build into our language a package system that stands
the test of multi-versioning and name clashes,
and ensures as much as possible preservation
of essential semantics constraints, as well as of intensional identity.

The intensional part might begin with global naming and versioning
in a rootless tree-structured way (a tree without priviledgeda global root).
The extensional part might begin with a way to specify precise interfaces
(i.e. "I want a module that has such semantic properties", instead of
"I want a module named X"), and to extract objects (extensions) from
projects (intensions) whose interfaces (limits) are well-specified.


> ie. a higher-order extensional modular state that contains a global ID, is
> secure and can be filtered according to the users wishes.
Extension, identity, and security are orthogonal features.

> Now, on a practical side, this "language" needs to be extensible with type
> constraints imposed AS IT IS EXTENDED, to allow a consistent "interface".
Sure. That's what reflection is about: dynamically extend the language
and the constraints that can be expressed.

> Why advovate LISP with extensions Fare?
Because LISP was designed as a minimal reflective language already,
and has a clean syntax, with well-defined semantics, and a long tradition
of being able to reflectively self-extend itself so as to express anything
that any other language ever did. Plus the messages of this thread began
as a crosspost to lispos@math.gatech.edu.

> Why not extend ISL (xerox-parc offering) or Oberon or BETA or NESL etc?
I never heard about ISL.
Oberon sucks (not even higher-order functions are real GC!)
BETA looks interesting but the semantics is not quite clear to me.
NESL I haven't looked at yet.

## Faré | VN: Уng-Vû Bân   | Join the TUNES project!  http://www.tunes.org/ ##
## FR: François-René Rideau |    TUNES is a Useful, Not Expedient System     ##
## Reflection&Cybernethics  | Project for a Free Reflective Computing System ##
Better, faster, cheaper - pick any two.