axiom-math
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Axiom-math] Re: [fricas-devel] Re: [open-axiom-devel] [fricas-devel] Re


From: Waldek Hebisch
Subject: [Axiom-math] Re: [fricas-devel] Re: [open-axiom-devel] [fricas-devel] Re: [fricas-devel] Re: iterators and cartesian product.
Date: Wed, 24 Oct 2007 03:17:09 +0200 (CEST)

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.
Even if you can avoid convertions (say by working excusively with
types) you are likely to need overloaded operations on types.
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).
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.

-- 
                              Waldek Hebisch
address@hidden 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]