Stavros has said it pretty well. The difficulty in doing
semantics right is illustrated by the fact that there are examples of
problems in much more recently defined CAS languages, in particular
Mathematica and Maple. Maple actually changed its scope rules recently.
Mathematica now has Block and Module. Module[{x}..] creates a new
symbol like x$123 with (I think) global scope. Pattern matching also
provides another peculiar twist: how does this interact with evaluation?
I recall only one place in macsyma in which a function is actually
required, in the romberg integration program in which one had to
do something like
f(x):=sin(x)
romberg(f,0,1).
Note that the 1st argument had to be a function name like f, not f(x).
Clearly the same kind of thinking could help integrate, sum, etc, but
there is still an issue of whether to "simplify" the body of a function..
f(x):=sin(x)^2+cos(x)^2
romberg(f,0,1)
or
integrate(f,0,1)
or
sum (f, 0, 1)
RJF
Stavros Macrakis wrote:
> Dynamic scope in Maxima is a remnant of the historical context Maxima
> was developed in, and I'm pretty sure that it should be changed at some
> point. But this would change many things.
>
> Consider global behavior flags, e.g.
>
> block([numer:true],%pi)
>
> For this to work, we'd have to have some way of marking *some* variables
> as fluid.
>
> Now consider localy: block([y],y) vs. globaly: y. Is localy=globaly?
> That is, does ev(localy,y=3) return y or 3? If localy does not equal
> globaly, what does it equal? Can you see the difference between the two
> when they are displayed, or does ratsimp(globaly-localy) => y-y ?!
>
> This sort of thing is the consequence of the punning between
> mathematical and programming variables in Maxima, which often comes in
> handy, despite having peculiar semantics.
>
> As you say, if Maxima dealt with true functions rather than expressions,
> much of this would become simpler. But I don't see how you would design
> a workable system on that basis, since traditional mathematical notation
> is heavily based on named variables.
>
> So I think we'd have to analyze the question more closely at some point.
> It is not a minor change to the semantics, and it does require changing
> (as Rich points out) the translate-to-Lisp package as well as the
> debugger, and checking existing code written in the Maxima language
> (e.g. the Share directories, not to mention user code) to see how it is
> affected. It is not something we can treat as a bug fix and rush into
> production.
>
> And frankly, there are lots of other weird things in Maxima
> semantics....
>
> -s
>
> _______________________________________________
> Maxima mailing list
> Maxima@www.math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>