On 04/09/2017 07:17 PM, Waldek Hebisch wrote:
> Ralf Hemmecke wrote:
>>
>> Hi,
>>
>> I just wanted to report that the fricas-aldor interface compilation
>> fails with trunk at the moment.
>>
>> The reason is most probably in bezout.spad
>>
>> if R has CommutativeRing then
>> subresultants : (UP, UP) -> IndexedVector(UP, 0)
>>
>> Somehow the corresponding lines in the generated .ap file are
>>
>> (|If| (|Test| (|Has| |#1| |CommutativeRing|))
>> (|Sequence|
>> (|Declare| |subresultants|
>> (|Apply| -> (|Comma| |#2| |#2|)
>> (|Apply| |IndexedVector|
>> (|PretendTo| |#2|
>> (|Apply| |UnivariatePolynomialCategory|
>> (|PretendTo| |#1|
>> (|With| (|Apply| |Join| |CommutativeRing| |Ring|)
>> NIL))))
>> (|RestrictTo| (|LitInteger| "0") |PositiveInteger|))))
>>
>> And the Aldor compiler then reports
>>
>> #1 (Error) Argument 2 of `IndexedVector' did not match any possible
>> parameter type.
>> The rejected type is PositiveInteger.
>> Expected type Integer.
>>
>> I don't yet have an idea why some program thinks it must convert the
>> literal 0 into PositiveInteger instead of Integer, because IndexedVector
>> is clearly defined with second argument being of type Integer.
>
> In 'ax.boot' we have:
>
> axFormatType(typeform) ==
> atom typeform =>
> typeform = '$ => '%
> STRINGP typeform =>
> ['Apply,'Enumeration, INTERN typeform]
> INTEGERP typeform =>
> -- need to test for PositiveInteger vs Integer
> axAddLiteral('integer, 'PositiveInteger, 'Literal)
> ['RestrictTo, ['LitInteger, STRINGIMAGE typeform ], 'PositiveInteger]
> ....
>
> So 'PositiveInteger' seem to come from the code above. Clearly we
> need smarter version of 'axFormatType'. As quick fix something like
>
> ....
> INTEGERP typeform =>
> typeform = 0 =>
> ['RestrictTo, ['LitInteger, '"0"], 'Integer]
> ...
>
> may do.
Thanks for this hint.
I haven't tested yet, but it seems that you additional line would be a
hack that would work. I probably have to add
axAddLiteral('integer, 'Integer, 'Literal)
as well.
However, I don't think that this is appropriate for the general case. In
fact, a proper solution would have to figure out the type from the
calling function and then use this type for the conversion of the
Literal. However, it seems that at the time when the literal is going to
be treated, the type information from above the tree is no longer
retrievable. So it looks like providing a solution in a hacky way is
much simpler than rewriting the whole ".ap" generation.
I guess the most important line actually is the "axAddLiteral" line,
because that leads to generating an
(|Import| (|With| NIL (|Declare| |integer| (|Apply| -> |Literal| %)))
|PositiveInteger|)
so the Aldor compiler could (and probably would) figure out itself that
0 is to be treated as an Integer. Still the aldor compiler needs the
information that such conversion from Literal to Integer is in scope.
Ralf
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
