[Axiom-math] Re: [fricas-devel] Re: [open-axiom-devel] [fricas-devel] Re: [fricas-devel] Re: iterators and cartesian product.

[Bill Page]

On 10/23/07, Waldek Hebisch wrote:
>
> Bill Page wrote:
> > Yes, under this proposal '1..9' would be a domain consisting of the
> > set of the first 9 positive integers. I want to consider the view that
> > this is the same as thinking of 'PositiveInteger' as a sub-domain of
> > 'Integer'. So like 'PositiveInteger', '1..9' would inherit some of the
> > structure of Integer, specifically 'OrderedSet', plus exports from
> > 'Finite' and the operations 'high', 'low' and 'incr' of
> > 'SegmentCategory'. However 'SEGMENT', 'BY' and 'convert' of the
> > existing 'SegmentCategory' would have to become domain constructors.
> >
> > In general I am wondering about "set-like" objects and whether these
> > should always be modeled as domains.
> >
>
> I must say that I find this idea very problematic.  Why?  It seems
> that you require automatic convertions between normal data and types.

Can you elaborate on the distinction between "normal data" and
"types". What is an example of such a conversion?

I have considered for example that perhaps '1..9' should actually be
an object of type 'Segment(PositiveInteger)' as it is now, but that
one should be able to (automatically) coerce such an object to an
equivalent domain. Martin Rubey has given an example of such a
construction in Aldor. Perhaps to extend Spad to make this possible
might not be too difficult?

> Even if you can avoid convertions (say by working excusively with
> types) you are likely to need overloaded operations on types.

So far in what I have proposed I do not think I require any such
"overloaded operations on types", but let me imagine what you might
mean. We would like of course operations like 'union' on Set, but if
sets { } are domains then 'union' must be a domain constructor. The
fundamental problem that we would have I think is dereferencing (and
evaluation) of such type expressions, i.e.

  {1,2,3} union {4,5}  = {1,2} union {3,4,5} = {1,2,3,4,5}

In Spad (and Aldor) as they exist now, I think this would be very
problematic if one tried to carry out my suggestion that *all*
set-like objects be implemented as domains.

> It looks that you want violate what I consider to be very useful
> limitation of Spad (see below).  You can avoid most problems
> working with objects as demostrated by Aldor generators (general
> generators are hard to implement efficiently, but at least can be
> implemented and difficulties are well understood).
>
> Now, why I do not want to allow overloading of Spad that constructors
> (one may think that builtin constructors are overloaded, but builtins
> are special, and they are really not overloaded but rather variadic).

Gaby has suggested a construction such as

   X : List Type := [Integer, Float, String]

so writing

    Product [1..3,2..4,3..5]

is not problematic as far as the arity of the domain constructor is concerned.

> This restriction means that overloads can be statically determinded
> by a rather simple algorithm working separately on each function.
> With overloaded types it seems only global constraint solving
> could work, which is much more complex.  One might think that
> difficulties of implementation could be ignored.  But I am affraid
> that humans may have even more problems with overloaded types.
>

Can you give an example of a construction that would cause such problems?

Regards,
Bill Page.