proposed syntax for multiline anony-functions (hopefully?)

[Travis Griggs]

On Aug 21, 2014, at 12:55 AM, icefapper at gmail.com wrote:

> Hi, just wanting to do a shot in the dark,but maybe this syntax is Pythonic (in a "we-are-all-grown-ups" fashion, ahem)enough to get its way into the language
> this is what yours truly thinks: don't we all know that ":" means the next token must be an indent (mostly)? and doesn't the "(" and its alikes, [ and } begin an space-insensitive lexing context? so all we need is having an "space-sensitivity-stack" and the corresponding "(" counting stack and this way we could match opening and closing "()" and pop the space-sensitivity-stack whenever the "(" counting stack gets a 0 at the top:
<snip>

Those more pythonista than me have weighed in on the particulars. I’ll offer some more general thoughts.

While I dwell in the land of pythonistas, I’m a an expat from the Island of Smalltalk. I live happily in Pythonville and will probably never return to the shrinking island, I do miss Smalltalk’s block closures. I don’t miss them *too* much, because things like comprehensions as well as the large library of functional like modules, covers many of the use cases. But I do miss their simple elegance.

I do not like the python lambda. For two reasons.

One: In a language that sought to be approachable by simple people (i.e. non computer science graduates who would use it in addition to their scientific/education background), I can’t believe they threw in a 6 character  phonetic description of a greek character to imply “fragment of code expression to be executed in a removed context”. Show a subset of keyword.kwlist to a non-comp-sci guy and tell me if when they see the ‘lambda’ betwixt the others, they don’t stop and think “huh, one of these is not like the others”.

Two: The reason that this subject circles regularity, because they used a keyword, it can only be used as a literal creator for a single line expression. So we keep coming back to “how can we do multiple expressions with a lambda/closure”.

For the unaware, the Smaltalk syntax for a literal block closure was a pair of [ ]. First of all, I liked that the characters actually looked like a “block” with the corners. I liked that it did not use parentheses. Parentheses are pretty loaded already, and it helped the brain pick out the differences instantly. I don’t like the OP’s proposal because I don’t think (def()) is distinct from normal grouping () statements. And I liked how terse they are. Two characters and you had a block. They are *everywhere* in the library. Compare that with how often you find ‘lambda’ in the python standard modules. I used to joke about the irony, that no language did more with functional closures than the all-objects-all-the-time Smalltalk, and that CLOS had a more robust object model than Smalltalk.

To me, for a multiple-expression (multi line or not) literal closure syntax to succeed, it must a) denote both the start and stop (not a leading keyword), b) be extremely terse so that the cost of creating closures is reduced c) not be confused with other common literal denotation so it can be quickly recognized when reading close (so [ and { are out for example, because of lists and dictionaries, and using < > would cause complete confusion because it’s hard at a glance to differentiate from a comparison operand).

Personally, I don’t think the desire to use lines as statement boundaries (something I like a lot) and at the same time to tersely pack multiple statements into a deferred code fragment, are reconcilable. And I don’t think there’s critical mass desire for them. So this subject will continue to resurface regularly. But I thought I’d chime in with a “foreigners” perspective.