It would be good to move to common representation. But this is much
more than "$Lisp" calls. Actually AFAICS api.spad make relatively
small number of "$Lisp" calls.
I always try to keep lisp calls to a minimum. So if I could shift them
all to your package and can achieve the same functionality, that would
be great.
I must admit that api.spad was born out of my desire to produce the api
webpage. My datastructure are more adhoc for exactly that purpose. If
you now come up with something more general or you put allow discussions
on your ideas, then there will certainly be a datastructure (and
respective accessor functions) be created that makes everyone happy.
Some simplifcations to work at all must be done pretty early.
Basically, once we put unsimplified condition on a signature in a
category if may be impossible to simplify it at later stages.
Sorry, but I don't understand it.
When code from api.spad is executed, there is a compiled FriCAS behind,
so all the information must be somewhere otherwise the comiler/
interpreter would not be able to deal with the condition.
The condition resolution that I implemented (sorry it's long time ago
that I actually looked at it) only deals with the information that comes
from the get_database $ Lisp calls. It must then investigate whether the
parameters of the category/domain/package lead to some simplifications
for the conditions. If such simplifications could be handled by some
low-level function, that would be great. I bet the interpreter/compiler
also must do such simplifications in order to check which function to
call or whether the function is exported at all. So, if this
interpreter/compiler functionality could be made available to the spad-
level, that would also be great an not require to duplicate such code.
But maybe, my knowledge of the internals is too weak to say anything
reasonable here.
I mean, a condition in isolation can not be simplified and
simplification is possible only because the source (category) that
introduced given signature and we can simplify condition on the
involved category. Which means that good simplification either will
be in Spad compiler or must re-do work done by Spad compiler. So
doing work in Spad compiler looks better to me.
Yes, understood and supported. For resolving conditions, a global view
is needed.
But Spad compiler is doing other things and fitting simplifications
here is not so easy. Still, in long term having several pieces of
code doing similar, but not identical things lead to increased
maintenence work, so I want to move simplifications to such places
that they can be used as widely as possible.
OK, looks like we are on the same side.
I hoped the condition-simplification-code is already quite separate from
the rest of the compiler.
In total, nobody wants that HyperDoc is showing other conditions than
fricas.github.io/api and the interpreter/compiler yet behaves in another
way. They should all use the same mechanism, of course.
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 view this discussion visit
https://groups.google.com/d/msgid/fricas-devel/fe97f3bd-eba5-47d4-9ef0-88aecb1b6640%40hemmecke.org.
