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

[Stephen Wilson]

Ralf Hemmecke <address@hidden> writes:

>  > One basic rule would be that a domain `functor' memoizes its
>  > arguments, and always returns the same object for equal arguments,
>  > performing any required initialization on the first call.
> 
> Of course you know that globally defined functors can be called in a
> local environment which would allow Foo(Integer) and Foo(Integer) to
> be different things in different contexts of the same program.

Yes.  But those would be two different functors.  The same rules would
apply independently to both.

>  > Of course
>  > equality is an issue in and of itself, but (for the purpos of functor
>  > memoization) my feeling is that Integer should not be equal to 'extend
>  > Integer ...'  except when the extension is empty.
> 
> Ask two mathematician of all the properties of "integer". They
> probably tell you different sets of functions. But if we use Integer
> in a program all we care about is what properties it has at the time
> we use it.

The rules I gave jive with my personal understanding of Aldor
semantics (despite the semantics are not strictly specified).  I
wanted to present some rules which were consistent with others
experience and expectations.

However, I am more than open to the possibility of providing a more
general mechanism.

> How would you distinguish 'Integer' from 'extend Integer' anyway? I
> think for me the difference is irrelevant. All I want to see is
> Integer and not Integer1, Integer2, etc.

This is basicly what you get in Aldor.  The virtue of the rules I gave
is that they are dirt simple.  Do you know of a way to define functor
application and the calculation of predicated exports which `works'
naturally when extend is involved, but that does not yield such
`versioned domains'?

>  > Furthere, no
>  > extended domain D would be equal to any other extension of D,
>  > similarly for extensions of extensions, etc.
> 
>  > As an aside, I feel that runtime equality checks on values (domain
>  > elements) should be permited only for those domains which implement
>  > BasicType (in which case I would support making BasicType a primitive
>  > language defined category).
> 
> Why should BasicType (i.e. =:(%,%)->Boolean) be a primitive? I don't
> see any need.

The basic rationale is that in order to memoize a functor, we need an
equality test for its arguments.  For domain elements, it seems only
natural to have a canonical place to define what equality means for
that domain.  This is in contrast to the compiler choosing what
equality means.  For example, the compiler might choose pointer
equality, but then it is likely that two bignums, although numericly
equal, would compare as different.  That is the kind of situation im
trying to avoid with my sugesstion.

> 
>  > Another option being to use whatever
>  > export '=: (%, %) -> Boolean' the domain admits, or perhaps the
>  > equivalent Aldor `generic tie-in' which I think is `test'.
> 
> What? "test" is not a replacement for "=" in Aldor.

Ah, now I recall. "test" serves as a coercion to boolean values.  It
was "case" that I was thinking about, as used in Aldors select
statement.  "case" is not a replacement for "=", but is used as a
`canonical' name for the purpose of equality testing in compiler
generated constructs.

My point is that the user should have a facility to define equality
and the compiler should respect that definition at runtime. 

>  > I strongly feel that SPAD should define precise semantics for any
>  > notion of equality used by the compiler.
> 
> If I am not completely wrong then Aldor does not define any meaning
> for =. It is a function as any other that a user defines.

>From memory, I agree.

> In Aldor one cannot currently compile something like
> 
>    if T = Integer then ... else ...
> 
> because there is no (implementation of a) function
> 
>    =: (Type, Type) -> Boolean
> 
> and defining one yourself you would have to use "pretend Pointer". But
> even then I guess it might happen that you have "T=T" returning false.

Precisely.


Steve