CL structure in FriCAS - Was [New release]

[Grégory Vanuxem]

HelloRalf, *,

Le mar. 1 juil. 2025 à 10:54, 'Ralf Hemmecke' via FriCAS - computer
algebra system <fricas...@googlegroups.com> a écrit :
>
> Hi Greg,
>
> can you be a bit more precise. What is the problem or what is your wish?
> S(M)UP or POLY cannot be a problem. They work nicely in FriCAS.

My principal concern is that SUP, or FRAC(*) for example, are too
tightly related to Common Lisp (CL) programming structures. I find
this counterproductive in
terms of language evolution.

From my point of view SPAD is somewhat object oriented but the
encapsulation is not respected.

Take rational numbers, FRAC(INT), in a lot of places, at default level, a CL
CONS is expected. From my point of view this is _highly_ unsatisfactory. I know
this is just speculation what I am telling here, but who knows. SUP is
also a domain like this. You have it everywhere. I think it's up to the coder to
implement or not SUP related things. Or choose the domain(s) he wants
to use. I do not
want to criticise its implementation, I am sure it was
discussed a lot and I like how it is done.

BTW SingleAsOrderedSet is for me a shortcut. But, the problem is, again, too
CL related things remain for me. I think I will more elaborate later.

For now I am finishing a reliable Nemo interface (I encounter some
problems sometimes with SBCL).

In fact, to be more precise, see TAOCP, some structures in programming
langages are well defined, Lisp is a List processing language, and
panAxiom as of now relies too a lot of about Lisp.

- Greg

PS: I encountered, first, at university, for my own, a programming
language, LISP :

https://www.amazon.com/Parallel-Distributed-Processing-Vol-Foundations/dp/026268053X

[Ralf Hemmecke]

On 11/25/25 18:58, Grégory Vanuxem wrote:
> HelloRalf, *,

I was a bit lost until I figured out that you refer to
https://groups.google.com/g/fricas-devel/c/MZEoqkRMo0Y/m/Dec-ihJGAgAJ

> My principal concern is that SUP, or FRAC(*) for example, are too
> tightly related to Common Lisp (CL) programming structures.

Oh, maybe, this time you have targeted the wrong person. ;-)
I mostly look at SPAD without ever thinking about its underlying LISP
structure.

Fraction is a quite generic constructor that choses to represent its
element as pairs.

https://github.com/fricas/fricas/blob/master/src/algebra/fraction.spad#L276

Rep := Record(num : S, den : S)

Where do you see a Lisp connection?

> From my point of view SPAD is somewhat object oriented but the
> encapsulation is not respected.

Unless someone convinces me of something else, I would say SPAD *is*
object-oriented with the domains being the objects.
However, I would never dare to program in an object-oriented way in
SPAD. Objects/domains are 'heavy' things. We only tend to create a view
of them. And the compiler tries to ensure that there is only *one*
Fraction(Integer) lying around. Now I better shut up, since I am no
programming language expert.

> Take rational numbers, FRAC(INT), in a lot of places, at default
> level, a CL CONS is expected. From my point of view this is _highly_
> unsatisfactory.

Can you explain, *why* this is unsatisfactory for you?

Ralf

[Grégory Vanuxem]

Hello Ralf, *

Relatively difficult to explain for a non-English speaker...

Le mar. 25 nov. 2025 à 21:39, 'Ralf Hemmecke' via FriCAS - computer

algebra system <fricas...@googlegroups.com> a écrit :
>

> On 11/25/25 18:58, Grégory Vanuxem wrote:
> > HelloRalf, *,
>
> I was a bit lost until I figured out that you refer to
> https://groups.google.com/g/fricas-devel/c/MZEoqkRMo0Y/m/Dec-ihJGAgAJ

Yes, one my first principal concern is that CL structures are too much
used. Take FRAC(INT):

(1) -> 1/2

1
(1) -
2
(2) ->
(2) -> % pretend SExpression

(2) (1 . 2)
(3) -> TYPE_-OF(1/2)$Lisp

(3) CONS

Personally, my "FRAC(INT)" are implemented in C using FLINT (via Julia):

(1) -> QQ(1/2)

1
(1) -
2
(2) -> % pretend SExpression

(2) #<JLREF 3 #x302000A2C9DD>

(3) -> )juliad refs
Dict{Int64, Any} with 2 entries:
6 => 1
3 => 1//2

I need a CL class (<JLREF... >) to GC-it in Julia when it's CL GC-ed in FriCAS.

My principal concern here is that it's tightly related in Spad
and Boot code to CL. So in some place CL cons take place instead of
numerator/denominator stuff. I finally managed to modify the boot code
to take into account NMfraction, but it's an horror to me, I do not
want to modify the FriCAS internals (NM means Nemo [1] here):

