Are compiled maxima functions lexically scoped????

Hi,

I am going to go quiet on this issue for a while since I think the limit 
has been reached of
what can be achieved by looking at small toy examples. I will need to 
produce some proof
of concept code. But as said I currently have other things to do.

To Robert:
========

Well the difference is that f(s,t):=s[t] throws an error on f(t,1) (when 
t is unbound) in interpreted code whereas it does not in translated code 
(it returns (in my point of view correctly) t_1). However changing the 
definition to

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

(which Richard will consider as supremely evil:-) gives an error both in 
interpreted and translated code. This is because now the translated code 
calls meval (mevil?) in the wrong scope. When sanitized this new 
definition would still
behave as expected (i.e. returning t_1 for f(t,1)). I am going to look 
at more translated code to possibly get some useful ideas.

To Richard:
========

Thanks for explaining clearly that

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

is from a lisp-2 philosophy an incorrect program, so its  interpreted 
and compiled version  are allowed to behave
differently. I do not agree (if it is illegal then maxima should always 
give an error). Nevertheless it is good to know this.

I like your proposal for program variables (which live in a different 
name space)
and replacing evaluation by explicit substitution and explicit 
simplification (so that its effect is deterministic).
I think this can currently perhaps be achieved in lisp (by avoiding to 
call meval and friends as much as possible), but not in the maxima 
language. It seems to me it would require a complete redesign of the 
maxima language which would not be backwards incompatible.

Nevertheless when going down that road I think one should make
the maxima language an object oriented language where expressions are 
simply instances of an appropriate class. This
would allow one for example to unify all the different number systems 
which are now
treated more or less distinctly in maxima. One should also create a 
proper package system so that not
every extension dumps all its garbage in the global scope.

Ideally one should not have to create a new language but simply create 
bindings to an existing object
oriented language (I would vote for python, but java makes probably more 
sense). The issue on how
to interface with legacy code is a major one however.


Michel