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.