Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.albasani.net!news.stack.nl!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: proposed syntax for multiline anony-functions (hopefully?)
From: Travis Griggs <travisgriggs@gmail.com>
In-Reply-To: <1bd05b41-ad00-4ce8-8678-de51205ebc3b@googlegroups.com>
Date: Fri, 22 Aug 2014 13:05:53 -0700
Content-Transfer-Encoding: quoted-printable
References: <1bd05b41-ad00-4ce8-8678-de51205ebc3b@googlegroups.com>
To: python-list@python.org
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.13305.1408737958.18130.python-list@python.org>
Lines: 69
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:76817


On Aug 21, 2014, at 12:55 AM, icefapper@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=92ll =
offer some more general thoughts.

While I dwell in the land of pythonistas, I=92m 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=92s block =
closures. I don=92t 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=92t believe they threw in a 6 =
character  phonetic description of a greek character to imply =93fragment =
of code expression to be executed in a removed context=94. Show a subset =
of keyword.kwlist to a non-comp-sci guy and tell me if when they see the =
=91lambda=92 betwixt the others, they don=92t stop and think =93huh, one =
of these is not like the others=94.

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 =93how can we do multiple =
expressions with a lambda/closure=94.

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 =93block=94 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=92t like the OP=92s =
proposal because I don=92t 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 =91lambda=92 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=92s hard at a glance to =
differentiate from a comparison operand).

Personally, I don=92t 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=92t think there=92s critical mass desire for them. So this subject =
will continue to resurface regularly. But I thought I=92d chime in with =
a =93foreigners=94 perspective.=