Re: [Axiom-developer] RE: Types as values, and Re: Static versusDynamicallytyped(was:Philosophy... )

[Ralf Hemmecke]

William Sit wrote:
> Besides requiring a priori knowledge of S, the above "work around" does not help
> with the constructor FRAC when its parameter is a field (not to mention when it
> is FRAC S for some S). Ideally, FRAC F when F is a field should simply return F,

In fraction.spac the Fraction code starts with
Fraction(S: IntegralDomain): QuotientFieldCategory S with
  if S has IntegerNumberSystem and S has OpenMath then OpenMath
  if S has canonical and S has GcdDomain and S has canonicalUnitNormal
      then canonical
 == LocalAlgebra(S, S, S) add
  ...

Isn't it allowed to modify this to

 == if F has Field
      then F
      else LocalAlgebra(S, S, S) add ...

> but then since F need not be of the form FRAC R for an integral domain R (for
> example when F is a finite field), it would be meaningless to export functions
> like numerator or denominator. But this necessitates recursive inquiry if R may
> itself be a field. To avoid all such problems, Axiom (probably just the
> interpreter) forbids FRAC FRAC INT.

It seems that the interpreter knows more about algebra as I would like. 
If one does not like FRAC FRAC INT then is should clearly be specified 
somewhere and not hidden in the interpreter. IMHO, the interpreter 
should interpret, but not add "implicit knowledge" that is not in the 
SPAD code itself.

> If it is possible to inquire about the
> parameters or even the constructor of F (by this I mean, is F has the form  FRAC
> S, or FF(p, n), etc without having the user to specify any S, p, or n), and to
> return info on the parameters, then types and domains can be truly analogous to
> normal data objects: we are able to look into the entries of a matrix, or the
> terms and coefficients of a polynomial

Yes, we are able to look inside a matrix and even to modify entries 
destructively, but this only works because the designer of the Matrix 
has given enough exports to do so. Otherwise Matrix would just be a 
black box which might have properties like, for example, Algebra(R). 
Good enough for some algorithms, but probably not what an ordinary 
person thinks about matrices.

That is why I think that an explicit export of a function that returns 
the parameter domain would be the better way to go. If Q = FRAC R and 
one wants to get out R from Q, it is basically the same as asking to get
1 out of x (where x was previously obtained by x := inc(1). Or was it
x:=lenght("a") and one wants to get "a"?

Ralf