Re: [Axiom-developer] Spad and its object model

[Stephen Wilson]

Gabriel Dos Reis <address@hidden> writes:

> On Sun, 10 Jun 2007, Stephen Wilson wrote:
> 
> | Hello Gaby,
> | 
> | Gabriel Dos Reis <address@hidden> writes:
> | [...]
> | >   However, I do believe the use of arrays has inherent problems in 
> | > terms of maintaining coherence of function pointers assigned to slots.
> | > Because the mapping from declarations order to integer has lost important
> | > informations (name, types, etc) of the functions being mapped.
> | 
> | Im not sure if this is fundamental to an array.  I think it is
> | entierly possible to define vtable elements at a fixed offset which
> | provide alternative methods of indexing.  Indeed, I belive the current
> | layout provides such a rudimentary facility of mapping export labels
> | to arity and argument type information, but the details escape me (Its
> | been a long time since I looked at this.  I recall making notes.  I
> | need to do some digging).
> 
> I'm not sure I agree.  For the array representation, numeric integrs
> are the key.  The only information they carry is the order of
> declaration.  In a context where declarations are scatered over
> different modules  (or files), there no longer is a natural order
> of declarations.  Chaos ensures.

Notice that I said the vtable could have a entry to provide
alternative indexing strategies at a _fixed_ offset.  Such an entry
could be a hash, an assoc list, etc.  The current vtables do have such
a stucture.  I belive the following mappings are currently possible
(but this is only theory, I need to work out the details):

     index -> function slot
     index -> name
     name -> arity
     name -> target type
     name -> argument type(s)
     name -> index

This is not a complete list.  For example we could map a type
signature to the list of exports which satisfy.

Spad vtables potentially support many types of keys for indexing, not
just integers.

> | >   I would like to suggest the idea of using hastables as opposed to
> | > arrays to implement vtables (materialization of domains and packages).
> | > Not only it would help tame the problem of coherence, but also move
> | > to functionalities like "post facto extensions".
> | 
> | Roughly, what are the keys?  What do the entries look like?
> 
> The keys would be faithfull encodings of operation names, their types
> (and possibly their scope, in case we go with nested scopes).

OK.  My initial feeling is that there would be a great deal of
overhead involved in computing the hashes for such keys.  Caching
would help but would that not provide an opportunity for coherence
problems to arise?

> | I assume "post facto extensions" motivate the choice of a hash as they
> | are easily extensible (new elements are readily added).  Could we not
> | simply make vtable vectors expressly adjustable?
> 
> The fundamental problem I see there is that there is no natural
> order of declarations, so the real problem is not that the vtable
> has a fixed lenght; it is because it is very tricky to ensure consistency.

I hope I have a clear understanding of your concerns.

> | I would need a clear picture of what the semantics would be for "post
> | facto extensions".  Do you sugest following Aldor explicitly? IIRC new
> | exports introduced by `extend' are not visible to previous
> | definitions, except via `has' predicates which execute during
> | runtime.  Are there other issues involved?
> 
> If you do static resolution of names (which I believe we should retain),
> then "future" dos not interfer with "past".

I think I understand your statement, but not how it connects.  `has'
is (in part) an introspective runtime operation.  Often the argument
contains a free variable.  I dont see how static resolution of names
fits in this context.


Thanks,
Steve