[Prev][Next][Index][Thread]

Re: Closures

Jeff Dalton wrote:

> Thanks, Samuele!  Very interesting.  Unfortunately, I don't quite
> understand it.
>
> Samuele Pedroni <pedroni@inf.ethz.ch> wrote:
>
> > Here the rationale for Python, mostly a GvR (aka Python BDFL) point:
> >
> > >     There are technical issues that make it difficult to support
> > >     rebinding of names in enclosing scopes, but the primary reason
> > >     that it is not allowed in the current proposal is that Guido is
> > >     opposed to it.  His motivation: it is difficult to support,
> > >     because it would require a new mechanism that would allow the
> > >     programmer to specify that an assignment in a block is supposed to
> > >     rebind the name in an enclosing block; presumably a keyword or
> > >     special syntax (x := 3) would make this possible.
>
> Why is it *rebinding* in enclosing scopes and why would a special
> syntax be needed?  (I don't remember very much about Python, I'm
> afraid.)

Because Python is quite heretic in the way you introduce locals:

def f(x): # x is an arg => local
   print y # y is global or free: no assigment/binding to it
   z = 2   # z is local: occur in binding/assignment statement
   print z  # print our local z

if we put def f(...) in:
  def g():
     z = 3
     def f(x):
       ....
then should z = 2 in f introduce a new local variable or rebind the z in in g?
In both cases you will need a syntax to express the other possibility
...
Now binding/assigment statement introduce  new local variables, like before
and you can't assign to variable in outer scopes up to global scope
(it exists a global decl statement).

>
>
> > PS: GvR is known to have said something along the line of: the mind of the
> > average Python programmer is simpler than that of average Lisp programmer.
> > I think both groups get an appropriate set of tools.
>
> Ok, but the Python approach seems more complex to me, rather than simpler.

It's simpler wrt  Python previous status quo, but I think I'm not the right
person
to assess this, I'm fine with both set of rules in their respective context.

Returning to your question:

> The interesting question is why:  why have Dylan and modern Lisps
> gone this way when virtually no one else has?  Why were Lisp and Dylan
> not satisfied with some kind of "approximate closure" when so many
> others were?  Java came close but didn't take the final step of supporting
> assignment.
>
About Java I think it's a matter of performance over their somehow already
defined execution model (the JVM), I think on the tradition of C and C++ Java
is
a bit scared about not explicit performance costs (Lisp absolutely not [1])

Perl has all what you want but it has only anonymous closures because sub def
are not
lexical (but I think this is going probably to change) so the syntax to use
them is a bit
cluttered.

Maybe I could be wrong but if I rembember well the most modern form of closures

came to Lisp (and Dylan) from Scheme dialect: at least one of the author (Guy
L. Steele)
explicitly states that inspiration came from Algol and from the fact that they
were
trying to implement an object-oriented model (actors) in a functional language
[1].
It seems natural that then you need shared bindings.
>From this point of view it's also more clear that the space of possibilities
(what is needed vs. nice, what is not )is a bit larger when you already have
both objects
and first-class functions.

regards.

[1] G. L. Steele, Jr. and R. P. Gabriel. The evolution of Lisp. In The 2nd ACM
SIGPLAN History of Programming Languages
 Conference (HOPL-II), pages 231--270, 1993.