Are compiled maxima functions lexically scoped????

I think that compiled and interpreted maxima programs should work correctly
on correct input. Otherwise it is a bug in one or the other.  On incorrect
input they may behave differently, and that would not, in my opinion, be a
bug in the compiler.

The example being used repeatedly as a benchmark for the behavior of maxima,
namely

  f(s,t):=s[t]

is itself an erroneous program, in my view. Maxima operates generally as a
"Lisp-2" and you want to make it into a "Lisp-1". For the distinction, see
http://www.dreamsongs.com/Separation.html

When s is a function in maxima, it has a bunch of properties possibly
including a simplification operator, an arithmetic operator, a compiler
operator, a number of arguments, notions like "linear", "additive", a
derivative property and taylor series definitions, etc.

s can simultaneously have a value.

Rebinding of the name s, as in foo(s):= .... access to s ... [at least by
analogy with common lisp and the lisp-2 model], means that foo(43) masks
only the global value of s with the value of 43 during its access within
foo.

You are entitled to use the value of s, namely 43, inside foo. If you call s
within foo, by   s(1234),  what does this mean? Does it mean you are calling
43(1234), presumably an error?  NO. The FUNCTION s has not been rebound, and
so the global function s should be called, not the value of s.

Now you CAN pass a function in to foo, say cos, and apply that function...
you can do so this way:

Foo(s):= apply(s,[1234]).

Foo(cos);

Compare that to a definition foo(cos):=cos(0),  in the Lisp-2 model, foo(43)
gets cos(0) or 1.  This is what maxima does.

There is a further nuance, in that items with no current function definition
become expressions like s(1234), and then it is possible to move these
expressions around into arbitrary environments in which there may be local
functions, or repeated evaluations, eg.  S is bound to r is bound to cos...
while this confuses the situation, I think that your premise that an
erroneous program should be the basis for revising the underlying
programming language should be re-examined.

Another possible way out of this morass is to look at programming variables,
say p,q,r,s that are traditional in some sense, like those you see in
fortran and pascal, as a separate set of objects from indeterminates.  These
latter objects might be names like x, y, z.  It is forbidden to assign them
values. That is x:3 is an error.  If you want to know what x^2 when x=3,
then do something like subst(x=3,x^2). 

The programming variables can only be bound to expressions.  You cannot (for
example), compute a derivative with respect to a programming variable p.
You could, of course, set p:x,  and compute diff(sin(x),p) ... which would
be cos(x).

The name cos  is like an indeterminate in this sense. You cannot assign to
it or bind it. That is foo(cos):= ... IS AN ERROR.

In foo(s):=s(0), IT IS AN ERROR to use a programming variable as a function.

This model is not entirely consistent with Maxima right now.

RJF






> -----Original Message-----
> From: maxima-bounces at math.utexas.edu [mailto:maxima-
> bounces at math.utexas.edu] On Behalf Of Michel Van den Bergh
> Sent: Thursday, January 11, 2007 12:30 PM
> To: maxima at math.utexas.edu
> Subject: Are compiled maxima functions lexically scoped????
> 
> Sigh....
> 
> I thought interpreted and compiled maxima functions were supposed
> to behave identically but now I see they do not even on very simple
> examples.
> 
> My very rudimentary testing shows that my favorite examples
> 
> f(s,t):=s[t]
> 
> and
> 
> f(s):=s[1]
> 
> seem to behave as expected when compiled whereas they behave strangely
> when interpreted (see
> http://maxima.sourceforge.net/wiki/index.php/LexicalLayer).
> 
> Michel
> 
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima