Securing a future for anonymous functions in Python

[Bengt Richter]

On Mon, 10 Jan 2005 21:15:50 -0500, Tim Peters <tim.peters at gmail.com> wrote:

>...
>
>[Anna]
>>> BTW - I am *quite* happy with the proposal for "where:" syntax - I
>>> think it handles the problems I have with lambda quite handily.
>
>[Steve Holden]
>> Whereas I find it to be an excrescence, proving (I suppose) that one
>> man's meat is another person's poison, or something.
>
>I've been waiting for someone to mention this, but looks like nobody
>will, so I'm elected.  Modern functional languages generally have two
>forms of local-name definition, following common mathematical
>conventions.  "where" was discussed here.  The other is "let/in", and
Well, I did say it reminded me of some kind of weird let ;-)
http://groups-beta.google.com/groups?q=%20Reminds%20me%20of%20some%20kind%20of%20weird%20let&hl=en&lr=&sa=N&tab=wg

>seems a more natural fit to Python's spelling of block structure:
>
>    let:
>        suite
>    in:
>        suite
>
>There's no restriction to expressions here.  I suppose that, like the
>body of a class, the `let` suite is executed starting with a
>conceptually empty local namespace, and whatever the suite binds to a
>local name becomes a temporary binding in the `in` suite (like
>whatever a class body binds to local names becomes the initial value
>of the class __dict__).  So, e.g.,
>
>    i = i1 = 3
>    let:
>        i1 = i+1
>        from math import sqrt
>    in:
>        print i1, sqrt(i1)
>    print i1,
>    print sqrt(i1)
>
>would print
>
>    4 2
>    3
>
>and then blow up with a NameError.
>
>LIke it or not, it doesn't seem as strained as trying to pile more
>gimmicks on Python expressions.
I could get to like it ;-)

Hm, a little extension to this could provide a new way to populate closure variables,
and also (never mind, one thing at a time ;-)

#1: If you gave your 'let' above a list of 'externs' that can be rebound from within the let.
E.g.,

    let(sqrt):

the effect in your example would be to eliminate the NameError you mention.
The compiler would make an entry for sqrt in the enclosing namespace, and generate
code to bind/rebind if assigned from within the let.

This would be an interesting way to create closure bindings:

    let(foo):
        preset = 'another way to make closure vairables'
    in:
        def foo(): return preset
    ...
    print foo()

#2: Making the in: suite callable as a light weight function with no arguments. An optional
binding name after in would bind like def and create a persistent named callable instead of just an
implicitly called anonymous suite.

Then you could define the same effective foo by

    let:
        preset = 'another way to make closure vairables'
    in foo:
        return preset  # return now legal 
    ...
    print foo()

The combination would work like:

    let(rebindable):
        factor = 10
    in bar:
        rebindable *= factor

    rebindable = 2
    bar()
    print rebindable  # => 20
    rebindable += 5
    bar()
    print rebindable  # => 250

You can see this could be used nicely in case functionality, with a dict of named in-functions.

What do you think?

Regards,
Bengt Richter