PEP 312 - Making lambdas implicit worries me, surely it's just the name 'lambda' that is bad...

[Gary Stephenson]

In Clipper 5 and it's derivatives ( Xbase++, Visual DB, VO,  Flagship,
Harbour, ... ), lambda style thingies are referred to as "codeblocks", and
have the declaration syntax.:

     b = {|x,y| x+y }

and a special function is provided to evaluate them

    eval( b, 3, 5 )

or even, in some dialects,

    b.eval( 3,5 )

I find this syntax very easy to understand and to teach, and the concept
extremely powerful in practice.  Codeblocks can even be made to serve as
closures (via a mechanism which Clipper 5 christened as "detached locals""),
although the implementation is a little inconsistent imho.

Xbase++ is quite similar to Python in many ways (particularly with 2.2 's
slots-based classes), and I am puzzled why codeblocks seem so
extraordinarily useful in Xbase++, and yet lambdas seem almost to languish
in Python.  Part of the reason may be that Xbase++ doesn't have first-class
functions, but I can't see that being the whole story.

Is there some fundamental difference between the two that I've failed to
appreciate?  Or are codeblocks only so popular in Xbase++ because the rest
of the language is so impoverished in comparison to Python?  Or is the
codeblock syntax superior enough to make the construct more accessible to
"lesser minds".

just curious,

gary



"Roman Suzi" <rnd at onego.ru> wrote in message
news:mailman.1046680745.4884.python-list at python.org...
>
> If I understand correctly, functional-savvy (or even aware) people are
> minority of Python programmers. So all features which advance the FP
> paradigma will be countered by those who "do not need the feature".
>
> Will it lead to a FunPython fork in the future? I hope not!
>
> If FP in Python is indeed Guido's mistake, then lets deprecate lambda,
> map, filter, etc and ban function objects as function arguments/results.
> ;-)
>
> Sincerely yours, Roman A.Suzi
> --
>  - Petrozavodsk - Karelia - Russia - mailto:rnd at onego.ru -
>
>
>