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

[Gabriel Dos Reis]

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.

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

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

-- Gaby