Assignment versus binding

[Rustom Mody]

On Tuesday, October 4, 2016 at 12:47:58 PM UTC+5:30, dieter wrote:
> Steve D'Aprano  writes:
> > On Mon, 3 Oct 2016 04:15 pm, Jussi Piitulainen wrote:
> >> Steve D'Aprano writes:
> >>> Why shouldn't people say that binding and assignment are the same
> >>> thing in Python? What's the difference?
> >> 
> >> Outside Python, (lambda x : f(x)) is said to "bind" x. It's different
> >> from assigning a new value to x. It's similar to how quantifiers in
> >> logic are said to bind their variables, so that variables bound to
> >> different quantifiers are different variables.
> >
> > o_O
> >
> > Me: "How is binding different from assignment?"
> >
> > You: "This is an example of binding: lambda x: f(x). Its different from
> > assigning to x. Clear now?"
> >
> >
> > What's "outside python"?
> 
> The concept "assignment" comes from an operational semantics based
> on some form of "RAM" machine. Such a machine has storage cells where
> you can assign values to which remain there until overridden with
> a new value.
> 
> The concept "binding" comes from a denotational semantics based on
> some form of functions where parameter names are bound to values on
> function "application" and do not change inside the function.
> 

«Binding comes from semantics ie logicians/mathematicians
Assignment comes from RAM-machine ie engineers»

seems like an intelligent distinction…
Except for the “do not change inside the function”

Sure in pure functional languages they do not change because nothing changes.
However in scheme there is a strong difference between define/let that change
the ‘structure’ of the scope and set! that changes its contents.

> 
> When you pass a Python variable as parameter to a function,
> and this function modifies the value of the corresponding
> "formal parameter", this does not change the variable's value.
> This indicates, that the variable does not model directly the
> corresponding storage cell.
> 
> On the other hand, you can assign a new value to a Python variable
> which indicates that Python variables are neither simple bindings.
> 
> 
> Of course, these are only semantic subtlenesses.
> 
> There are storage cells associated with Python variables and assignment
> can change their content (only on function call, it is not the storage
> cell that gets passed on into the function but the current value).
> 
> On the other hand, one can model Python variables as bindings
> where language constructs (assignments) allow to change the binding.
> 
> Thus, at an appropriate level of abstraction, you can say that
> "binding" and "assignment" are mostly equivalent.

Thats a bizarre statement -- Are not the contents of the scope and the shape of the scope different things?

No language (that I know) reifies this as completely as theoretically possible.
In particular scheme goes further but shies away from full first class
environments:
http://stackoverflow.com/questions/617325/why-doesnt-scheme-support-first-class-environments

However many scheme implementations provide it in some ad-hoc manner:
[renamed from ‘environment’ to ‘namespace’ presumably due  to clashes with OS
env-variables]
https://docs.racket-lang.org/reference/syntax-model.html#%28part._namespace-model%29


Python goes some way towards this with locals/globals etc... not really first-class.

However at the conceptual level there is a fundamental difference between
the shape of the namespace/environment/scope and its contents.