> Internal objects of Tunes should be stable. External objects > must be isolated. The fundamental role of an OS is > to provide isolation, in my view. No. An OS should provide a dependable frame for computing. If the objects involved are completely unsecure, then yes, there should be isolation. But else not. > This is what i'd call a kernel, it > serves as a device driver for the processsor and memory and provides > some unit of isolation. > why call this a kernel? well, why not? Because when we isolate processes, it's not some centralized software that manages it all, but a process-dependent module. Not a kernel at all. Different objects may be isolated by different modules; every one is free. > it's just a customary name for sth that looks like part of the > machine, form the s/w point of view. isolation is no kernel; just a module among others. >

> What should our unit of isolation be?

> 	Agent/Actor/Module/Process/Thread ? Space/Domain/Context ?
> Which of these are identical? The first four and the last > three? There seem to be light and heavy versions of both: > A thread is a light process, a space is a light domain. Let just not have isolation (in the unix meaning) waste our life. Isolation a la unix (cf. Glossary) is for unsecure objects; when we do have such objects (e.g. when emulating DOS or Unix; or when allowing the user to "admit" unsure axioms), we do need isolation. But > What memory model will we use? One virtual address space for all > processes/domains (newton)? Or a separate address space for every > domain (spring)? i'd prefer the single variant. That would enable us > to get rid of the distinction b/w virtual memory and files more easy. Well, from the HLL point of view, I'd take the first model; but for implementation easiness, I'd choose the other. Can't we do that transparently ? The first model is useful to implement at low-level only if objects use world-wide distribution at the finest grain, which I don't think they do. To me, we'll have a low-level layer that deals with local objects, which can be moved accross domains. The high-level language will hide that to those who don't feel concerned (but not to the others). > >> * every object should provide for dynamic dispatch of messages, in other > >> words associate names with other objects. > i take that ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ back. i just meant "respond to > messages". still, i'd like to see the self model as the > default, it is the best one to think with. and it is not THAT > heavy, except for oddballs. What I'd add to SELF is some typing/specifications that'd add security. I'd also allow hiding sub-objects, and suches. > >> no separate naming service (as in spring). > >Well, this should be meta-space dependant. I'd like the system to be > >scalable, and objects to be strippable, so we can have light versions. > # exactly. but why does everybody say *meta*-space? this is just a > # *space*. Err, I've added a Glossary definition for it. Does it explains it well ? Basically, meta- means "that talks about". An object evolves in a space. Now, the context that defines this space evolves in a meta-space. e.g. the space in which an integer object evolves is the type of integer objects; but this type evolves in a space of types, a meta-space. But I admit the word might be sometimes overused or misused (though not as much as the term "Object-Oriented"). > # (someone has written a paper titled "Meta? What do you mean, > # `Meta'?" anybopdy know where to get it?). No, but I'm interested if you find it. > # it is a standard(?) > # implementation technique in lisp-systems that all of the different types > # of objects live in different address regions. the objects don't contain > # an explicit link to their description, their types are identified by > # position. this also makes it easier to manage them. of course, there > # may still be a space that does allow per-object change of > # type and behavior. Well, this allows tagging objects according to their type; much useful technique. Big object can suffer the overhead of having individual description fields (aka meta-information) (see Apertos), but not small ones. This method allows to identify a small object's type by their address. >

  • Interactivity
  • [this is superfluous, cancel it. maybe put > it in a new section `expected payoffs'.] Well, I admit it brings little, but it may not be obvious to most readers. If I create such "payoff" section, how will I organize it ? >
  • Attributes[i don't get this. *drool* what would be an exmple for > an attribute? a feature? what about "objects that have code"?] Attribute may or may not have explicit code. A field in a structure can be the structure's attribute, or it can be the associated value in a hash table, or yes, the result of a function call. >
  • Access rights are implemented through HLL context and > scoping. [sounds interesting. could you elaborate?] See the "Semantics" file... > completely read-only. [but not constant] Particularly, you can't > change an attribute's value if you don't have the proper "rights". I wasn't clear enough. Read-only only is nice; constant is nicer even; so when one is possible, it shall be used. > as type checking, if we use a good type system [annotated > bibliography, please] Well, I'll point you to the Coq manual, inside the Coq distribution. (see "Related Works" for a pointer to Coq, or ftp.inria.fr:/local/coq/). > attribute/function to an object. [i guess with self this means sending a > message] Yup. But we know that there is an isomorphism between Object-Oriented message sending and Functional Programming function evaluation. Why use exclusively one aspect of the isomorphism ? Let's freely use one aspect or the other. > meta-level symbol, but a zero-level object. [meta-level??? waddaya mean? > scoping? in lisp, symbols (attribute?) and functions are both > first-class objects. and lisp provides closures just like > scheme does. just that lisp symbols have cells. Oops, I meant "not a meta-level symbol, but a zero-level object", that is, function/attributes are first class dynamic objects, and not just accessible at compile time through their symbols (though the LISP evaluator "compiler" is so simple it's constantly used at run-time).