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
--
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 [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/fricas-devel/6e35ca04-07fd-4c7f-be4b-098ae7f868d2%40hemmecke.org.
