On Fri, Jan 10, 2025 at 01:28:02PM -0500, Camm Maguire wrote:
> Greetings! Just about finished getting fricas to work with the
> forthcoming new GCL release.
>
> This GCL version tries to be strict about enforcing
> call-arguments-limit, which has always been 64. I get the following
> when compiling SULS.spad. Somewhere an apply of '|Join| needs to be
> replaced with reduce. Any suggestions of where to look?
Hmm, I do not see how reduce could help here. 'Join' is used
as a wrapper around 'JoinInner'. 'JoinInner' depends on getting
list of arguments.
> BOOT>>:bt
>
> #0 INVOKE-DEBUGGER {loc0=#<conditions::internal-simple-program-error.0>}
> [ihs=70]
> #1 Join {loc0=#<vector 0000000002ada8c0>,loc1=#<vector
> 0000000004eb1a20>,loc2=#<vector 0...} [ihs=68]
> #2 EVAL {loc0=nil,loc1=nil,loc2=nil,loc3=#<function 00000000173468b0>}
> [ihs=67]
> #3 eval {loc0=(|Join| (|UnivariateLaurentSeriesConstructorCategory| (quote
> |Coef|) (quot...} [ihs=66]
> #4 c_eval {loc0=(|Join| (|UnivariateLaurentSeriesConstructorCategory|
> (quote |Coef|) (quot...} [ihs=65]
> #5 compMakeCategoryObject {loc0=(|Join|
> (|UnivariateLaurentSeriesConstructorCategory| |Coef| (|SparseUniva...}
> [ihs=64]
This is a very specific code path. 'compMakeCategoryObject' is a function
in 'src/interp/define.boot', 'c_eval' is a function in
'src/interp/util.lisp', 'eval' is also in 'src/interp/util.lisp'.
Lisp form passed to 'c_eval' is produced by 'mkEvalableCategoryForm'
in 'src/interp/lisplib.boot'.
There is similar code path where result of 'mkEvalableCategoryForm'
is passed to 'eval'. For FriCAS categories one needs first use
'mkEvalableCategoryForm' before using 'eval', so basically there
are 3 call sites that pass category expression to Lisp 'EVAL',
all going via 'eval'. In principle 'mkEvalableCategoryForm'
could replace
(Join arg1 arg2 ... argn)
with
(JoinInner (LIST arg1 arg2 ... argn))
if that helps.
'Join' is also called from compiled code (in my developement tree
there are 1165 uses of 'Join' in compiled code, but some are not
calls), I am not sure if those places use large number of arguments.
Concernig bigger picture, internal representation of types in FriCAS
(inherited from Axiom) is as an S-expression which after modest
transformation may be passed to Lisp EVAL. In most cases specific
constructs use small fixed number of arguments. Variable argument
constructs are: 'Join' (the case above), 'Record', 'Union',
'Mapping' and 'Enumeration' (there are also 'RecordCategory',
'UnionCategory' and 'EnumerationCategory'). 'Mapping' represents
types of functions and number of arguments is number of arguments of
corresponding function + 1. So any trouble with 'Mapping'
is likely to appear due to a function exceeding argument limit
(an unlikely event). 'Enumeration' currently is essentially
unused, but in principle could have rather large number of
arguments. I think that currently in FriCAS 'Record' and
'Union' are well below the argument limit, but I have seen in
other languages uses with hundreds of recored fields and that
would exceed the limit. So it would be unnatural to have any
smallish limit on number of arguments to 'Record' and 'Union'.
Currently 'Join' probably can occurr only at top level of an
expression: 'Join' produces a category and categories are
allowed as arguments to 'Join' but not as arguments to other
constructs. And FriCAS code aggressively flattens application
of 'Join'.
Nested inside a type expression can be essentially arbitrary
FriCAS expression. Of those list constructors may have largish
number of arguments, but I hope that this is already handled.
--
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/Z4G7Cl-M8pg3F8z9%40fricas.org.
