Let's hack some code
Tue, 29 Apr 1997 09:38:15 +0200 (MET DST)
> Richard Coleman:
> How about CMU-CL (or) CLISP on top of the new Flux toolkit (due in May).
I admire people like you who have the energy, concentration,
and independence to undertake great software hacking.
We definitely do need more people like you.
However, I propose we take advantage of the time
before the Flux OS kit is available,
to discuss the design problems of it the project.
* what object model(s) do we want to build the OS abstractions upon?
Note that the choice of a model will tend to preclude the use
of languages that don't support it.
* what about modules? Functors? environments?
[Personally, I'd go with first-class environments,
and build modules, objects, functors, macros, dynamic scoping, reflection,
compilers, etc, on top of them]
* how much interoperability with languages like ML or Haskell
can there be in the OS?
Or will all these languages only be supported in lispOS
as Lisp is supported in Unix (i.e. not)?
* If we're to operate with recursively typed languages (such as ML),
how do we safely&efficiently exchange data between the two languages?
* Even without recursively typed languages,
many procedures in LISP languages naturally require constraints
on their arguments that correspond to recursive types;
if we want safe/efficient implementation of these procedures,
we must be able to get rid of type check without checking at everytime;
how will LispOS manage that?
* More generally, how will LispOS manage the consistency of invariants?
* Can there be user-defined invariants, or only a set of built-in invariants?
* That is, is there room for insatisfaction
with the invariants&variants LispOS
will provide (trivial strong typing, orthogonal persistence, GC)?
If there is, count me already among the future activists of meta-lispOS
to overcome these shortcomings;
If there ain't, I'm interested in how you manage to achieve that.
* My guess is only a reflective architecture allows to refine user
TUNES is a Useful, Not Expedient System