[PATCH] make printing of Kernel/Expression faster as SExpression

[Qian Yun]

If you do something like "sin(x) pretend SExpression",
it will take a long time.

This is useful during debugging.

After this patch, the output is still unreadable, but much faster.

- Qian

diff --git a/src/lisp/primitives.lisp b/src/lisp/primitives.lisp
index 65783b28..379b259d 100644
--- a/src/lisp/primitives.lisp
+++ b/src/lisp/primitives.lisp
@@ -567,11 +567,12 @@
(defstruct (SPAD_KERNEL
(:print-function
(lambda (p s k)
+ (let ((*print-pretty* nil))
(format s "#S~S" (list
'SPAD_KERNEL
:OP (SPAD_KERNEL-OP p)
:ARG (SPAD_KERNEL-ARG p)
- :NEST (SPAD_KERNEL-NEST p))))))
+ :NEST (SPAD_KERNEL-NEST p)))))))
OP ARG NEST (POSIT 0))

(defmacro SET_SPAD_KERNEL_POSIT(s p) `(setf (SPAD_KERNEL-POSIT ,s) ,p))

[Waldek Hebisch]

On Sat, May 16, 2026 at 09:14:15PM +0800, Qian Yun wrote:
> If you do something like "sin(x) pretend SExpression",
> it will take a long time.
>
> This is useful during debugging.
>
> After this patch, the output is still unreadable, but much faster.

I admit that I find Lisp level printouts of some kinds of FriCAS
data useless. Basically, this is when types are part of data
structure (in particular representation of functions typically
contains type). It is not clear to me if speeding up such
useless printouts is worthwile. OTOH without '*print-pretty*'
even otherwise simple printouts are much harder to read.

> - Qian
>
> diff --git a/src/lisp/primitives.lisp b/src/lisp/primitives.lisp
> index 65783b28..379b259d 100644
> --- a/src/lisp/primitives.lisp
> +++ b/src/lisp/primitives.lisp
> @@ -567,11 +567,12 @@
> (defstruct (SPAD_KERNEL
> (:print-function
> (lambda (p s k)
> + (let ((*print-pretty* nil))
> (format s "#S~S" (list
> 'SPAD_KERNEL
> :OP (SPAD_KERNEL-OP p)
> :ARG (SPAD_KERNEL-ARG p)
> - :NEST (SPAD_KERNEL-NEST p))))))
> + :NEST (SPAD_KERNEL-NEST p)))))))
> OP ARG NEST (POSIT 0))
>
> (defmacro SET_SPAD_KERNEL_POSIT(s p) `(setf (SPAD_KERNEL-POSIT ,s) ,p))
>

> --
> 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/cacd1f3e-e5d2-4001-80d4-73667b87d525%40gmail.com.

--
Waldek Hebisch

[Qian Yun]

On 5/16/26 9:29 PM, Waldek Hebisch wrote:
> On Sat, May 16, 2026 at 09:14:15PM +0800, Qian Yun wrote:
>> If you do something like "sin(x) pretend SExpression",
>> it will take a long time.
>>
>> This is useful during debugging.
>>
>> After this patch, the output is still unreadable, but much faster.
>
> I admit that I find Lisp level printouts of some kinds of FriCAS
> data useless. Basically, this is when types are part of data
> structure (in particular representation of functions typically
> contains type). It is not clear to me if speeding up such
> useless printouts is worthwile. OTOH without '*print-pretty*'
> even otherwise simple printouts are much harder to read.
>

Speedup this printout of Kernel is to ease the pain during
debugging EXPR.

We can get much more compact printout, if we only print the
name of "operator" instead of its full property list.

But this will break write!$File. (See src/input/files.input,
write a EXPR into a file and read it back.)
(BTW, is this serialization/de-serialization process
reliable for EXPR?)

How about setting a Lisp variable in File domain,
and if the Kernel's :print-function detects that, print
full version; otherwise print the short version.

- Qian

[Waldek Hebisch]

On Wed, May 20, 2026 at 12:05:29PM +0800, Qian Yun wrote:
> On 5/16/26 9:29 PM, Waldek Hebisch wrote:
> > On Sat, May 16, 2026 at 09:14:15PM +0800, Qian Yun wrote:
> >> If you do something like "sin(x) pretend SExpression",
> >> it will take a long time.
> >>
> >> This is useful during debugging.
> >>
> >> After this patch, the output is still unreadable, but much faster.
> >
> > I admit that I find Lisp level printouts of some kinds of FriCAS
> > data useless. Basically, this is when types are part of data
> > structure (in particular representation of functions typically
> > contains type). It is not clear to me if speeding up such
> > useless printouts is worthwile. OTOH without '*print-pretty*'
> > even otherwise simple printouts are much harder to read.
> >
>
> Speedup this printout of Kernel is to ease the pain during
> debugging EXPR.
>
> We can get much more compact printout, if we only print the
> name of "operator" instead of its full property list.
>
> But this will break write!$File. (See src/input/files.input,
> write a EXPR into a file and read it back.)
> (BTW, is this serialization/de-serialization process
> reliable for EXPR?)

It is hard to exclude possibility of bugs, but a lot of effort
went into making this reliable and currently I am not aware
of bugs there. The whole reason for SPAD_KERNEL is to allow
serialization/deserialization at level of Lisp representation.

To ensure uniqeness of kernels, kernels must have nonzero
position only when they are present in the cache. That is
why they are written out withithout position and on reading
position set to 0. After that Kernel code will notice that
position is 0 and enter the kernel into the cache.

> How about setting a Lisp variable in File domain,
> and if the Kernel's :print-function detects that, print
> full version; otherwise print the short version.

That looks potentially bug-prone. I admit that I would
prefer Spad specific debugging functions. Note that problem
is really not about kernels but about types: Spad types are
rather bulky as Lisp data structures and a lot of Spad data
contains types. AFAICS bulk is cause by '%diff' and
'%eval' properties of 'sin'. Values of both are Spad
funtions and type is part of function representation:
Spad function is represented as a pair, first element of
the pair is Lisp function, the second is data which
typically is domain vector corresponding to the type.
Note that you will get the same problem trying to
print Spad functions or trying to trace Spad functions
using Lisp 'trace'.

--
Waldek Hebisch