(3) -> x:=x::NUP(NINT,'x)

(3) x
Type: NMUnivariatePolynomial(NMInteger,x)
(4) -> x/4

x
(4) -
4
(5) -> )set mess type on
(5) -> x/4

x
(5) -
4
Type: NMFraction(NMUnivariatePolynomial(NMInteger,x))



This is my first principal concern. The second one is that SUP is
almost everywhere in FriCAS (at Category level in fact - ???). I can
understand its use, it's "universal" in the sense that
SingletonAsOrderedSet (the "?", the indeterminate) allows you to create
polynomials without specifying the indeterminate/variable, but again,
its CL structure is heavily used at Spad and Boot level. Moreover I
have some difficulties, my fault, in creating them. All the POLYs
stuff is somewhat a big piece
of code, and for sure well done, but I am not in the head of the
code's writers.

Hope I was more clear,

Greg

[1] https://nemocas.github.io/Nemo.jl/stable/

> > My principal concern is that SUP, or FRAC(*) for example, are too
> > tightly related to Common Lisp (CL) programming structures.
>
> Oh, maybe, this time you have targeted the wrong person. ;-)
> I mostly look at SPAD without ever thinking about its underlying LISP
> structure.
>
> Fraction is a quite generic constructor that choses to represent its
> element as pairs.
>
> https://github.com/fricas/fricas/blob/master/src/algebra/fraction.spad#L276
>
> Rep := Record(num : S, den : S)
>
> Where do you see a Lisp connection?
>
> > From my point of view SPAD is somewhat object oriented but the
> > encapsulation is not respected.
>
> Unless someone convinces me of something else, I would say SPAD *is*
> object-oriented with the domains being the objects.
> However, I would never dare to program in an object-oriented way in
> SPAD. Objects/domains are 'heavy' things. We only tend to create a view
> of them. And the compiler tries to ensure that there is only *one*
> Fraction(Integer) lying around. Now I better shut up, since I am no
> programming language expert.
>
> > Take rational numbers, FRAC(INT), in a lot of places, at default
> > level, a CL CONS is expected. From my point of view this is _highly_
> > unsatisfactory.
>
> Can you explain, *why* this is unsatisfactory for you?
>
> Ralf
>

> --
> 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/6e35ca04-07fd-4c7f-be4b-098ae7f868d2%40hemmecke.org.

[Ralf Hemmecke]

On 11/27/25 20:53, Grégory Vanuxem wrote:
> Relatively difficult to explain for a non-English speaker...

I'm so sorry that I'm German speaking... ;-)

> Yes, one my first principal concern is that CL structures are too
> much used.

I am already lost here.
In principle you could implement SPAD without ever touching any LISP.
Lisp is an implementation detail. Aldor is very much like SPAD, but
there is C underneath.

Take FRAC(INT):
>
> (1) -> 1/2
>
> 1 (1) - 2 (2) -> (2) -> % pretend SExpression
>
> (2) (1 . 2) (3) -> TYPE_-OF(1/2)$Lisp

Implementation detail. I bet in Aldor you wouldn't be able to do this,
since at runtime the fraction is certainly not stored as a lisp object.

That said, yes, in FriCAS, the objects are eventually represented in
Lisp form, since this is the underlying language. If you call this the
"tight connection", then yes, it naturally is.

> I need a CL class (<JLREF... >) to GC-it in Julia when it's CL GC-ed
> in FriCAS.

Sorry, I must quit here. That is beyond my understanding. I have no idea
how you connect FriCAS with Julia. Obviously, you do it on a lisp level,

> Moreover I have some difficulties, my fault, in creating them. All
> the POLYs stuff is somewhat a big piece of code, and for sure well
> done, but I am not in the head of the code's writers.

As far as I remember, you can SPADCALL any function from FriCAS algebra.
Maybe a bit cumbersome, but with that you should be able to construct
polynomials.

Ralf

[Tim Daly]

Scratchpad used concepts from Barbara LIskov's CLU which was

basically object-oriented. This is mentioned in the collected papers

in the volume 10.1

https://www.google.com/search?client=firefox-b-1-d&q=CLU+programming+language

https://en.wikipedia.org/wiki/Axiom_(computer_algebra_system)

(As an amusing aside, the SANE version of Axiom (never released) was pure common lisp.

There was no SPAD or BOOT. It used CLOS for structuring. It was so much easier and

cleaner as CLOS supports a lot of useful features. It also made it possible to construct

a parallel tower for working with theorems and proofs which enabled connecting

LEAN theorems to things like Groups, Rings, etc. in a natural way. If the mood moved

you it was trivial to change the internal representations.)

Tim