[Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda

Kay Schluehr kay.schluehr at gmx.net
Sat Jun 18 13:43:27 CEST 2005


Josiah Carlson wrote:

 > Kay Schluehr <kay.schluehr at gmx.net> wrote:
 >
 >
 >> Maybe anonymus function closures should be pushed forward right now 
not only syntactically? Personally I could live with lambda or several
 >> of the alternative syntaxes listed on the wiki page.
 >>
 >
 >
 >
 >
 >> But asking for a favourite syntax I would skip the "def" keyword 
from your def-arrow syntax proposal and use:
 >>
 >>    ((a, b, c) -> f(a) + o(b) - o(c))
 >>
 >
 > ...
 >
 >
 >
 >> The arrow is a straightforward punctuation for function definitions. 
Reusing existing keywords for different semantics seems to me as a kind 
of inbreeding.
 >>
 >
 >
 > That's starting to look like the pseudocode from old algorithms
 > textbooks, which is very similar to bad pseudocode from modern CS theory
 > papers.  Punctuation as a replacement for words does not always win
 > (perfect examples being 'and' vs. &&, 'or' vs. ||, 'not' vs. !, ...)
 >
 >

Writing functions as arrows is very convenient not only in CS but also 
in mathematics. Looking like pseudo-code was not one of Guidos Python 
regrets if I remember them correctly.

 > -1 on the syntax offering.
 >
 >
 >
 >> For pushing anymus functions forward I propose to enable explizit 
partial evaluation as a programming technique:
 >>
 >
 >
 > If I remember correctly, we've got rightcurry and leftcurry for that (or
 > rightpartial and leftpartial, or something).
 >
 >

Currying usually does not perform a function evaluation in order to 
create another more special function. Partial evaluation is a dynamic 
programming and optimization technique. Psyco uses specialization and
caching implicitely. I propose to use it explicitely but in a more 
restricted context.

 >> >>> ((x,y) -> (x+1)*y**2)
 >> ((x,y) -> (x+1)*y**2)
 >>
 >> >>> ((x,y) -> (x+1)*y**2)(x=5)
 >> ((y) -> 6*y**2)
 >>
 >
 >
 > I'll assume that you don't actually want it to rewrite the source, or
 > actually return the source representation of the anonymous function
 > (those are almost non-starters).
 >
 >

Computer algebra systems store expressions in internal tree form, 
manipulate them efficiently and pretty-print them in textual or latex 
output on demand. There would be much more involved than a tree to tree 
translation starting with Pythons internal parse tree and an evaluator 
dedicated to it.

 > As for all anonymous functions allowing partial evaluation via keywords:
 > it would hide errors. Right now, if you forget an argument or add too
 > many arguments, you get a TypeError. Your proposal would make
 > forgetting an argument in certain ways return a partially evaluated
 > function.


That's why I like to dump the function in a transparent mode. Personally 
I could dispense a little security in favor for cheap metainformation.

Regards,
Kay






More information about the Python-Dev mailing list