Differences between revisions 6 and 7
Revision 6 as of 2005-03-12 08:50:48
Size: 5280
Editor: h00095bd2b849
Comment:
Revision 7 as of 2005-03-12 14:01:13
Size: 7712
Editor: NickCoghlan
Comment: Add a goals section to provide more context
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
As it stands, Guido van Rossum has suggested that lambda forms will disappear in ["Python3.0"]. This started a number of threads on comp.lang.python suggesting alternate syntaxes for lambda in the hopes that one of them might be more amenable to GvR's tastes. This pages summarizes these suggestions: As it stands, Guido van Rossum has suggested that lambda forms will disappear in ["Python3.0"]. This started a number of threads on comp.lang.python suggesting alternate syntaxes for lambda in the hopes that one of them might be more amenable to GvR's tastes. This pages summarizes these suggestions.

The main hope of this page is to find a way to retain the functionality of existing Python lambdas - a way to create simple deferred expressions within another expression. For many uses (e.g. lazy argument evaluation, or simple callbacks) separating the deferred expression out into a named function can actually reduce clarity, as it overemphasises the deferred expression at the expense of the expression that the deferred expression is only one part of.

== Goals for Alternate Form ==

=== Definitely Desirable Features ===
 * Acceptable to BDFL
   If Guido doesn't like it, it ain't gonna happen!

 * At least as capable as current lambda expressions
   If a new syntax is to replace the status quo, it needs to be at least equivalent in expressiveness

 * More Pythonic / Less ugly
   The current lambda syntax simply doesn't blend well with the rest of Python's syntax. A syntax which mixes in with other expressions as cleanly as list comprehensions and generator expressions do should have a much better chance of gaining BDFL approval.

 * More friendly to inexperienced users
   Compared to other Python keywords, 'lambda' is rather esoteric. In the challenge for "farthest outside day-to-day English usage", its closest competitor would probably be 'assert', as even 'def' and 'elif' are just abbreviations for 'define' and 'else if'. Use of simpler keywords may make deferred expressions appear less intimidating than they seem with the current unusual keyword.

 * Less external baggage
   One of the problems with lambda is that developers familiar with lambda calculus expect more of it than it provides. They expect full anonymous functions, whereas Python's lambda expressions allow deferred evaluation of only a single expression. An alternate syntax described as providing deferred evaluation of expressions rather than anonymous functions may be less prone to trigger complaints about the single expression limitation (consider: how often are complaints heard regarding the restriction of the expression section of list comprehensions or generator expressions to single expressions?).

=== Arguably Desirable Features ===
 * Support anonymous suites
   No discussion of lambda is complete without it being suggested that it should be possible to embed entire suites inside expressions. Accordingly, some suggestions along these lines are included below under the heading Real Closures.

As it stands, Guido van Rossum has suggested that lambda forms will disappear in ["Python3.0"]. This started a number of threads on comp.lang.python suggesting alternate syntaxes for lambda in the hopes that one of them might be more amenable to GvR's tastes. This pages summarizes these suggestions.

The main hope of this page is to find a way to retain the functionality of existing Python lambdas - a way to create simple deferred expressions within another expression. For many uses (e.g. lazy argument evaluation, or simple callbacks) separating the deferred expression out into a named function can actually reduce clarity, as it overemphasises the deferred expression at the expense of the expression that the deferred expression is only one part of.

Goals for Alternate Form

Definitely Desirable Features

  • Acceptable to BDFL
    • If Guido doesn't like it, it ain't gonna happen!
  • At least as capable as current lambda expressions
    • If a new syntax is to replace the status quo, it needs to be at least equivalent in expressiveness
  • More Pythonic / Less ugly
    • The current lambda syntax simply doesn't blend well with the rest of Python's syntax. A syntax which mixes in with other expressions as cleanly as list comprehensions and generator expressions do should have a much better chance of gaining BDFL approval.
  • More friendly to inexperienced users
    • Compared to other Python keywords, 'lambda' is rather esoteric. In the challenge for "farthest outside day-to-day English usage", its closest competitor would probably be 'assert', as even 'def' and 'elif' are just abbreviations for 'define' and 'else if'. Use of simpler keywords may make deferred expressions appear less intimidating than they seem with the current unusual keyword.
  • Less external baggage
    • One of the problems with lambda is that developers familiar with lambda calculus expect more of it than it provides. They expect full anonymous functions, whereas Python's lambda expressions allow deferred evaluation of only a single expression. An alternate syntax described as providing deferred evaluation of expressions rather than anonymous functions may be less prone to trigger complaints about the single expression limitation (consider: how often are complaints heard regarding the restriction of the expression section of list comprehensions or generator expressions to single expressions?).

Arguably Desirable Features

  • Support anonymous suites
    • No discussion of lambda is complete without it being suggested that it should be possible to embed entire suites inside expressions. Accordingly, some suggestions along these lines are included below under the heading Real Closures.

Current Syntax

   1 lambda a, b, c:f(a) + o(b) - o(c)
   2 lambda x: x * x
   3 lambda : x
   4 lambda *a, **k: x.bar(*a, **k)
   5 ((lambda x=x, a=a, k=k: x(*a, **k)) for x, a, k in funcs_and_args_list)

