Values and objects

Jussi Piitulainen jpiitula at ling.helsinki.fi
Sun May 11 08:22:33 EDT 2014


Rustom Mody writes:
> On Sunday, May 11, 2014 1:56:41 PM UTC+5:30, Jussi Piitulainen wrote:
> > Marko Rauhamaa writes:
> > > Rustom Mody:
> > > 
> > > > On Saturday, May 10, 2014 2:39:31 PM UTC+5:30, Steven D'Aprano wrote:
> > > >> 
> > > >> Personally, I don't imagine that there ever could be a
> > > >> language where variables were first class values *exactly*
> > > >> the same as ints, strings, floats etc.
> > 
> > > > [...]
> > 
> > > > What you mean by *exactly* the same mean, I am not sure...
> > 
> > > Lisp variables (symbols) are on an equal footing with other
> > > objects.  IOW, lisp variables are objects in the heap.
> > 
> > Only some, or only in quite old or special members of the
> > family. But yes, I suppose when Lisp was still LISP, it was the
> > kind of language that Steven fails to imagine in the quotation
> > above. Variables really were symbols, which still are objects that
> > can be passed around and stored in data structures. Or maybe not -
> > wasn't the essential binding component (originally an "association
> > list", later a more abstract "environment", called "namespace" in
> > Python culture) separate from the symbol even then? Global
> > bindings aside.
> 
> A symbol is a first-class data structure in any lisp (that I know)
> http://en.wikipedia.org/wiki/Homoiconicity is a defining characteristic of lisp

I don't see the relevance of these observations.

The claim was that Lisp variables are symbols. What do you write in
Common Lisp in place of the "..." to have the following evaluate to
the the value of the variable x?

    (let ((x (f)) (y 'x)) (... y ...))

No, (eval y) is not an answer, and (symbol-value y) is not an answer:
these do not do the thing at all. To suggest (progn y x) is to concede
my point that there is no way to get the value of x through the symbol
x that is the value of y.

> Environments are first class in many schemes:
> http://sicp.ai.mit.edu/Fall-2004/manuals/scheme-7.5.5/doc/scheme_14.html
> (The '+'es there indicate its an MIT scheme extension; but its quite common)

It's not very common. A couple of top-level environment specifiers are
in the reports (scheme-report-environment, null-environment, and
interaction-environment is optional, if I recall correctly) but the
crucial reifier of an arbitrary lexical environment is not, and
environment specifiers can only be used as an argument to eval.

Even if that were common, it seems to me a joke to say that the symbol
itself is the variable, which is the claim that I responded to. It's
like saying that pairs of integers are first class variables because
they can be interpreted as lexical addresses wrt an environment. You
know, (0, 0) refers to the first variable in the current environment
frame, (3, 1) to the second variable in a specific ancestor frame, and
so on.

> In my understanding a symbol can be called a variable only wrt some
> environment
> 
> IOW there is no meaning to the word 'variable' without some notion
> of scope.

Agreed.

So you consider it reasonable to say that variables are symbols in
Lisp, and then clarify that a symbol means a symbol together with a
first-class lexical environment, as if that was implicit in the
original claim (and as if such environments were widely available in
Lisp)?

If so, I admit I've been fooled, and I've spent far too much time on
this already. At least I was responding in good faith.

> I am not sure what your references to old and new lisps and static
> vs dynamic scope has to do with this.

I'm saying that lexical variables are not accessible through the
symbol that happens to look like the variable in the source code.

And I'm saying that it's the lexical variables that need to be
considered, because they are the default kind even in Lisp today.
Dynamic variables are special. (They are even _called_ special.)

I'm not saying that a dynamic variable cannot be accessed through the
symbol, because that doesn't seem to be true. (I installed a Common
Lisp and experimented a little when I wrote my original response.)

> Or are you saying that in the 1960s lisps, a symbol was the string
> (name) along with its (dynamic binding) stack??

It seems to be the case today, in Common Lisp, that a special variable
is accessible through the symbol. For example, (symbol-value y) would
work in my example above if x had been declared special. The dynamic
environment is implicit.

In the 1960s, before Scheme AFAIUI, things were that way.

> Python to qualify for this not only would the namespacing of locals
> have to be systematic with globals, the nesting structure of
> environments would have to be introspectively available as in the
> scheme example.
> 
> Note the functions: environment-parent and environment-bound-names

If Marko meant MIT Scheme when he said Lisp, and reification of
arbitrary lexical environments when he said symbol, I've responded to
a quite different claim than he intended, and spent far too much
effort on this.



More information about the Python-list mailing list