From: Stavros M. <mac...@gm...> - 2024-10-20 22:28:03
|
Currently, we have: ev(a[1]+a[2]+a[3], a[2]:3) => a[1]+a[3]+3 and f[2]:3$ ev(sum(f[i],i,1,3)) => f[1]+f[3]+3 and ev(sum(a[i],i,1,3),a[i]:=if i=2 then 3 else 'a(i)) => a[1]+a[3]+3 but ev(sum(a[i],i,1,3),a[2]:3) => a[1]+a[2]+a[3] Since everywhere else in Maxima, only symbols can be locally bound to values, I'd think we should have the same rule here, and exclude subscripted variables (which are mapatoms) as well as non-mapatoms. By the way, struct fields are also mapatoms, and have strange behavior: defstruct(foo(a,b))$ qq: new(foo(4,5)); ev(qq@a, qq@a:100) => 4 ev(qq, qq@a:100) => foo(a = 100, b = 5) which is different from lists: ll:[1,2,3,4]$ ev(ll[2], ll[2]:100) => 100 ev(ll, ll[2]:100) => [1, 100, 3, 4] (global ll remains unchanged) The list behavior is cute, but I'd rather have consistent, simple, and predictable behavior.... -s On Wed, Oct 16, 2024 at 4:09 PM Robert Dodier <rob...@gm...> wrote: > On Tue, Oct 15, 2024 at 11:29 AM Stavros Macrakis <mac...@gm...> > wrote: > > > 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". > > Yeah, generally agreed. This is perhaps what is addressed by the > conventional "principle of least surprise", or, as I like to call it, > the "principle of maximum consistency" -- just what you were saying > about "does not need to be explained, because it has exactly the same > semantics as similar constructs". > > It is perhaps a sign of how much I have absorbed the obtuse and > intricate design flaws of Maxima over the past decades, that I was > saying "this example is easily explained". Easily, if one is > sufficiently enlightened, as they said back in the old days. > > I am intrigued by the possibility of prohibiting non-mapatoms from ev > temporary assignments -- I might try to make an experimental version > and see how that changes calls to makelist in the test suite. > > best > > Robert > |