Replacement for lambda - 'def' as an expression?

[Paul Rubin]

Re: Replacement for lambda - 'def' as an expression?

"Terry Reedy" <tjreedy@udel.e du> writes:[color=blue]
> Are you claiming that including a reference to the more humanly readable
> representation of a function (its source code) somehow detracts from the
> beauty of the function concept?[/color]

Huh? Anonymous functions mean you can use functions as values by
spelling out their source code directly, instead of having to make a
separate reference and then pass that. There are times when the
separate reference is just clutter. It's less readable, not more readable.
[color=blue]
> Or are you claiming that binding a
> function to a name rather than some other access reference (like a list
> slot) somehow detracts from its conceptual beauty? Is so, would you say
> the same about numbers?[/color]

Yes, I would say the same about numbers; Python would suffer if users
were required to give a name to every number. I'd say

x = f(1, 3)

is much less ugly than

one = 1
three = 3
x = f(one, three)

I further don't see how the second example is more "readable" than the first.

[Simo Melenius]

Re: Replacement for lambda - 'def' as an expression?

Paul Rubin <http://phr.cx@NOSPAM.i nvalid> writes:
[color=blue]
> Sybren Stuvel <sybrenUSE@YOUR thirdtower.com. imagination> writes:[color=green]
> > An example:
> >
> > def generate_random izer(n, m):
> > randomizer = def(x):
> > return x ** n % m
> >
> > return randomizer[/color]
>
> 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[/color]

But if you could do anonymous blocks, you could just write something
like:

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

Personally, I don't mind naming local functions in practice (and
Python syntax doesn't lend itself very well to anonymous blocks) but
rather, the nuisance is that I feel there's just plain something wrong
with it. It's less beautiful than it could be.

Luckily, the last time I followed the discussion on this topic in
c.l.p, some bright mind whose name escapes me now pointed out the
craziness of _having to_ name functions by comparing it to the
situation where you'd have to bind any literal objects to symbols
before you could use them. Like:

def return_fixed_nu mber ():
res = 42
return res

or:

arg1 = "foo"
arg2 = 42
arg3 = baz ()
myfunction (arg1, arg2, arg3.xyzzy ())

Sure, you don't lose any expressiveness in that: if you had to name
any object before using it, you could write all the same programs that
you can in the current Python. But it's the expressiveness of your
mind that gets harpooned: you'll have to keep part of your focus on
these extraneous local variables instead of thinking only in terms
of values where only values matter.


--
firstname.lastn ame@iki.fi -- Today is the car of the cdr of your life.

[Paul Rubin]

Re: Replacement for lambda - 'def' as an expression?

Simo Melenius <firstname.last name@iki.fi-spam> writes:[color=blue]
> But if you could do anonymous blocks, you could just write something
> like:
>
> def generate_random izer (n, m):
> return def (x):
> return pow (x, n, m)[/color]

Yes, as it stands you can already say:

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

I was showing that it can also be done with a named internal function.
[color=blue]
> Sure, you don't lose any expressiveness in that: if you had to name
> any object before using it, you could write all the same programs that
> you can in the current Python. But it's the expressiveness of your
> mind that gets harpooned: you'll have to keep part of your focus on
> these extraneous local variables instead of thinking only in terms
> of values where only values matter.[/color]

Yes, I agree with this.

[Tom Anderson]

Re: Replacement for lambda - 'def' as an expression?

On Tue, 6 Sep 2005, talin at acm dot org wrote:
[color=blue]
> add = def( a, b ):
> return a + b[/color]

+1

This is so obviously the right syntax for closures in python that i really
can't believe we're still arguing about it.
[color=blue]
> 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 )[/color]

Can't we just rely on indentation here:

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

?

A consequence of that is that you *must* end the suite on a line of its
own; with your scheme, you can in fact write:

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

Although i'm not convinced that this is something i want to be possible!
[color=blue]
> The one-liner version looks a lot prettier of course:
>
> a = map( (def( item ): return item * item), list )[/color]

To do one-liners, which is absolutely essential, we can't rely on line
ends, of course, so we'd need your scheme to be in operation here. For
consistency, it should also apply to multi-line suites; it should be
possible to have both the bracket-based and line-based rules in effect at
the same time - changes in indent level are essentially treated as a kind
of bracket.
[color=blue]
> 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.[/color]

If there were no statements which ended with an expression list, it would
be possible to detect the end by the presence of a comma. The python
grammar would only need a few changes to meet that requirement, none of
them that disruptive (mostly, you replace the expression list with a tuple
- in many cases, making explicit what was previously implicit).
[color=blue]
> (Besides, if being an expression is good enough for 'yield', why
> shouldn't def get the same privilege? :)[/color]

A fine point!

tom

--
And the future is certain, give us time to work it out