On Tue, Apr 29, 2025 at 10:12:54AM -0400, Camm Maguire wrote:
> Greetings!
>
> Waldek Hebisch <de...@fricas.org> writes:
>
> > Looking more at the issue, I suspect that gcl is inlining definition
> > of |*0;n;1;frame1;AUX|. I am not sure if Lisp standard allows
> > such inlining (those are discrete definitions via separate evals,
> > not parts of single file). In this case I can (re)define called
> > function first and after that (re)define caller. Such change
> > seem to fix this problem. However, FriCAS in many places
> > assumes that redefinitions on the fly work as expected.
>
> Yes, this is it. GCL collects a lot of information about compiled
> functions and uses it (hopefully effectively) when optimizing the
> caller. For example, 'reverse returns a sequence, and GCL will assume
> this when compiling code that calls 'reverse, but if someone
> subsequently changes 'reverse to return a number, that number will be
> returned to the caller but will likely not be properly handled.
That is very good when done within a single Lisp file. Between
files it is a tradeof: FriCAS also is a developement system
and important part is ability to separately compile modified
files. Assumption that Lisp type will not change is somewhat
limiting for developement.
The case in question deals with user defined functions. Here
user should be free to redefine functions in arbitrary ways,
including arbitrary change to types.
FYI: FriCAS tracks dependencies between functions and variables.
When a function or a variable changes it recompiles all functions
which depend on it. This probably avoids most problems. But
FriCAS encourages recursion and for recursive functions some
callers needs to be compiled before called functions.
> The ideal is if one can arrange to define (and optimally compile) the
> callee before the caller. If the callee is expected to change, this
> definition should be generic enough to encompass all allowed subsequent
> changes.
In case of user defined functions types depend on user. Current
type machinery puts enough load on users, IMO extra restricitons
would be too much.
> Alternatively, one can set the assumed signature info with a
> declaration:
>
> (DEFUN |*0;n;1;frame1| (|envArg|)
> (declare (ftype (function (t) t) |*0;n;1;frame1;AUX|))
> (PROG (XG7)
> (RETURN
> (COND ((LETT XG7 (HGET |*0;n;1;frame1;AL| NIL)) XG7)
> ((QUOTE T) (HPUT |*0;n;1;frame1;AL| NIL (|*0;n;1;frame1;AUX|
> |envArg|)))))))
>
> One could use (function (t) integer) or (function (t) fixnum) as
> appropriate. One can also declaim these declarations at the toplevel.
>
> Other relevant function call declarations include (declare (notinline
> fun)) and (declare (inline fun)). GCL will not inline the fun call
> unless (declaim (inline fun)) was issued somewhere at the toplevel, but
> one can override this setting with local declarations.
>
> Not really relevant yet but on the horizon are other function
> properties, including 'side-effects'. Many functions are known to
> return atomic values given certain inputs, and further have no
> 'side-effects' as in making other changes to the global state. In such
> situations GCL can skip the call altogether. I suppose we will have to
> invent another declaration, as the spec allows, to override this
> determination in the caller if/when this goes online.
>
> One can see the current (default) signature info with (si::signature
> 'fun) or (si::signature #'fun).
>
> With the |*0;n;1;frame1| above the test works as expected. Please let
> me know if this clears the path for fricas or if we need to provide some
> other facility.
I have commited patch changing order of definition, that should
solve the second regression. And you wrote that you solved the
first one, that fixes current troubles.
Concerning longer term (after next gcl release), there are
potential troubles. ATM I do not know how serious they are.
We probably can add 'notinline' declaration for user defined
functions.
--
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 fricas-devel+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/fricas-devel/aBE3NdbnAD83SMwh%40fricas.org.
