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

[Ralf Hemmecke]

William Sit wrote:
> > > It is useful, for example, to be
> > > able to distinguish whether a field is a quotient field of some integral domain
> > > or just a field to make codes more efficient. The request was not acted upon
> > > because at the time (around 1990 +/- 3 years?), effort was concentrated on
> > > developing the Aldor (A#) compiler, which promised to solve such problems.
> >
> > However, I somehow do not think that
> > being able to query the structure of a type is a good idea. You gave a
> > good reason, but isn't there a better way to achieve efficiency?

> Yes, but another reason, in the above example of field, is in allowing
> generalizations to work, not just efficiency due to data representation
> (reducing computation in the field to that in the underlying integral domain, as
> in Grobner bases computation). 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. If we COULD ask whether R is a quotient field (not just a field)
> and if in case of affirmative answer also find out the underlying integral
> domain S of R = FRAC S, we would be able to replace R by S for the package.

Hmm, but one can also achieve what you want by adding a function to the 
Fraction constructor

Fraction(R: IntegralDomain): with {
  ...
  fractionField: Boolean;
  underlyingDomain: IntegralDomain;
  ...
} == add {
  fractionField: Boolean == true;
  underlyingDomain: IntegralDomain == R;
  ...
}

If one then gets a field K, one just has to ask

if K has with {fractionField: Boolean} then {
   Groebner(underlyingDomain K, coercedPolys);
} else {
  Groebner(K, polys);
}

Ralf