[Openmcl-devel] Garbage collector - ccl:terminate (memory stuff)

[Tim Bradshaw]

Another approach to this is to simply reuse symbols that already are interned elsewhere, particularly CL:

(do-symbols (symbol "FRICAS-LISP")
  (export (list symbol) "FRICAS-LISP"))

This is legal, and readable.

Obscure note: you need (export (list s) ...) because otherwise at some point you end up saying (export nil ...).

--tim

> On 27 Apr 2024, at 13:37, Rainer Joswig <joswig at lisp.de> wrote:
> 
> 
> 
>> Am 27.04.2024 um 13:41 schrieb Grégory Vanuxem <g.vanuxem at gmail.com>:
>> 
>> 
>> As a last note, there is a strange "routine" in the FRICAS-LISP
>> package (BOOT, the interpreter and algebra libraries use it) that I do
>> not really understand, wouldn't it be related? I can eventually "play"
>> with this piece of code (some code parts are cutted below):
>> 
>> (make-package "FRICAS-LISP"
>>     :use (list (or (find-package "COMMON-LISP")
>>                    "LISP")))
>> 
>> Here is the piece of code I do not totally understand and if it has
>> effect on CCL symbols that prevents me to define the ccl:terminate or
>> ccl::terminate method on jlref object:
>> 
>> ;;; We use uninterned symbols because at this point we do not
>> ;;; want to add symbols to FRICAS-LISP
>> (let ((#1=#:ls nil))
>>    (do-symbols (#2=#:el "FRICAS-LISP") (setf #1# (cons #2# #1#)))
>>    (mapcar (lambda (#3=#:x) (export (list #3#))) #1#)
>> )
> 
> 
> 
> The form above could be replaced by:
> 
> (mapcar #'export (apropos-list "" "FRICAS-LISP"))
> 
> It simply exports all symbols in the package "FRICAS-LISP" from the current package at that point, avoiding interning new symbols by the code itself.
> 
> 
> If one want to control from where to export, then we can use this:
> 
> (mapcar #'(lambda (#1=#:fricas-lisp-symbol) (export #1# "FRICAS-LISP"))
>               (apropos-list "" "FRICAS-LISP"))
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20240501/40c70d69/attachment.htm>