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

[Gabriel Dos Reis]

On Mon, 11 Jun 2007, Stephen Wilson wrote:

| 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.

I guess what I trying to get at is what are the benefits of those 
additional indirections over simple, hash table representation.

>From all I can see, the "index" key relies on order declaration which is a
non-started.  The scheme "name" key is essentiablly equivalent to using a hash
table.  If an extrat indirection is required to get the type, what is he
point?  

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

Maybe.  I'm talking of Spad and its object model representation as of today.
I'm considering ways to get supports verification and extensions without
excessive performance regression.  

| > | >   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.

If you use strings as encoding (traditional technique), then what you really
put in the hastable is the symbol whose name is the encoding.  In that case,
the "intern" operation is done by the compiler, NOT at runtime, and look
up is quite fast.

|  Caching
| would help but would that not provide an opportunity for coherence
| problems to arise?

More specificaly?

[...]

| > | 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.

There are two stages operations:  static resolution of (function) names,
and dynamic resolution of the residual.

|  Often the argument
| contains a free variable.  I dont see how static resolution of names
| fits in this context.

Example of cases where it won't work?

The hashtable repreentation vs. array representation has no semantics effect
on well formed programs.

-- Gaby