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

[Waldek Hebisch]

> 
> Hi,
> 
>   I've been thinking about the following for a long time now, and I
> susect it is time for me to let it go to the Axiom  community for feedback.
> 
>   Spad fundamentally uses arrays of function pointers (also known as vtables)
> as implementation technology for categories, domains, packages, and 
> inheritance.  Each function defined gets a slot in a vtable (the thing that
> materializes a domain or a package) and call to that function may be
> resolved by poking at that slot and dereferencing the result. The vtable is
> an array to allow constant time indexing.  That is fast.  OK.
> 
>   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.
>

Gaby, did you look how Axiom uses arrays of function pointers?  At
the first glance they are like vtables.  But there is a fundamental
difference: Spad domain uses only its own domain vector -- it never
directly uses ancestor vector.  More precisely, at compile time
Spad compiler determines all "external" values used by given
domain and assigns them slot numbers.  There is no problem of
coherence due to fixed numbers: as long as you use the same object
file the numbers stay fixed.  Once you recompile, the numbers will
change, but the change affects all uses of given number, so things
stay consisten.   Of coures, crucial to consistency is fact that
other domains use only its own vector and do not care about
domain vectors of other domains. 

One mau ask how it is possible?  Essentially the arrays of function
pointers is a cache -- it is filled with calls to lookup routine
which a runtime fills slots with correct functions.  So actually,
spad domain vector not a vtable in OO sense, but rather a like
procedure linkage table in ELF shared library.

There are issues with coherence, but IMHO they are unavoidable
given static typechecking and dynamic runtime:  Spand compiler
checks that intefaces to domians are compatible at compile
time, but you may redefine things in incompatible way and
recompile only some objects later.  Say you compile D which
references Integer.  Later you redefine Integer in incompatible
way and recompile Integer (but keep ald object for D).  D 
references Integer by name and in fresh inage will pick
new definition of Integer, giving runtime problems.  Still,
if you just add new functions to Integer things will stay
more or less sane.
 
>   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".
> 
> Comments?
> 

IMHO using just using hastables in place of arrays does not make any
sense, because arrays are just cache lookups.  Using hastables for
core lookups make some sense -- my impression was that core lookup
used linear search.  However, then you need to face issue of coherence...
You may also think about different lookup policy, but that would
significantly change Spad semantic.

AFAICS problems of "post facto extensions" have nothing to do
with usage of arrays to cache lookups.  IMHO main problem is
that Axiom has just one "handle" to access given domain.
Namely domain Integer defines function also  named Integer
which build domain vector.  If an extension tries to redefine
Integer one looses handle to original domain.  The solution
is to have two (or more) handles: one to current interface
and one for each element of the extension set.  So domain
Integer should define Interface-Integer and Implementation-Integer.
Latey an extension MyExtension will redefine Interface-Integer
(replacing original interface by an extended one) and
Implementation-MyExtension.  Implementation-MyExtension still
can reach old Integer via Implementation-Integer and delegate
things.  In principle Interface-Integer can know that it
is implemented by Implementation-Integer and Implementation-MyExtension
and if Integer is redefined later the new interface can notice
that it also needs parts from Implementation-MyExtension.

IIUC Aldor is using sheme as above, only names differ.

-- 
                              Waldek Hebisch
address@hidden