cleanup in src/interp/foam_l.lisp

9 views
Skip to first unread message

Qian Yun

unread,
Feb 16, 2026, 6:07:49 AM (7 days ago) Feb 16
to fricas-devel
At the end of src/interp/foam_l.lisp, section ";; Testing", there's:


===========================
;; Testing

(defun |AXL-spitSInt| (x)
(print x))

;; tacky but means we can run programs

(eval-when (:execute :compile-toplevel :load-toplevel)
(defun H-integer (l e)
(|AXL-LiteralToInteger| l))

(defun H-string (l e)
(|AXL-LiteralToString| l))

(defun H-error (l e)
(|AXL-error| l))
)

(eval-when (:execute :load-toplevel)
(DEFCONST |G-axclique_string_305639517| (cons #'H-String nil))
(DEFCONST |G-axclique_integer_685864888| (cons #'H-integer nil))
(DEFCONST |G-axclique_error_011667951| (cons #'H-error nil))
)
===========================


They are not used and I think they can be removed.

They cause a problem in fricas0 with recent sbcl, when you try to
(load (compile-file "foam_l.lisp")):

debugger invoked on a DEFCONSTANT-UNEQL in thread
#<THREAD tid=11938 "main thread" RUNNING {1200BE8003}>:
The constant |G-axclique_string_305639517| is being redefined (from
(#<FUNCTION H-STRING>) to (#<FUNCTION H-STRING>))
See also:
The ANSI Standard, Macro DEFCONSTANT
The SBCL Manual, Node "Idiosyncrasies"


- Best,
- Qian

Waldek Hebisch

unread,
Feb 16, 2026, 2:26:21 PM (7 days ago) Feb 16
to fricas...@googlegroups.com
'foam_l.lisp' is part of Aldor interface. If you do not run Aldor
it should be possible to just omit this file. There may be references
from other files, but all refrences should be from Aldor interface
and no part of 'foam_l.lisp' should be used if you do not run
Aldor.

Due to above, any testing of changes to 'foam_l.lisp' should
involve Aldor. If you look at history you will see that I mostly
avoided changes to 'foam_l.lisp' and main changes there are by
Ralf Hemmecke. Actually, Peter Broadbery is right person to
ask about changes as he should know what is needed by Aldor.

--
Waldek Hebisch

Qian Yun

unread,
Feb 16, 2026, 7:47:33 PM (7 days ago) Feb 16
to fricas...@googlegroups.com
foam::axiomxl-file-init-name is referenced by daase.lisp.

Shall we tweak that a bit?

- Qian

Waldek Hebisch

unread,
Feb 16, 2026, 8:30:43 PM (7 days ago) Feb 16
to fricas...@googlegroups.com
On Tue, Feb 17, 2026 at 08:47:29AM +0800, Qian Yun wrote:
> foam::axiomxl-file-init-name is referenced by daase.lisp.
>
> Shall we tweak that a bit?

I see, if you want to run without 'foam_l.lisp' you need to change
this part, that is call 'foam::axiomxl-file-init-name' only when package
"FOAM" exists and contains the function.

> On 2/17/26 3:26 AM, Waldek Hebisch wrote:
> >
> > 'foam_l.lisp' is part of Aldor interface. If you do not run Aldor
> > it should be possible to just omit this file. There may be references
> > from other files, but all refrences should be from Aldor interface
> > and no part of 'foam_l.lisp' should be used if you do not run
> > Aldor.

--
Waldek Hebisch

Qian Yun

unread,
Feb 22, 2026, 12:41:33 AM (yesterday) Feb 22
to Peter Broadbery, fricas-devel
Hi Peter, and to fricas-devel:

I've tried: aldor can be built successfully with this chunk of code
removed from aldor/lib/ax0/src/axext_l.lsp;
and fricas-aldor interface can be built successfully as well,
with this code removed from src/interp/foam_l.lisp.

So Waldek, can I do the clean up then?

- Best,
- Qian

On 2/18/26 6:43 AM, Peter Broadbery wrote:
> Hi,
>
> I think they can be removed - but I've not tested the idea.
> Removing them is the kind of change where it'll be clear if it doesn't work.
>
> Peter
>
> On Tue, 17 Feb 2026 at 08:47, Qian Yun <oldk...@gmail.com> wrote:
>>
>> Hi Peter,
>>
>> What's your opinion on G-axclique_string_305639517, etc.
>> Can we remove them safely?
>>
>> - Best,
>> - Qian
>> --
>> 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...@googlegroups.com.
>> To view this discussion visit
>> https://groups.google.com/d/msgid/fricas-devel/aZNvWQJbmgAGTecB%40fricas.org.

Waldek Hebisch

unread,
Feb 22, 2026, 10:05:06 AM (yesterday) Feb 22
to fricas...@googlegroups.com, Peter Broadbery
On Sun, Feb 22, 2026 at 01:41:28PM +0800, Qian Yun wrote:
> Hi Peter, and to fricas-devel:
>
> I've tried: aldor can be built successfully with this chunk of code
> removed from aldor/lib/ax0/src/axext_l.lsp;
> and fricas-aldor interface can be built successfully as well,
> with this code removed from src/interp/foam_l.lisp.
>
> So Waldek, can I do the clean up then?
>
<snip>
> > > > (eval-when (:execute :load-toplevel)
> > > > (DEFCONST |G-axclique_string_305639517| (cons #'H-String nil))
> > > > (DEFCONST |G-axclique_integer_685864888| (cons #'H-integer nil))
> > > > (DEFCONST |G-axclique_error_011667951| (cons #'H-error nil))
> > > > )
<snip>
> > > > debugger invoked on a DEFCONSTANT-UNEQL in thread
> > > > #<THREAD tid=11938 "main thread" RUNNING {1200BE8003}>:
> > > > The constant |G-axclique_string_305639517| is being redefined (from
> > > > (#<FUNCTION H-STRING>) to (#<FUNCTION H-STRING>))

AFAICS G-axclique_string_305639517 and the other two are defined in
Aldor sources, so presumably normally they will be provided by Aldor.
It is not clear if we need our own definitions.

However, the error deserves deeper investigation. Namely, we use
DEFCONST, which is our macro which is supposed to sove problem
with redefinition of constants: if you check you will see that
DEFCONST executes DEFCONSTANT only when symbol is not bound.
In other words, DEFCONST is supposed to define constant only
when it is not already defined.

So how exactly do you trigger the error? Doing

)read foam_l.lisp

twice works for me when using Debian sbcl 2.2.9.

BTW: Plain DEFCONSTANT would fail in old sbcl versions, that is
why we have DEFCONST.

--
Waldek Hebisch

Qian Yun

unread,
Feb 22, 2026, 7:59:45 PM (22 hours ago) Feb 22
to fricas...@googlegroups.com
This error does not happen in fricas, but in fricas0.

I've attached minimal reproducible example. Just try
sbcl --load a

And as pointed out by sbcl manual
https://www.sbcl.org/manual/#Defining-Constants

(defmacro define-constant (name value &optional doc)
`(defconstant ,name (if (boundp ',name) (symbol-value ',name) ,value)
,@(when doc (list doc))))

This version works while ours DEFCONST does not.

However I do not understand why our DEFCONST does not work.

- Best,
- Qian
a.lisp
b.lisp

Waldek Hebisch

unread,
Feb 22, 2026, 9:44:31 PM (20 hours ago) Feb 22
to fricas...@googlegroups.com
On Mon, Feb 23, 2026 at 08:59:40AM +0800, Qian Yun wrote:
> This error does not happen in fricas, but in fricas0.
>
> I've attached minimal reproducible example. Just try
> sbcl --load a
>
> And as pointed out by sbcl manual
> https://www.sbcl.org/manual/#Defining-Constants
>
> (defmacro define-constant (name value &optional doc)
> `(defconstant ,name (if (boundp ',name) (symbol-value ',name) ,value)
> ,@(when doc (list doc))))
>
> This version works while ours DEFCONST does not.
>
> However I do not understand why our DEFCONST does not work.

Looks like problem with order of evaluation. The following seem to
work for FriCAS and with your example:

(defmacro DEFCONST (name value)
`(if (not (boundp (quote ,name)))
(DEFCONSTANT ,name ,value)))

The difference is that in our current version test was done at macro
expansion time, but execution of DEFCONSTANT could happen later.
The version above (and sbcl version too) couples test to execution
of DEFCONSTANT.

--
Waldek Hebisch

Qian Yun

unread,
1:04 AM (17 hours ago) 1:04 AM
to fricas...@googlegroups.com
Aha. Thanks, please commit.

- Qian

Reply all
Reply to author
Forward
0 new messages