Re: [Maxima-discuss] index properties and define/funmake

[Richard F. <fa...@gm...>]

I would say the argument is not one of popularity, but of perspective.
There are a number of systems for symbolic math with different
user interfaces, including graphic-style commands,  maybe even verbal stuff.
Those that have programming-language style features are mostly quite
similar in those respects: Macsyma, Maple, Matlab, Reduce, Axiom,
Mathematica,
... and they typically inherit some aspects of the much older (1959) Lisp
language, as well as FORTRAN, Algol 60 and its descendants.

There is an argument that goes something like this:

  Astrologers have certain notations. So we should add stuff like ♑ to
the language, instead of (say) expecting people to write Capricorn.
True?  I tried to work with one mathematician who refused to use a system
that did not have Greek letters ON THE KEYBOARD.  He was not very
productive, though he did have an incredible typewriter setup.

Or why don't we allow spoken "eks squared" instead of x^2 ? I built such
a system; never really caught on, but that was 20 years before ChatGPT.

The (historical, logical) argument is that augmenting the typical CAS
(computer algebra system) notation adopted
mostly from algebra  by adding constructions from scientific programming
languages seems to have provided a reasonable framework, syntactically
and semantically for adding features.  This is mixed up with symbolic
notations,
(e.g. an infix-version of Lisp like rlisp in Reduce ).  [FORTRAN  allows
f(x) only if
f is defined as a subroutine.  Maxima just shrugs an "quotes" it.]

The particular issue here is whether objects that are apparently not symbols
should be allowed to be bound -- as formal parameters.
Well, we could allow them as block variables as well.  say block([x^2:9]
... )
does that bind x to {-3,3} ?? It seems unambiguous to me. Or maybe another
notation allowing equations rather than bindings would be better...
 with({x^2=9}, print(x^4)) ...
And sometimes I use different marker colors when I lecture with a
white-board.
Should Maxima allow purple input?  underlining? Circling of subexpressions?
(uh, we actually did this, at least on lisp machines...)

Where does this end up?
1. People are, of course, free to add features. Even publish ideas and get
 advanced degrees.  Breaking existing systems or making them complicated
and/or inefficient is not a winner..

2. People who request features should think .. have I learned about the
existing features?  Have others with similar research interests who have
used
CAS managed this situation?  Can I, with just a little effort... maybe
programming, maybe typing more,
 simulate what I think I need with the existing features?  Humans are
pretty flexible
this way.

3.  If your goal is to typeset mathematical-ish stuff and Maxima doesn't do
it just right,
consider using one of the dozen or so existing math typesetting systems.
Maxima
is mostly oriented to legible interactive math, which may not be
journal-ready.
Maybe coordinate with Maxima, but not necessarily.

too much..  happy new year, all.

RJF



On Thu, Jan 8, 2026 at 3:56 PM Robert Dodier <rob...@gm...>
wrote:

> On Thu, Jan 8, 2026 at 3:18 PM Stavros Macrakis <mac...@gm...>
> wrote:
>
> > As Fateman points out, no common programming languages support
> subscripted formal variables, for all the good reasons you give.
>
> That's a pretty weak argument, isn't it? There's already all kinds of
> stuff in Maxima that doesn't exist in other languages; that's kind of
> the point of having different languages.
>
> There may be other reasons against non-symbols as arguments, but
> simple popularity or lack of it isn't one of them.
>
> > If it's just the name that is wanted, users can use other conventions if
> their variables have conventional names, e.g., phi_x, phi_y, phi_z.
>
> Maxima already allows nonatomic expressions to be used as variables in
> various contexts, which makes it an unpleasant surprise that it
> doesn't extend to formal arguments.
>
> Robert
>
>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>