To add to this, the jlId method is normally called with a class
reference as argument:
#<JLREF zzModRingElem 864811387508848656 {100304E3B3}>
And not (|NemoIntegerMod|) so the generated code seems totally wrong.
Le sam. 4 mai 2024 à 06:43, Grégory Vanuxem <g.vanu...@gmail.com> a écrit :
>
> Hello,
>
> I have found 'devaluate' in some Spad files and it can be handy. Some
> domains are parameterized and it is not possible, or at least I don't
> know how to do it, to use ' is ' instead of ' has ' (Domain vs.
> Category) for them:
>
> if R is Foo then
> new(n) == bar(n)
> else
> new...
>
> it is not possible to use:
> if Foo(p) then
>
> Or like #1 in "SubDomain(Integer, #1 >= 0)" used for NonNegativeInteger?
>
> I don't know how. So I use 'devaluate' and a 'has' after the 'is', in
> fact '=' here, see the string below, to let me gather information
> about the domain, size(), precision() etc. (the parameters) via the
> exported operations of the parent category. Think of ZMOD in a
> container as an example.
>
> But, this is not my question, sometimes using 'devaluate' breaks
> completely the code after, it's still compilable but not executable.
> Any ideas why?
> R is a Ring.
> ===== spad ===============
> NRing :String := string CAR((devaluate(R)$Lisp))$Lisp
>
> Rep := SExpression
> pprint := true
>
> getind(m) ==> concat(["getindex(", "refs,_"", jlId m, "_")"])
> =====
> And later, the above macro is incorrectly treated (jlId is defined in
> a category, and call the JLREFID *method*):
>
> >> System error:
> There is no applicable method for the generic function
> #<STANDARD-GENERIC-FUNCTION BOOT::JLREFID (1)>
> when called with arguments
> (|NemoIntegerMod|).
> See also:
> The ANSI Standard, Section 7.6.6
>
>
> A work around is:
> ================================================
> NRing := CAR((devaluate(R)$Lisp))$Lisp pretend String
> --NRing :String := string CAR((devaluate(R)$Lisp))$Lisp
>
> Rep := SExpression
> pprint := true
>
> getind(m) ==> concat(["getindex(", "refs,_"", jlId m, "_")"])
> ================================================
>
> And all becomes right... I have already encountered this issue before
> but never found where it came from, now, yes!
> And even a workaround. Before, I think it was adding some code between
> the 'devaluate' and the macro that did the job.
>
> - Greg
--
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 fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/CAHnU2dYeLXM1Uj%2BjLA-FNAFxjjGC8ts93%3Dmr48oA2oDeqUBLbQ%40mail.gmail.com.
