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

On 10/25/2007 06:50 PM, Bill Page wrote:
> On 10/24/07, Ralf Hemmecke wrote:
>>> |   '1..' is another (better?) name for PositiveInteger
>>>
>>> No, it is not.  Both behave quite differently in many situations.
>> What?
>>
>> Suppose I have given
>>
>>    PositiveIntegerCategory
>>
>> and suppose
>>
>>    PositiveInteger: PositiveIntegerCategory == add {...}
>>
> 
> In the existing Axiom library PositiveInteger is a subdomain of
> Integer. The Axiom interpreter infers the following domain
> 
>   UniversalSegment PositiveInteger
> 
> of the expression '1..'. 'UniversalSegment(S)' includes an operation
> 'expand' that returns a Stream(S) provided S had OrderedRing.
> 
>> then
>>
>>    (..)(i: Integer): PositiveIntegerCategory == PositiveInteger
>>
>> For simplicity I simply ignore the parameter and in the following I
>> simply use an existing "IntegerType" from LibAldor.
>>
>> ---BEGIN aaa.as
>> #include "aldor"
>> #include "aldorio"
>> PositiveInteger: IntegerType == Integer add;
>> (..)(i: Integer): IntegerType == PositiveInteger add;
>> one:*Integer == 1$Integer;
>> import from one..;
>> stdout << 3 << newline;
>> ---END aaa.as
>>
>> (I don't import from Integer since I use ":*" instead of ":". Remove the
>> * and see what the compiler tells you.)
>>
>> Add the line
>>
>> for i in one.. repeat stdout << i << newline;
>>
>> to the program above and try to compile. Of course it must fail.
>>  >aldor -fx -laldor aaa.as
>> "aaa.as", line 9: for i in one.. repeat stdout << i << newline;
>>                    ....^.......^
>> [L9 C5] #2 (Error) No meaning for identifier `i'.
>> [L9 C13] #1 (Error) Argument 1 of `generator' did not match any possible
>> parameter type.
>>      The rejected type is
>>                  IntegerType with
>>                      == Posi....
>>      Expected type String.
>>
>> Since there is no function (..) which returns a Generator(Something).
>>
>> But still, I cannot see, why
>>
>>    one..
>>
>> behaves in any way different from PositiveInteger.
>>
> 
> The point is that '1..' as a 'UniversalSegment' provides only certain
> specific exports which differ from those available in
> 'PositiveInteger'.

I think, you are confusing the element-domain difference. If you say

   '1..' as a 'UniversalSegment'

that can only mean that

   1..

is of *type*

   UniversalSegment

Now, UniversalSegment(T) is a domain, so "1.." is an elment and thus 
"1.." does not export anything. (That is in total contrast to what I 
have constructed above. "one.." is a *domain* or type IntegerType.)

Ralf