question about what lamda does

[Bruno Desthuilliers]

danielx wrote:
> Bruno Desthuilliers wrote:
> 
>>danielx wrote:
>>(snip)
>>
>>
>>>Python's lambda really can't be as powerful as Lisp's because Python
>>>does not have expressions that do case analysis (this is not lambda's
>>>fault, of course ;). The reason is that you really want to put each
>>>case on its own set of lines.

An expression can span several lines.

> This enhances readability at the expense
>>>of terseness. Since Python's statements are terminated by a newline, 

or by a ';'

> it
>>>would be rather awkward to have a kind of expression where good style
>>>calls for it to be spread out accross multiple lines.

I must be pretty dumb, but I don't see how this relate to the problem of
case analysis in lambda expressions ?

>>>You can try to simulate these kinds expressions using into a list or
>>>dictionary, but this becomes rather messy. I think the only way to get
>>>this done properly is to use eval. For example:
>>>
>>>def recursiveFunction(args):
>>>  ...  # do stuff...
>>>  choices = { True:"0", False:"recurisveFunction(newArgs)" }
>>>  return eval( choices[predicate] )
>>
>>Why do you want to use eval here ?
>>
>>
>>>The reason that you need eval is that you want to prevent any cases
>>>from being executed until you decide which one you want.
>>
>>What about:
>>
>>def recursiveFunction(args):
>>    ... # do stuff...
>>    ... # that defines 'newArgs' and 'predicate' of course ...
>>    return (recursiveFunction, lambda x: 0)[predicate](newArgs)
> 
> 
> Sure, that works, but don't take things so literally.

Sorry for being pragmatic !-)

> For instance, if
> you have a bunch of cases, you might not way to apply the same set of
> arguments to all of them.

return {
  'case1' : lambda: someFunc(args1),
  'case2' : lambda: someFunc(args2),
  'case3' : lambda: someOtherFunc(args1, arg42),
}.get(predicate, lambda: 0)()

Still no need for eval()...

Now of course there are limits to the exercice, and we're still far away
from ML-like pattern matching or Lisp 'case' forms. As you noted, Python
is a statement-based language, not an expression-based one like Lisp.
This makes a definitive difference.

> Also, let's not get distracted from the main point about how doing case
> analysis in an expression is ugly,

Ugliness is in the eyes of the beholder <wink>

> making lambda's weaker in Python
> than in the language which inspired them.

The fact is that Python "lambdas" are *not* Lisp lambdas. Python
"lambdas" are mostly a handy trick to turn a *simple* expression into a
 closure - and definitively not a basic building block of the language.

Daniel, I of course do agree that Python lambdas are nothing near Lisp
lambdas - FWIW, Python is not Lisp neither -, but that looks like an
apple and banana comparison to me... IMHO, the most obvious problem with
Python lambdas is the word "lambda" !-)


-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb at xiludom.gro'.split('@')])"