dan.stanger@ieee.org wrote:
>
> What kind of problems would static binding cause with local variables
> declared in blocks, and dummy variables in functions?
These two issues are treated the same way.
> How would
> this change the behavior of maxima in general
It would not affect algorithms like factoring, integration etc.
It would affect the meanings of some user-written programs if
they re-use variable names.
It would change user debugging commands (though probably
not used, and perhaps unimplemented in GCL/maxima), since
some variables would be impossible to look at.
> and is this a good idea?
The advantages of lexical binding have been viewed as
outweighing the disadvantages, as evidenced by design of recent
languages in which it was possible to make this distinction.
For people writing in C or Fortran, the distinction may
not be worth making. You might want to make a more drastic
change like adding an environment data object and a way of
providing it to ev, as well as a way of defining variables
and functions
with respect to an environment.
This would be natural for someone who was taught Scheme
as a first programming language, but unnatural to someone
who has been writing in C or Fortran for many years.
> Would a change like this be very difficult?
For the right person, a change in the evaluator (meval and
friends) would be fairly simple. For most other people,
it might be tough.
There would also have to be a corresponding change in
the translation-to-lisp code, for those using the
commands translate() or compile(). I think the same
comment regarding meval holds here.
An alternative would be to provide a DIFFERENT toplevel
with different binding etc. for experimentation.
e.g.
(c1) restart_top_level_with_lex_bindings();
just as we could have
(c1) restart_top_level_with_Mathematica_syntax();
etc.
RJF
> Dan Stanger
> _______________________________________________
> Maxima mailing list
> Maxima@www.math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima