Complaint about abbreviated function name

[Ralf Hemmecke]

Hi Waldek,

Well, FriCAS is your baby, so you can do whatever you like, but if you
had proposed that patch before committing, I would have complained about
the name.

What is the sense of basically using a name from the underlying lisp
level at the spad level rather than inventing a good name that says what
the function does. One cannot (and should not) expect SPAD developers to
know Lisp at all.

I would have liked that we at least keep the convention that the spad
functions have no abbreviations, but are rather full names.

You also seem to more and more deviate from camelCase convention of the
original AXXIOM developers, i.e. the fricas code feels more and more
like following two conventions (camelCase and underscore-separated) at
the same time. :-(

Maybe it is only my opinion. But I don't like it.
Just my 2 cents.

Ralf

On 1/15/26 14:54, hebisch wrote:
> Branch: refs/heads/master
> Home: https://github.com/fricas/fricas
> Commit: 174ddd63ac8e53d5867080f95b082eaf20875889
> https://github.com/fricas/fricas/commit/174ddd63ac8e53d5867080f95b082eaf20875889
> Author: Waldek Hebisch <c...@fricas.org>
> Date: 2026-01-15 (Thu, 15 Jan 2026)
>
> Changed paths:
> M ChangeLog
> M src/algebra/hypertex.spad
> M src/interp/Makefile.in
> A src/interp/br_sup.boot
>
> Log Message:
> -----------
> Add a missing function

[Waldek Hebisch]

On Thu, Jan 15, 2026 at 03:31:36PM +0100, 'Ralf Hemmecke' via FriCAS - computer algebra system wrote:
> Hi Waldek,
>
> Well, FriCAS is your baby, so you can do whatever you like, but if you had
> proposed that patch before committing, I would have complained about the
> name.
>
> What is the sense of basically using a name from the underlying lisp level
> at the spad level rather than inventing a good name that says what the
> function does. One cannot (and should not) expect SPAD developers to know
> Lisp at all.

You do not say which name you find problematic. Do you mean
'sublis_formal'? If yes, then my reasons are as follows:
- BRINFO must cooperate with Boot code and call what is
needed form Boot
- to avoid having to many '$Lisp' calls I create Spad wrappers.
Also, calls via wrappers mean that there is type checking
for arguments and returns values.
- 'sublis_formal' is low level function that in ideal world would
be not exported. But it is needed in few places outside BRINFO,
so I exported it.
- finding good names is not so easy, in this case I needed the
function so went with IMO reasonable choice, that is essentially
re-use name of Boot function.

Let me add that this is part of bigger work on Hyperdoc code.
I consider most of it as not ready inclusion in FriCAS.
Bit BRINFO part IMO already is useful. Unfortunatly, since
other code is not included I did not notice that one piece was
missing. I noticed that part is missing when I modified my
working version. I probably should have been more careful,
as I forget about package declaration, but the point was to
reasonably quickly fix the problem, so I commited also
related change to BRINFO (which included 'sublis_formal').

I am not commited to this name. In my working code new function
names appear regularly, many are changed or removed. As long
a code is changing I do not think too long about names, that
would slow down me too much. That is part of reason that I
normally do not commit working intermediate versions of code.
Only when I get to some milestone I work on cleaning up code
which may include choosing better names. But this time I
wanted to quickly fix the problem.

> I would have liked that we at least keep the convention that the spad
> functions have no abbreviations, but are rather full names.
>
> You also seem to more and more deviate from camelCase convention of the
> original AXXIOM developers, i.e. the fricas code feels more and more like
> following two conventions (camelCase and underscore-separated) at the same
> time. :-(

I really find underscore-separated version superior, for me it is
definitely easier to work than camelCase. We could for consitency
change camelCase to underscore-separated, but probably you would
like this even less.

> Maybe it is only my opinion. But I don't like it.
> Just my 2 cents.
>
> Ralf
>
> On 1/15/26 14:54, hebisch wrote:
> > Branch: refs/heads/master
> > Home: https://github.com/fricas/fricas
> > Commit: 174ddd63ac8e53d5867080f95b082eaf20875889
> > https://github.com/fricas/fricas/commit/174ddd63ac8e53d5867080f95b082eaf20875889
> > Author: Waldek Hebisch <c...@fricas.org>
> > Date: 2026-01-15 (Thu, 15 Jan 2026)
> >
> > Changed paths:
> > M ChangeLog
> > M src/algebra/hypertex.spad
> > M src/interp/Makefile.in
> > A src/interp/br_sup.boot
> >
> > Log Message:
> > -----------
> > Add a missing function
>

> --
> 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/919b550f-c499-46f4-bd6a-ca2f7f727744%40hemmecke.org.

--
Waldek Hebisch