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

[Waldek Hebisch]

On Thu, Nov 27, 2025 at 08:53:32PM +0100, Grégory Vanuxem wrote:
> 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

Do you realize that reprezentation of Fraction is defined in Localize
and it is:

Rep := Record(num : M, den : R)

So that is pure Spad definition, having nothing to do with Lisp.

Spad Record with two fields is represented by Lisp CONS, but that
in principle is changable. If we change this, there may be trouble
in Boot and Lisp code, but Lisp and Boot should use proper accessor
and creation functions (and not raw CONS, CAR and CDR) so the
problem is limited. Of course, we make compromises. To get better
speed several places in algebra use raw Lisp functions. But
in grand picture this is not too bad, in my build tree I see 1062
uses of 'Lisp', which is 0.5% of total lines, so not too much and
easily identifable.

> 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>

<snip>

> 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):

Well, FriCAS uses generic code so 'FRAC(INT)' may use generic routines
which _assume_ that 'FRAC(INT)' is represented as a Record. Almost
20 years ago there was proposal to use Lisp rationals as a representation
for 'FRAC(INT)'. That gave significant speedup for calculation with
rational numbers. But _that_ would bake in irregular dependency on
Lisp. Most FriCAS calculations are done on integers and speed of
rational numbers have modest impact on typical computations, so
I decided that a little speedup was not worth complication.

Your use of Julia rationals is analogus to this "Lisp rationals for
FRAC(INT)" change, but you introduce dependency on Julia (instead of
Lisp dependency).

<snip>

> 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.

Again, that is general Spad definition.

> 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.

Well, there are no free lunch. Our multivariate polynomial code
uses rather simple idea: a multivariate polynomial is a
univariate polynomial in main variable with coefficients
being multivariate polynomials in remaining variables. That
leads to simple recursive implementation of basic operations.
But to get better speed we compromise in few places. And
some operations like gcd or factoring need complex algorithms
to get reasonable speed.

And some parts want different representation so they reimplement
some basics.

--
Waldek Hebisch

[Grégory Vanuxem]

In fact, I have taken you like a newbie, an arrivist. My fault again, I love that. I will respond later. 

Just for info I have not knowledge, but I know FRAC(INT) as LocalAlgebra

--
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/aTLz-jjvI2JOhk8D%40fricas.org.

[Grégory Vanuxem]

Zut. I vas responded about it's week-end. It's not... 

[Grégory Vanuxem]

No response please.