Due to your DEFVAR you implicitely used the FOO2 mechanism where I think you expected FOO1 behaviour.
Look at the entry for LET in the CLHS where it says that "each binding is lexical unless there is a special declaration to the contrary". So Erik Naggum was of course right when he said that lexical bindings do not affect the SYMBOL-VALUE. However, your example wasn't about lexical bindings.
Alan S. Crowe wrote: > Well my old value of x is still there, so a symbol must have > multiple "symbol values", even when it is special. This > needs more investigation.
This sounds to me like an issue with understanding scope and extent[1]. I found this hard to understand and found that the biggest help was reading chapter 3 of CLTL2[1] several times. (I also realise that I am in danger of repeating myself...)
That's not a lexical binding, it's a special binding. Once you've done a DEFVAR on something it's special for ever - you can never make it lexical again.
>What would be the robust way of processing this code so that only the >function name list is changed to newlist? Some of the difficulty in >parsing this code arises out of the separate namespaces.
I didn't understand your motivation for this example, but converting the example itself seems a lost cause. Your only way out is to follow the Paul Graham tack of scrupulously abstaining from the ability to use the same symbol as both operator name and non-operator variable. Once you do that, of course, you aren't really exploiting the vaunted freedom of a Lisp2 anymore. You are writing as a Lisp1er (eg, Schemer) would, except that, unlike them, you are still saddled with the funcall/#' machinery even though it isn't buying you anything in an informational sense.
* Erik Naggum | Lexical bindings do not affect the symbol-value of a the symbol used.
* Alan S. Crowe | Well my old value of x is still there, so a symbol must have multiple | "symbol values", even when it is special. This needs more investigation.
It is not a lexical binding when it is special. /THINK/!
-- Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.
> What (defvar <x> ..) does, among other things, is to proclaim <x> to > be a special variable. One consequence of this is that it will be > _impossible_ to create a lexical binding for <x>.
And which is also (one of the reasons) why it is (usually) a good idea to have asterisks around the names of special variables. (Whether global or not.)
* Dorai Sitaram wrote: > I didn't understand your motivation for this example, > but converting the example itself seems a lost cause.
This is obviously false. Anything which understands the code - such as a correct code walker - can do this kind of replacement. One canonical example of such a program is an interpreter or compiler, and several Lisp environments have compilers which maintain databases of where functions (and less commonly, but obviously possibly) variables are used and provided user access to them. I think at least one InterLisp system, for instance, allowed you to specify replacements on programs, relying on this kind of information (and possibly also allowing pattern-based substitutions too).
In general, I can't see the reason for changing lexically bound variable names, since (in a Lisp2) they never really matter - the exceptions being when you want to unify or split two variables. Those exceptions can't really be done mechanically since they obviously change the program semantics. Dynamic variables are clearly more interesting to track (and not surprisingly the various compiler/database systems do tend to track bindings of & references too specials).
* Joe Marshall wrote: > Avoiding name collisions when inlining.
Oh, yes that's a very good reason. What I meant was as an editorial change to source code, not as something done during compilation/evaluation - sorry not to be clearer...
* Dorai Sitaram | I didn't understand your motivation for this example, | but converting the example itself seems a lost cause.
If so, it would also be impossible to execute. Is it?
| Your only way out is to follow the Paul Graham tack of scrupulously | abstaining from the ability to use the same symbol as both operator name | and non-operator variable.
I think you should say "my only way out" when that is what you mean.
| You are writing as a Lisp1er (eg, Schemer) would, except that, unlike | them, you are still saddled with the funcall/#' machinery even though it | isn't buying you anything in an informational sense.
I think products and vendors should be judged by the intelligence of their marketing. So Scheme must be the choice of the pretty dumb.
-- Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.