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 <[email protected]> > > 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 [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/fricas-devel/919b550f-c499-46f4-bd6a-ca2f7f727744%40hemmecke.org. -- Waldek Hebisch -- 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/aWlrGLTcXWtoHBt7%40fricas.org.
