Franz Lehner wrote:
>
> The bug discussed earlier (compiler is confusing categories)
> has been hitting again.
> On Thu, Jul 09, 2009 at 05:39:44PM +0200, Waldek Hebisch wrote:
> > The error is coused by line 170 in nruncomp.boot:
> >
> > [op,[dc,:[genDeltaSig x for x in nsig]],['T,cform]]
> > ^^^^
> >
> > At first glance 'nsig' makes no sense here, after replacing it
> > by 'sig' the error goes away. But using 'sig' we get errors
> > in other places.
> I tried to build after changing 'nsig' to 'sig'
> and the build stops after compiling FS.spad
>
> ****** comp fails at level 2 with expression: ******
> (|SparseMultivariatePolynomial| | << R >> | (|Kernel| $))
> ****** level 2 ******
> $x:= R
> $m:= (Ring)
> $f:=
> ((((|opquote| #) (|opdiff| #) (~= #) (= #) ...)))
>
> >> Apparent user error:
> Cannot coerce R
> of mode (Comparable)
> to mode (Ring)
>
> and actually the compiler is right,
> at the beginning of FS.spad we find:
> ************************************************************
> FunctionSpace(R : Comparable): Category == Definition where
> ^^^^^^^^^^^^^^
> OP ==> BasicOperator
> O ==> OutputForm
> SY ==> Symbol
> N ==> NonNegativeInteger
> Z ==> Integer
> K ==> Kernel %
> Q ==> Fraction R
> PR ==> Polynomial R
> MP ==> SparseMultivariatePolynomial(R, K)
> ^
> QF==> PolynomialCategoryQuotientFunctions(IndexedExponents
> K,K,R,SparseMultivariatePolynomial(R, K),%)
> ************************************************************
> but SMP really needs a ring as first argument and Comparable
> does not make sense here, only later (after line 455)
> 455: if R has Ring then
> it makes sense and MP starts being used.
Franz, the '==>' lines are macro definitions. They are _not_
type checked. Only result of expansion is used. I remeber
that I did found some errors of similar sort, but I do not
remeber if the error were in FS. Anyway, the real errors should
be rare and easy correct.
The true problem is that when compiling code for categories
(I mean executable code) the compiler simply forgets about
conditions -- it essentially treats exported signatures as
if they had no conditions.
> Was this the reason for the change sig -> nsig?
>
As I wrote I believe that the 'sig -> nsig' is a workaround
for the problem with categories.
--
Waldek Hebisch
[email protected]
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=.
