On Tue, Jan 06, 2026 at 03:54:21PM +0100, 'Ralf Hemmecke' via FriCAS - computer
algebra system wrote:
> > 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.
Concerning datastructures, if you (or somebody else) thinks that
we need different datastructures or some impovement, then I am
happy to discuss this.
I came to current datastructures in BrowserInformation due to
following considerations. First, at low level for efficiency
we use symbols instead of strings, so to keep things consistent
and avoid converting back and forth I used symbols too (unless
there were other reason to prefer strings). I kept signatures
mostly as in existing Boot code, that is as a list with retrurn
type first and arguments after that. Also for conditions I kept
representation from lower level. For display we want info
about origin and documentation string, so we essentially get
Sig_doc record. One could discuss if this record should contain
also function name. That is almost arbitrary decision, in some
places it is convenient to group functions "by name", that is
for each name have list of possibilities. In other places we
want to process name together with other data. Hyperdoc allows
grouping in other ways, for this I introduced Grp_rec.
For constructors we do not have overloading, so constructor is
uniquely identified by its name. So we can represent list of
constructors by list of symbols. Since at various places
we shows separately info abound different kinds, I introduced
Split_rec. Gen_rec is to represent result of general search
(both constructors and operations). Searches use patterns
and some patterns are not valid, so we need some indication
about possible errors. Current Boot code puts an error
message in case of error in pattern, so I kept Boot representation
(but having type as a macro partially abstracts this).
In some places we need constructors with conditions. Conditions
may refer to constructor parameters, so for this I use "constructor
form", that is list with constructor name as first element,
followed by arguments.
Hyperdoc in many places shows exposure information. But exposure
is really info about constructor names and can be recomputed
at reasonable cost. So I do not put exposure information in
data structures, instead 'exposed_constructor?' allows
retriving it when needed.
> > 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.
Well, compiler dully makes OR-s or AND-s of conditions and in
principle can work with unsimplified conditions (but it may
reject valid program when it can not recognize true condition).
At runtime we have parameters which we can evaluate, so we can
also evaluate conditions. But fact that for specific arguments
condition evaluates to true does not tell you that it will
always evaluate to true. So this is different than simplification.
> 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.
Unfortunately, this is somewhat intertwined with other parts. If you
look how source travels trough the compiler, first place that is doing
some simplification is handling of Join. It uses a trick to effectively
pass Join to runtime support routines. But we do not want to evaluate
all types during compilation, so this trick replaces actual types in
arguments of categories by symbols. Which means that some important
information is not available during processing of Join.
There is second place which simplifies conditions, this is done at
end of compilation of domains and package. Again, we do not want
to evaluate types there.
Currently some simplifications are done for HyperDoc processing,
as part of generation of libdb (but I would like to remove this
part) and when retrieving information from databases.
> 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.
Exactly.
--
Waldek Hebisch
--
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/aV02PFnzm4F-PJ8w%40fricas.org.
