[Maxima-discuss] Semantics of var in makelist etc. WAS ... How do I translate the "ev"...

[Stavros M. <mac...@gm...>]

I don't think "can be explained" is the right design criterion. I would
much rather have "does not need to be explained, because it has exactly the
same semantics as similar constructs".

Non-atoms are not allowed as variables/indexes in most other cases:

All of these (correctly!) give errors:

sum(f(),f(),1,3); => ERROR

block([f()],3); => ERROR
limit(3,f(),5); => ERROR
integrate(4,f(),1,3); => ERROR

create_list(f(),f(),1,3); => ERROR  (surely this should be just like
*makelist*)


*for* and *lambda* give syntax errors at read time:

for f() thru 2 do print(f()) => ERROR
lambda([f()], 3)  => ERROR


*limit, integrate, diff *allow subscripted variables, but not function
calls:

integrate(f[1],f[1],1,3); => 4


There are other incompatibilities between these:

var:'x   =>   x

sum(x,x,1,3)   =>   6
sum(x,var,1,3)   =>   3 x       << var is not evaluated (also in *product,
makelist, create_list*)
integrate(x,x,1,3)   =>   4
integrate(x,var,1,3)   =>   4      << var *is* evaluated (also in *limit,
diff, ...*)

I can't think of a reason for this difference.


How about *ev*?

So, would I also argue that *ev(f(),f()=3)* or
*ev(sin(x)+cos(y),sin(x)+cos(y)=Q)* should give an error rather than
substituting?

No (although that second example is really weird). As Robert said earlier,
*ev* is a collection of convenience functions which are handy at the
command line. If it does the wrong thing, the interactive user will see the
problem immediately.

I am not completely happy that *ev* muddies the difference between
evaluation and substitution, but....

            -s

On Tue, Oct 15, 2024 at 1:32 AM Robert Dodier <rob...@gm...>
wrote:

> On Mon, Oct 14, 2024 at 12:00 PM Stavros Macrakis <mac...@gm...>
> wrote:
>
> > Internally makelist calls ev, but I've got to say that that shocks me
> even more than the fact that ev has bizarre behavior itself. In particular,
> I find this ridiculous:
> >
> > makelist(['(x), '('x),'('('x))],'x,17,17) => [[17, '17, '('17)]]
> >
> > Re using 'x as a variable in ev and makelist, I doubt that the
> implementers considered that case. It should probably raise an error.
>
> Ah, but this example is easily explained. 'x is a nonatomic expression
> ((MQUOTE) $X) so ev is going to substitute (not assign) ?meval(17) for
> ?meval('x) in ['(x), '('x),'('('x))] and then evaluate that, peeling
> off one quote from each of the three list elements. (I'm pretty
> impressed that it comes out with the right number of quotes on each
> element, frankly.)
>
> I disagree that 'x should cause an error, unless all nonatomic doodads
> cause an error, and I'm inclined to think they shouldn't.
>
> The barely-coherent intricacies of ev spill over into makelist ... Oh
> well!!
>
> Robert
>