Code block literals

[John Roth]

"Greg Ewing (using news.cis.dfn.de)" <g2h5dqi002 at sneakemail.com> wrote in
message news:bmd3cv$lk51t$1 at ID-169208.news.uni-berlin.de...
> Dave Benjamin wrote:
> > In that case, why do we eschew code blocks, yet have no problem with the
> > implicit invocation of an iterator,
>
> I don't think code blocks per se are regarded as a bad thing.
> The problem is that so far nobody has come up with an entirely
> satisfactory way of fitting them into the Python syntax as
> expressions.

I know. I played around with the idea a bit after it came up a couple
of weeks ago, and identified a number of issues.

1. One code block, or a code block for any parameter?
This isn't as simple as it seems. Ruby does one code block
that is an implicit parameter to any method call, but in
Smalltalk any method parameter can be a code block.

2. How do you invoke a code block? Does it look just like
a function? I presume so. If you do one code block per
method call, though, it gets a bit sticky. Again, Ruby
uses a special keyword ('yield') to invoke such a code
block, while if code blocks were simply anon functions,
then it's a non-issue.

3. Expression or statement syntax? Ruby avoids the
problem by making its single code block a special
construct that immediately follows the method
call parameter list, and it doesn't have the chasm
between expression and statement syntax that's built
into Python.

4. Do we want it to be smoothly substitutable for
lambda? I presume so, simply based on the principle
of minimum surprise. Then that forces multiple
code blocks in a method, which in turn reduces
a lot of other issues.

5. Is uglyness really an issue? One of the major
discussion points (read: flame war issues) any time
expanding expression syntax comes up is that
expressions that are too long become unreadable
very rapidly.

So what I come up with at this point is twofold:

1. We need to be able to insert a code block in
any parameter, and

2. Code blocks need to have statement syntax.

So let's say I want to use a code block instead of
a lambda or a named function in a map:

foobar = map(def (x, y, z):
        astatement
        anotherstatement
    list1, list2, list3)

This doesn't actually look anywhere near as bad
as I thought it might. The indentation, though, is a
bit peculiar. The first point is that the statements
in the code block are indented with respect to the
enclosing statement, NOT with respect to the first
word ('def') that starts the code block.

The second point is that the continuation of the
embedding expression has to dedent to close the
code block without closing the embedding statement,
and this has to be visually identifiable.

A third item is that I don't really care if we use 'def'
or not. Borrowing the vertical bar from Ruby, the map
example becomes:

foobar = map(| x, y, z |
        astatement
        anotherstatement
    list1, list2, list3)

I kind of like this better, except for one really unfortunate
issue: it's going to raise havoc with code coloring algorithms
for a while.

John Roth

>
> -- 
> Greg Ewing, Computer Science Dept,
> University of Canterbury,
> Christchurch, New Zealand
> http://www.cosc.canterbury.ac.nz/~greg
>