[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Axiom-developer] Spad and its object model
From: |
Stephen Wilson |
Subject: |
Re: [Axiom-developer] Spad and its object model |
Date: |
11 Jun 2007 13:15:02 -0400 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 |
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
- Re: [Axiom-developer] Spad and its object model, (continued)
- Re: [Axiom-developer] Spad and its object model, Martin Rubey, 2007/06/11
- Re: [Axiom-developer] Spad and its object model, Ralf Hemmecke, 2007/06/11
- Re: [Axiom-developer] Spad and its object model, Stephen Wilson, 2007/06/11
- Re: [Axiom-developer] Spad and its object model, Ralf Hemmecke, 2007/06/11
- Re: [Axiom-developer] Spad and its object model, Stephen Wilson, 2007/06/11
- Re: [Axiom-developer] Spad and its object model, Ralf Hemmecke, 2007/06/11
- Re: [Axiom-developer] Spad and its object model, Stephen Wilson, 2007/06/11
- Re: [Axiom-developer] Spad and its object model, Franz Lehner, 2007/06/11
- Re: [Axiom-developer] Spad and its object model, Ralf Hemmecke, 2007/06/11
Re: [Axiom-developer] Spad and its object model, Gabriel Dos Reis, 2007/06/11
- Re: [Axiom-developer] Spad and its object model,
Stephen Wilson <=
- Re: [Axiom-developer] Spad and its object model, Gabriel Dos Reis, 2007/06/11
- Re: [Axiom-developer] Spad and its object model, Stephen Wilson, 2007/06/11
- Re: [Axiom-developer] Spad and its object model, Gabriel Dos Reis, 2007/06/11
- Re: [Axiom-developer] Spad and its object model, Stephen Wilson, 2007/06/11
- Re: [Axiom-developer] Spad and its object model, Gabriel Dos Reis, 2007/06/11
- Re: [Axiom-developer] Spad and its object model, Stephen Wilson, 2007/06/11
- Re: [Axiom-developer] Spad and its object model, Gabriel Dos Reis, 2007/06/11
- Re: [Axiom-developer] Spad and its object model, Stephen Wilson, 2007/06/11
- Re: [Axiom-developer] Spad and its object model, Gabriel Dos Reis, 2007/06/12
- Re: [Axiom-developer] Spad and its object model, Stephen Wilson, 2007/06/12