Slots

[Akim Demaille]

Hi Claire people!

I am currently working on a prototype based language. It is largely
inspired by Io, Self and others, including Claire/Laure. Objects are
currently implemented as dictionaries mapping symbols to objects. I
am not satisfied by our support for attribute accessors.

Just like in Eiffel, I believe that whether something is an attribute
or a 0-ary function is an implementation matter, therefore in our
language 0-ary function calls do not require parens, and the user does
not know whether she is using a computed value or a stored value. So
far, so good for read accessors.

Wrt write accessors, I want to capture assignments and transform them
into function calls - what people seem to enjoy calling "setters", at
least in C# parlance.

In Self this is done via a "foo:" slot that is associated to the data
slot "foo". This is interesting, but we believe we will probably need
several prototypal behaviors for our slots (some behave like proxies
to distant resources, some should check the values verify some
invariants etc.) therefore I tend to think everything related to a
slot should be encapsulated into a slot object/hierarchy. That is,
instead of "Object = map[symbol => object]", I consider "object =
list[slot]" and "slot = (name, object)" (and possibly other slots,
typically get/set for accessors).

But there is a host of questions I'm not sure how to answer.

I'm a little worried with the chicken and egg problem here (reading an
object slot means getting a slot-object and reading one of its
slots...).

I'm also concerned with the cost that this incurs: twice as many
indirections.

So I was looking for inspiration in Claire's model, but I am a bit
lost (the inspector does not seem to be interactive, and I am not
fluent enough in claire to explore everything, even though I know the
answer is there since the system is reflexive).

- do slots in Claire contain their name?

- I seem to understand that not all slots are reified? So maybe I
misunderstood and Claire's object model is more like "symbol ->
object" and if that object turns out to be derive from "slot", then it
has a specific handling?

- can object share reified slots?

More generally, where could I find a model (say UML or whatever) of
Claire's world? The documentation pays special attention to the
functions, and AFAICS, gives little attention to the object hierarchy.

Thanks in advance!

PS/ Maybe this message should not be sent to xlclaire, but claire-
language.com seems dead. So dead actually that even points to
clairelanguage.com instead of claire-language.com.

[sylvain]

Akim Demaille a écrit :
> Hi Claire people!

I Akim,

A few words about the inspector :

The inspector is interactive but has some subtleties. Mostly, from the
claire interpreter you'll ask for the inspection of an entity with the
ask mark (?), for instance you can explore the definition of the slot
class :

default memory size by 2^3 and 2^3, Loglist = 21
-- CLAIRE run-time library v3.3.37 [os:Darwin-ppc-g++4.0.1, C++:g++]
--
[5044]claire> ? slot
eval[1]> 1: isa = class
2: name = claire/"slot"
3: comment = "slot"
4: slots = (isa @ object, module! @ restriction, comment @
restriction, domain @ restriction, range @ restriction,
selector @ restriction, mClaire/srange @ slot, default @ slot,
mClaire/index @ slot)
5: superclass = restriction
6: subclass = {}
7: ancestors = list<class>(void, any, object, system_object,
restriction, slot)
8: descendents = set<class>(slot)
9: mClaire/evaluate = #'self_eval_ClaireObject
10: open = 1
11: instances = (isa @ object, name @ symbol, module! @ symbol,
mClaire/definition @ symbol, value @ symbol,
mClaire/freeme? @ freeable_object, name @ class, comment @ class,
slots @ class) ...
12: mClaire/prototype = (0, 0, 0, list<type>(), any, 0, 0, unknown, 0)
13: params = ()
14: mClaire/dictionary = (unknown, unknown, unknown, self_print @
restriction, blob! @ void, Serialize/ibserialize @ restriction,
self_eval @ object, iClaire/equip @ list<type>(any, list), echo @
any) ...
15: ident? = true
16: if_write = unknown
17: mClaire/dispatcher = ()
inspect>


The 'inspect>' prompt tells you that you are in the inspector toplevel
(enter 'q' to come back the interpreter). To explore deeper through
the printed relations you can enter the associated index and then use
'up' to come back to the explored entity.

When you enter something different from an index, 'up' or 'q' then the
inspector will apply on the entity that is read without evalution. So
if its a symbol (a class name, a porperty name...) the exploration
applies on that entity, if its a bag (list, set, tuple) then you'll
explore tits content, otherwise you will inspect the meta instruction
built by the Reader before its evaluation (this later feature is only
available in XL claire).

> - do slots in Claire contain their name?
>
> - I seem to understand that not all slots are reified? So maybe I
> misunderstood and Claire's object model is more like "symbol ->
> object" and if that object turns out to be derive from "slot", then it
> has a specific handling?
>
> - can object share reified slots?
>
> More generally, where could I find a model (say UML or whatever) of
> Claire's world? The documentation pays special attention to the
> functions, and AFAICS, gives little attention to the object hierarchy.

I'm afraid there is no UML model available. Using the reflexion of the
language it could however be generated on the fly provided an
appropriate piece of code... I suggest that, for the moment, you use
the inspector to travel accross relation that exists between system
objects.

In claire, both slot and method inherit from the class relation. A
relation associates a name to a domain (a list of type). For slots,
the domain contain a single type which is the class in which the slot
is defined. The interpreted code always use the relation to evaluate a
slot access/update but the compiler will transform it either in a call
to an ad hoc deamon function or a standard C++ indirection when the
access/update does not trigger complex things.

The role of the relation class is central and drive whether it can be
extended, whether it has an inverse relation if a rule is associated
to it or even if the update is defeasible.

The model in claire is better desrcibed as an "entity -> relation"
than a "symbol -> object".

> Thanks in advance!
>
> PS/ Maybe this message should not be sent to xlclaire, but claire-
> language.com seems dead. So dead actually that even points to
> clairelanguage.com instead of claire-language.com.

You're at the right place ! You're welcome to discuss about claire
model here.


Regards,
Sylvain