A replacement for lambda

[Mike Meyer]

I know, lambda bashing (and defending) in the group is one of the most
popular ways to avoid writing code. However, while staring at some Oz
code, I noticed a feature that would seem to make both groups happy -
if we can figure out how to avoid the ugly syntax.

This proposal does away with the well-known/obscure "lambda"
keyword. It gives those who want a more functional lambda what they
want. It doesn't add any new keywords. It doesn't add any new magic
characters, though it does add meaning to an existing one. That could
be replaced by a new magic token, or adding magic meaning to a
non-magic token. It breaks no old code either way.

I haven't really worked out all the implications; I just wanted to
throw it out and see what everyone else thought about it. As a
result, the code examples tend to be ugly.

As previously hinted, this feature is lifted from Oz.

Currently, class and functions definitions consist of a keyword -
either "class" or "def" - followed by a name, a header, then code. The
code is compiled into an object, and the name is bound to that object.

The proposal is to allow name to be a non-name (or rare name)
token. In this case, the code is compiled and the resulting object is
used as the value of the class/def expression.

My choice for the non-name token is "@". It's already got magic
powers, so we'll give it more rather than introducing another token
with magic powers, as the lesser of two evils.

Rewriting a canonical abuse of lambda in this idiom gives:

myfunc = def @(*args):
return sum(x + 1 for x in args)

In other words, this is identical to:

def myfunc(*args):
return sum(x + 1 for x in args)

We can write the same loop with logging information as:

sum(def @(arg):
print "Bumping", arg
return arg + 1
(x) # '(' at the same indent level as def, to end the definition
for x in stuff)

A more useful example is the ever-popular property creation without
cluttering the class namespace:

class Spam(object):
myprop = property(fget = def @(self):
return self._propertie s['myprop']
,
fset = def @(self, value):
self._propertie s['myprop'] = value
,
fdel = def @(self)
del self._propertie s['myprop']
,
doc = "Just an example")

This looks like the abuse of lambda case, but these aren't
assignments, they're keyword arguments. You could leave off the
keywords, but it's not noticably prettier. fget can be done with a
lambda, but the the others can't.

Giving clases the same functionality seems to be the reasonable thing
to do. It's symmetric. And if anonymous function objects are good,
then anonymous class objects ought to be good as well.

<mike
--
Mike Meyer <mw*@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Paul Rubin]

D H <no@spam> writes:

where fdel = def (self):
...........
As you can see, it doesn't save much over the traditional way since
you have to name the "anonymous" lambdas anyway.

It saves polluting the surrounding namespace with superfluous variables
that aren't going to be used again.

[Paddy]

Christopher Subich <spam.csubich+b [e-mail] ch.spam.com> writes:

Basically, I'd rewrite the Python grammar such that:
lambda_form ::= "<" expression "with" parameter_list ">"

I do prefer my parameter list to come before the expression. It would
remain consistant with simple function definitions.

- Cheers, Paddy.

[Stefan Rank]

on 30.07.2005 10:20 Paolino said the following:

why (x**2 with(x))<(x**3 with(x)) is not taken in consideration?

If 'with' must be there (and substitue 'lambda:') then at least the
syntax is clear.IMO Ruby syntax is also clear.

I am sorry if this has already been proposed (I am sure it has).

Why not substitue python-lambdas with degenerated generator expressions::

(lambda x: func(x)) == (func(x) for x)

i.e. a one time callable generator expression (missing the `in` part).
The arguments get passed into the generator, I am sure that can be
combined with the PEP about passing args and Exceptions into a generator.

[Paul Rubin]

Stefan Rank <st*********@of ai.at> writes:

I am sorry if this has already been proposed (I am sure it has).
Why not substitue python-lambdas with degenerated generator expressions::

(lambda x: func(x)) == (func(x) for x)

I don't think I've seen that one before, and FWIW it's kind of cute.

But what's wrong with leaving lambdas the way they are? Anyone who can
understand generator expressions can understand lambda. I don't see any
point in trying to improve on lambda, without actually fixing its main
problem, which is the inability to create multi-statement closures.

[Kay Schluehr]

Mike Meyer schrieb:

I know, lambda bashing (and defending) in the group is one of the most
popular ways to avoid writing code. However, while staring at some Oz
code, I noticed a feature that would seem to make both groups happy -
if we can figure out how to avoid the ugly syntax.

This proposal does away with the well-known/obscure "lambda"
keyword. It gives those who want a more functional lambda what they
want. It doesn't add any new keywords. It doesn't add any new magic
characters, though it does add meaning to an existing one. That could
be replaced by a new magic token, or adding magic meaning to a
non-magic token. It breaks no old code either way.

Mike,

