x exquo y ==
zero? y => "failed"
z: % := (INTEXQUO(x, y)$Lisp) pretend %
NULL(z)$Lisp => "failed"
z
The above, i.e. with explicitly pretending %, compiles perfectly.
> The point of above is that something like current SExpression will
> stay. Of course, when possible we want higher level code. But in
> low level parts use of SExpression is quite appropriate.
I don't intend to remove SExpression. I just want to uncouple the
interdependence of types a bit.
"$Lisp" is all over the place in integer.spad.pamphlet, but Integer
itself doesn't really need Lisp. And the SExpression thing in exquo is
rather artificial. It would, for instance also go away, if INTEXQUO
would already something of the form Union(Integer, "failed"). So we
could have
x exquo y ==
zero? y => "failed"
(NEWINTEXQUO(x,y)$Lisp) pretend %
> In fact, introducing direct Lisp call in the code above would be a
> step backwards.
OK. Maybe I still lack a bit of knowledge in this direction, but as I
see it Integer wouldn't need SExpression. Of course, SExpression might
come back into the dependency if one considers the category of Integer
(I haven't actually checked this), but since Integer is
CoercibleTo(OutputForm), that's probably the circular dependency.
Other question. What do you think about my introduction of
LispExpression. Would that kind of decoupling have a chance to go into
FriCAS or do you rather want to stop me thinking in this direction?
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 http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