New Syntaxes

Args Before Expression

Nick Coghlan: def-to syntax #a 1

   1 (def (a, b, c) to f(a) + o(b) - o(c))
   2 (def (x) to x * x)
   3 (def () to x)
   4 (def (*a, **k) to x.bar(*a, **k))
   5 ((def (x=x, a=a, k=k) to x(*a, **k)) for x, a, k in funcs_and_args_list)

Nick Coghlan: def-arrow syntax #a 1

   1 (def (a, b, c) -> f(a) + o(b) - o(c))
   2 (def (x) -> x * x)
   3 (def () -> x)
   4 (def (*a, **k) -> x.bar(*a, **k))
   5 ((def (x=x, a=a, k=k) -> x(*a, **k)) for x, a, k in funcs_and_args_list)

Alex Martelli: def-as syntax #b 2

   1 (def (a, b, c) as f(a) + o(b) - o(c))
   2 (def (x) as x * x)
   3 (def () as x)
   4 (def (*a, **k) as x.bar(*a, **k))
   5 ((def (x=x, a=a, k=k) as x(*a, **k)) for x, a, k in funcs_and_args_list)

Dave Benjamin: fun syntax #g 7

   1 (fun(a, b, c): f(a) + o(b) - o(c))
   2 (fun(x): x * x)
   3 (fun(): x)
   4 (fun(*a, **k): x.bar(*a, **k))
   5 ((fun(x=x, a=a, k=k): x(*a, **k)) for x, a, k in funcs_and_args_list)

Roman Suzi: quote-colon syntax #i 9

   1 ` a, b, c:f(a) + o(b) - o(c)
   2 ` x: x * x
   3 ` : x
   4 ` *a, **k: x.bar(*a, **k)
   5 ((` x=x, a=a, k=k: x(*a, **k)) for x, a, k in funcs_and_args_list)

Expression Before Args

Nick Coghlan: for syntax #f 6

   1 (f(a) + o(b) - o(c) for (a, b, c))
   2 (x * x for (x))
   3 (x for ())
   4 (x.bar(*a, **k) for (*a, **k))
   5 ((x(*a, **k) for (x=x, a=a, k=k)) for x, a, k in funcs_and_args_list)

Robert Brewer: for (no-parens) syntax #c 3

   1 (f(a) + o(b) - o(c) for a, b, c)
   2 (x * x for x)
   3 (x for ())
   4 (x.bar(*a, **k) for *a, **k)
   5 ((x(*a, **k) for (x=x, a=a, k=k)) for x, a, k in funcs_and_args_list)

Nick Coghlan: def-from syntax #d 4

   1 (def f(a) + o(b) - o(c) from (a, b, c))
   2 (def x * x from (x))
   3 (def x from ())
   4 (def x.bar(*a, **k) from (*a, **k))
   5 ((def x(*a, **k) from (x=x, a=a, k=k)) for x, a, k in funcs_and_args_list)

Nick Coghlan: from syntax (posted to clp, no reference handy)

   1 (f(a) + o(b) - o(c) from (a, b, c))
   2 (x * x from (x))
   3 (x from ())
   4 (x.bar(*a, **k) from (*a, **k))
   5 ((x(*a, **k) from (x=x, a=a, k=k)) for x, a, k in funcs_and_args_list)

Michael Spencer: from-args syntax #e 5

   1 (f(a) + o(b) - o(c) from args(a, b, c))
   2 (x * x from args(x))
   3 (x from args())
   4 (x.bar(*a, **k) from args(*a, **k))
   5 ((x(*a, **k) from args(x=x, a=a, k=k)) for x, a, k in funcs_and_args_list)

Michael Spencer: for-args syntax #e 5

   1 (f(a) + o(b) - o(c) for args(a, b, c))
   2 (x * x for args(x))
   3 (x for args())
   4 (x.bar(*a, **k) for args(*a, **k))
   5 ((x(*a, **k) for args()) for x, a, k in funcs_and_args_list)

Bengt Richter: colon-function-application syntax #h 8

   1 (:f(a) + o(b) - o(c))(a, b, c)
   2 (:x*x)(X)
   3 (:x)()
   4 (:x.bar(*a, **k))(*a, **k)
   5 ((:x(*a, **k))(x=x, a=a, k=k) for x, a, k in funcs_and_args_list)

Real Closures

Real closures subsume the functionality of lambda plus allow for multi-line statements.


Curly braces for single-line and anonymous def for multi-line (from #h 10, boo #h 11, and this is also very similar to how Ruby does it):

   1 #single-line (similar to ruby syntax)
   2 {a,b,c | return f(a) + o(b) - o(c)}
   3 {x | return x*x}
   4 {return x}
   5 {*a, **k | return x.bar(*a, **k)}
   6 
   7 #multi-line
   8 x = def (a,b,c):
   9     return f(a) + o(b) - o(c)


Perhaps anonymous def for single line, anonymous def for single-line?

foo.addCallback(def (result): result + 1)
foo.addCallback(def (result, myExtra, args):
                     print 'hi!'
                     result += 1
                     return result
                , extra, args=here)

References

AlternateLambdaSyntax (last edited 2008-11-15 14:00:18 by localhost)

Unable to edit the page? See the FrontPage for instructions.