in modern functional language design one starts with certain lambda
expressions and add syntax sugar ( operational / statement syntax ) for
constructs based on them. In Python statement- and expression syntax
were introduced seperately. Pythons lambda is simply the symptom of
this separation. Now you suggest ( not the first time on this list or
at python-dev ) to put statements into expressions leading to a strange
syntax and conflicting with Pythons indentation rules.

Another way to deal with the restrictions of lambda is going the other
way round and simply propose expression syntax for conds and
assignments.

Using guards '||' and the keyword 'then' for conditional expressions:

( || x>=0 then f(x) || True then f(-x) )

Or shorter dropping 'then' in the second condition:

( || x>=0 then f(x) || f(-x) )

Both translates to:

if x>=0:
f(x)
else:
f(-x)

Using a reverse arrow for assignments:

x <- y

For loops can be replaced by functional constructs ( use map() or a
list/generator comprehension ).

Finally the lambda keyword can be replaced by expressional syntax e.g.
( EXPR from ARGS ):

Examples:
f = ( || x>=0 then f(x) || True then f(-x) from (x,) )
g = ( || x< 0 then self._a <-x || self._a <- 0 from (x,))

Kay

[Paul Rubin]

"Kay Schluehr" <ka**********@g mx.net> writes:

Examples:
f = ( || x>=0 then f(x) || True then f(-x) from (x,) )
g = ( || x< 0 then self._a <-x || self._a <- 0 from (x,))

Is this an actual language? It looks sort of like CSP. Python
with native parallelism, mmmmm.

[Kay Schluehr]

Paul Rubin wrote:

"Kay Schluehr" <ka**********@g mx.net> writes:

Examples:
f = ( || x>=0 then f(x) || True then f(-x) from (x,) )
g = ( || x< 0 then self._a <-x || self._a <- 0 from (x,))

Is this an actual language? It looks sort of like CSP. Python
with native parallelism, mmmmm.

The syntax was inspired by OCamls pattern matching syntax:

match object with
pattern1 -> result1
| pattern2 -> result2
| pattern3 -> result3
...

But for Python we have to look for an expression not a statement
syntax. In order to prevent ambiguities I used a double bar '||'
instead of a single one.

Kay

[Reinhold Birkenfeld]

Stefan Rank wrote:

on 30.07.2005 10:20 Paolino said the following:

why (x**2 with(x))<(x**3 with(x)) is not taken in consideration?

If 'with' must be there (and substitue 'lambda:') then at least the
syntax is clear.IMO Ruby syntax is also clear.

I am sorry if this has already been proposed (I am sure it has).

Why not substitue python-lambdas with degenerated generator expressions::

(lambda x: func(x)) == (func(x) for x)

i.e. a one time callable generator expression (missing the `in` part).
The arguments get passed into the generator, I am sure that can be
combined with the PEP about passing args and Exceptions into a generator.

It's hard to spot, and it's too different to a genexp to have such a similar
syntax.

Reinhold

[Seth Nielson]

I understand that there are a number of people who wish to remove
lambda entirely from the language. Nevertheless, I find it a useful
and powerful tool in actual development.

Any replacement must support the following: *delayed evaluation*.

I need a convenient (def is not always convenient) way of saying,
"don't do this now". That is why I use lambda.

-- Seth Nielson

On 7/30/05, Reinhold Birkenfeld <re************ ************@wo lke7.net> wrote:

Stefan Rank wrote:

on 30.07.2005 10:20 Paolino said the following:

why (x**2 with(x))<(x**3 with(x)) is not taken in consideration?

If 'with' must be there (and substitue 'lambda:') then at least the
syntax is clear.IMO Ruby syntax is also clear.

I am sorry if this has already been proposed (I am sure it has).

Why not substitue python-lambdas with degenerated generator expressions::

(lambda x: func(x)) == (func(x) for x)

i.e. a one time callable generator expression (missing the `in` part).
The arguments get passed into the generator, I am sure that can be
combined with the PEP about passing args and Exceptions into a generator.

It's hard to spot, and it's too different to a genexp to have such a similar
syntax.

Reinhold
--
http://mail.python.org/mailman/listinfo/python-list

[Paul Rubin]

Seth Nielson <se****@gmail.c om> writes:

Any replacement must support the following: *delayed evaluation*.

I need a convenient (def is not always convenient) way of saying,
"don't do this now". That is why I use lambda.

How's this: f{args} (curly braces instead of parens) is the same as
f(lambda: args).

Examples:

launch_thread{t argetfunc(a,b,c )}

b = Button{callback =pressed()} # Button remembers callback()

def ternary(cond, x, y):
if cond(): return x()
else: return y()

sign_of_a = ternary{a < 0, -1, 1}
etc.