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

[William Sit]

Martin Rubey wrote:
> 
> Ralf Hemmecke writes:
>  > William Sit wrote:
>  >
>  > > For example, if I have a constructor that requires an integral domain R 
> as
>  > > a parameter, and I constructed in the package the quotient field of R, as
>  > > you may suggest as an explicit way to achieve efficiency, then the 
> package
>  > > will FAIL if R is actually a field (you can consider this as a bug if you
>  > > like), even though a field IS an integral domain, mathematically.
> 
> Why would it fail? I don't think it does, in fact. However, if you are going 
> to
> apply FRAC you can simply ask whether the domain is a Field.

Mathematically speaking, it should not, but one is still creating only an
isomorphic copy (presumably with a less efficient data structure) since the
total quotient ring of a field is isomorphic to the field itself. However, while
FRAC FRAC INT in the interpreter seems to return a valid domain, a: FRAC FRAC
INT would return an error that the type is invalid. The problem is the current
algebra code for FRAC does not anticipate a field as its argument because it was
implemented as the localization of the ring with respect to a multipicatively
closed set.
 
> On the other hand, given a Field to ask whether it is a QuotientField is a
> question that I consider quite important.
> 
> However, the desirable query
> 
>   if R has QuotientField S
> 
> thus defining S is, I think, quite difficult to implement sensibly. 

Not only that, such a use is limited because it requires the user to supply S
already.

> Throughout
> Axiom, this effect is obtained by adding another parameter to the
> Package/Domain signature like:
> 
> MyPackage(F: Field, S: IntegralDomain): ...
> 
>   if F is Fraction S then
> 
> Martin

This construction certainly is because Axiom does not support querying the
parameters of a constructor from a domain resulting from that constructor. So if
some function returns a domain (constructors are such functions), the domain
already hides its parameters unless the author deliberately provides functions
to return such information (as suggested by Ralf).

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,
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.  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: what I called operations ON the objects,
not USING the objects. Only by having operations ON the objects can one add
operations USING the objects. This feature would facilitate simplification of
type construction such as FRAC FRAC INT to just FRAC INT, making them valid as
well as efficiently and trivially implementable.

William