Replacement for lambda - 'def' as an expression?

[talin at acm dot org]

I've been reading about how "lambda" is going away in Python 3000 (or
at least, that's the stated intent), and while I agree for the most
part with the reasoning, at the same time I'd be sad to see the notion
of "anonymous functions" go - partly because I use them all the time.

Of course, one can always create a named function. But there are a lot
of cases, such as multimethods / generics and other scenarios where
functions are treated as data, where you have a whole lot of functions
and it can be tedious to come up with a name for each one.

For example, my current hobby project is implementing pattern matching
similar to Prolog in Python. The dispatcher I am making allows you to
create "overloaded " versions of a function that take different patterns
as their input arguments, so that Simplify( (add, x, y) ) calls a
different method than Simplify( (log, x) ) -- in other words, the
choice of which code is executed is based on the structure of the tuple
that is passed into it. However, in order for this to work, I need to
be able to assign a block of Python code to a particular pattern, and
having to invent a named function for each pattern is a burden :)

Anyway, here's an example, then, of how 'def' could be used:

add = def( a, b ):
return a + b

The lack of a function name signals that this is an anonymous function.
The def keyword defines the function using the same syntax as always -
the arguments are in parentheses, and are unevaluated; The colon marks
the beginning of a suite.

In fact, it looks a lot like the existing lambda, with a couple of
differences:

1) It uses the familiar "def" keyword, which every Python beginner
understands, instead of the somewhat unfamiliar "lambda"
2) The arguments are enclosed in parentheses, instead of a bare tuple
followed by a colon, again reiterating the similarity to the normal
usage of "def".
3) The statements are a real suite instead of a pseudo-suite - they can
consist of multiple lines of statements.

Like all statements whose last argument is a suite, you can put the
body of the function on a single line:

add = def( a, b ): return a + b

(If this were Perl, you could also omit the "return", since in Perl the
last evaluated expression in the function body is what gets returned if
there's no explicit return statement.)

What about passing an anonymous function as an argument, which is the
most common case? This gets tricky, because you can't embed a suite
inside of an expression. Or can you?

The most powerful option would be to leverage the fact that you can
already do line breaks inside of parentheses. So the "def" keyword
would tell the parser to restart the normal indentation calculations,
which would terminate whenever an unmatched brace or paren was
encountered:

a = map(
(def( item ):
item = do_some_calcula tion( item )
return item
), list )

The one-liner version looks a lot prettier of course:

a = map( (def( item ): return item * item), list )

And it looks even nicer if we switch the order of the arguments around,
since you can now use the final paren of the enclosing function call to
terminate the def suite.

a = map( list, def( item ): return item * item )

Unfortunately, there's no other good way I can think of to signal the
end of the block of statements without introducing some radical new
language construct.

(Besides, if being an expression is good enough for 'yield', why
shouldn't def get the same privilege? :)

[Torsten Bronger]

Hallöchen!

"talin at acm dot org" <vi*****@gmail. com> writes:

[...]

Anyway, here's an example, then, of how 'def' could be used:

add = def( a, b ):
return a + b

I'm really not an expert in functional programming, so I wonder
what's the difference between "add = def" (assumed that it worked)
and "def add"?

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus ICQ 264-296-646

On Tue, 06 Sep 2005 12:19:21 +0200
Torsten Bronger wrote:

"talin at acm dot org" <vi*****@gmail. com> writes:

Anyway, here's an example, then, of how 'def' could be used:

add = def( a, b ):
return a + b

I'm really not an expert in functional programming, so I wonder
what's the difference between "add = def" (assumed that it worked)
and "def add"?

In the former case one could write

self.add[0] = def(a, b)
# etc.

--
jk

[Sybren Stuvel]

talin at acm dot org enlightened us with:

I'd be sad to see the notion of "anonymous functions" go
Same here. I think it's a beautyful concept, and very powerful. It
also allows for dynamic function creation in cases where a name would
not be available.
What about passing an anonymous function as an argument, which is
the most common case?

I don't really like that. The syntax is way too messy. Just the

funcref = def(args):
...

syntax would suffice for me.

Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa

[Rocco Moretti]

en**********@os paz.ru wrote:

On Tue, 06 Sep 2005 12:19:21 +0200
Torsten Bronger wrote:

"talin at acm dot org" <vi*****@gmail. com> writes:

Anyway, here's an example, then, of how 'def' could be used:

add = def( a, b ):
return a + b

I'm really not an expert in functional programming, so I wonder
what's the difference between "add = def" (assumed that it worked)
and "def add"?

In the former case one could write

self.add[0] = def(a, b)
# etc.

If that's the issue, it might make more sense to extend def to take any
lvalue.

def self.add[0](a, b):
return a + b

[Leif K-Brooks]

Sybren Stuvel wrote:

It also allows for dynamic function creation in cases where a name
would not be available.

What cases are those?

[Sybren Stuvel]

Leif K-Brooks enlightened us with:

It also allows for dynamic function creation in cases where a name
would not be available.

What cases are those?

An example:

def generate_random izer(n, m):
randomizer = def(x):
return x ** n % m

return randomizer

Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa

[Paul Rubin]

Sybren Stuvel <sy*******@YOUR thirdtower.com. imagination> writes:

An example:

def generate_random izer(n, m):
randomizer = def(x):
return x ** n % m

return randomizer

You're a little bit confused; "name" doesn't necessarily mean "persistent
name". You could write the above as:

def generate_random izer (n, m):
def randomizer(x):
return pow(x, n, m)
return randomizer

[D H]

talin at acm dot org wrote:

I've been reading about how "lambda" is going away in Python 3000 (or

See the page built from earlier threads about this:
http://wiki.python.org/moin/AlternateLambdaSyntax

Your syntax is the same used in boo: http://boo.codehaus.org/Closures

[Terry Reedy]

"talin at acm dot org" <vi*****@gmail. com> wrote in message
news:11******** **************@ z14g2000cwz.goo glegroups.com.. .

Of course, one can always create a named function. But there are a lot
of cases, such as multimethods / generics and other scenarios where
functions are treated as data, where you have a whole lot of functions
and it can be tedious to come up with a name for each one.
Either reuse names or 'index' them: f0, f1, f2, ...
add = def( a, b ):
return a + b
The difference between this and def add(a,b): return a+b would be the
finding of .func_name to an uninformative generic tag (like '<lambda.>')
versus the informative 'add'.
I need to be able to assign a block of Python code to a particular
pattern,
How about (untested -- I have never actually written a decorator, and am
following a remembered pattern of parameterized decorators) :

patcode = {}
def pat(pattern): # return decorator that registers f in patcode
def freg(f):
f.func_name = 'pat: <%s>' % pattern # optional but useful for debug
patcode[pattern] = f
# no return needed ? since def name is dummy
return freg

@pat('pattern1' )
def f(): <code for pattern 1>

@pat('pattern2' )
def f(): <code> for pattern 2>

etc

or define freg(f,pat) and call freg *after* each definition
having to invent a named function for each pattern is a burden :)

But you do not *have to* ;-)
or rather, you can replace func_name with a useful tag as suggested above.

Terry J. Reedy