Re: map/filter/reduce/lambda opinions and background unscientific mini-survey
I have never written a line of Lisp or Scheme, so it took me a while to
grok "lambda" as a synonym for "expression to be evaluated later". I
then thought it was similar to Smalltalk's functional closures, since
you can define local arguments at the beginning of the block, and then
write the body of the block using those args. But then I saw that it
was only a subset of that capability, since one may only implement an
expression in a lambda, not a full code block.
Even with those limitations, I've found lambda to be a nice compact
form for specifying callbacks. It is especially helpful in pyparsing,
where I define a mechanism for the programmer to specify a parse action
to be performed, which can modify the matched tokens. Here is one that
is very compact:
quotedString.se tParseResults( lambda s,loc,toks: toks[0][1:-1] )
Parse actions take 3 arguments: the original string being parsed, the
location of the beginning of the match, and a ParseResults object
containing the matched tokens (ParseResults objects can act as a list,
dict, or object with attributes). The purpose of this parse action is
to remove the opening and closing quotation marks from the matched
quoted string. One of the things I especially like about this
simplicity of parse actions is that there is no need for checking
whether toks is an empty list, or if the first and last characters are
quotation marks before stripping them - quotedStrings call their parse
actions *only* with a single element list, and only with the first
element containing a string with opening and closing quotes. Still, in
anticipation of the demise of lambda, and because this function is
frequently needed, I've added it as a built-in helper function to
pyparsing, called removeQuotes. But lambda is very simple and
immediate for defining such simple transforms, and there is no need to
go track down where a named function definition may be found. (Yes, I
*could* stop in my tracks just prior to this statement and define this
one-line function, but then this interrupts the flow of my grammar
definition.)
It seems to me that lambda's built-in limitation of *only* supporting
expressions, rather than complete code blocks, has led to people
applying their boundless creativity to trying to cram conditional logic
into bewildering and failure-prone boolean expressions, and it reminds
me of some of the C macro coding that I had to sift through about 20
years ago.
Not coincidentally, I think the lambda limitation is the true origin of
may of the requests we read on c.l.py for the proper syntax for
Python's version of the ternary ?: operator as in "how do I write
(x>10? a : b) in Python", which is invariably followed by a post such
as, "don't bother with that, just do "(x>10 and a or b)", which is then
usually followed with, "but watch out in case a evaluates to False..."
So personally, I like lambdas even if I am not found of the keyword
"lambda". Maybe we could replace "lambda" with "@" or "$"?
-- Paul
I have never written a line of Lisp or Scheme, so it took me a while to
grok "lambda" as a synonym for "expression to be evaluated later". I
then thought it was similar to Smalltalk's functional closures, since
you can define local arguments at the beginning of the block, and then
write the body of the block using those args. But then I saw that it
was only a subset of that capability, since one may only implement an
expression in a lambda, not a full code block.
Even with those limitations, I've found lambda to be a nice compact
form for specifying callbacks. It is especially helpful in pyparsing,
where I define a mechanism for the programmer to specify a parse action
to be performed, which can modify the matched tokens. Here is one that
is very compact:
quotedString.se tParseResults( lambda s,loc,toks: toks[0][1:-1] )
Parse actions take 3 arguments: the original string being parsed, the
location of the beginning of the match, and a ParseResults object
containing the matched tokens (ParseResults objects can act as a list,
dict, or object with attributes). The purpose of this parse action is
to remove the opening and closing quotation marks from the matched
quoted string. One of the things I especially like about this
simplicity of parse actions is that there is no need for checking
whether toks is an empty list, or if the first and last characters are
quotation marks before stripping them - quotedStrings call their parse
actions *only* with a single element list, and only with the first
element containing a string with opening and closing quotes. Still, in
anticipation of the demise of lambda, and because this function is
frequently needed, I've added it as a built-in helper function to
pyparsing, called removeQuotes. But lambda is very simple and
immediate for defining such simple transforms, and there is no need to
go track down where a named function definition may be found. (Yes, I
*could* stop in my tracks just prior to this statement and define this
one-line function, but then this interrupts the flow of my grammar
definition.)
It seems to me that lambda's built-in limitation of *only* supporting
expressions, rather than complete code blocks, has led to people
applying their boundless creativity to trying to cram conditional logic
into bewildering and failure-prone boolean expressions, and it reminds
me of some of the C macro coding that I had to sift through about 20
years ago.
Not coincidentally, I think the lambda limitation is the true origin of
may of the requests we read on c.l.py for the proper syntax for
Python's version of the ternary ?: operator as in "how do I write
(x>10? a : b) in Python", which is invariably followed by a post such
as, "don't bother with that, just do "(x>10 and a or b)", which is then
usually followed with, "but watch out in case a evaluates to False..."
So personally, I like lambdas even if I am not found of the keyword
"lambda". Maybe we could replace "lambda" with "@" or "$"?
-- Paul
Comment