HLL/INT: What is an object, anyway?

[The MOOSE project]

>   - I really loved reading about MIT's `exo'kernel.  That's exactly what
>     I want: `somewhat' standardized device drivers for the time and space
>     ressources.  (Oops, I just mistyped `satandardized'.  Does this tell
>     us anything about the word `standardized'? ;-) That's the equivalent
>     of Emacs in the field of OSs.
   I'm not sure what you mean about standardized device drivers or about
Emacs either.


>   - What is Tunes?  A protocol?  A set of standard (alternative) libraries?
>     What is the difference b/w an exokernel and Tunes?
   Tunes provides more than just an exokernel. An exokernel is a second-order
tool to dynamically link modules to the hardware. Exokernels are quite of an
improvements over current first-order kernels. Now why restrict to second-order
and to hardware ? And why restrict security to some statically defined,
limited, type-system, as done in SPIN, when there is one (does Aegis have
even such protection ?) ?
   Tunes is a higher-order unified secure module system.
It is not limited in abstraction or security; it concerns all the layers
of the system, not just the hardware layer, or a one static high-level
language. Thus, Tunes will include more than an exokernel, an exo-exo-kernel,
or even an exo(n)-kernel.


>   - Farč's object definition:
That's Faré, not Farč ;)

>>  So my definition for an object would be:
>>  "anything whose semantics can be finitely coded into a Turing Machine".
>     Oh, sh**.  Do we really need that?  I hope we don't.
   You mean actually coding into Turing machines ?
   Well, that's kindof a philosophical definition, and only shows one
aspect of things.


>     Maybe the java
>     bytecode is OK as a LLL?
   I haven't seen it. But again, there is a question about the goals
of the LLL subproject, which currently has no coordinator (I'm only
an interim maintainer), particularly as for the portability required
for it, and how roles are distributed between HLL, LLL, and Migration
subprojects: at what level should what translations be done ?
   I've proposed that each subprojects defines its own languages, in
collaboration with the other two, and that each pair of subproject is
responsible for translators to be written between the two.


>     Glossary entries for the languages with links to their description
>     in the Review project will be the right thing - gimme one week.
> 
>     Could anybody write a 'diff Lisp SML' ?
   I can, when I have time.
   Basically, LISP objects are definable as a one multi-case
ML type; as static programs, ML is thus an extension of LISP,
and its type system is indeed much richer than that of LISP.
   LISP is also very low-level, and too many things are mutable.
   But LISP's syntax also has a lot of reflectivity (macros,
special forms and quoting), which ML completely lacks. Even
higher-order functions are limited in ML because of strictness,
heavy syntax, and a rich-but-not-enough type system.
   More some day....


>     Could anybody write a 'diff Lisp Haskell' ?
   I wish I could.

>     Could anybody write a 'diff Self BETA' ?
   I can't.

-- 
--    ,        	                                ,           _ v    ~  ^  --
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
--                                      '                   / .          --
Join the TUNES project for a computing system based on computing freedom !
		   TUNES is a Useful, Not Expedient System
WWW page at URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"