Code block literals

[Terry Reedy]

"Sean Ross" <sross at connectmail.carleton.ca> wrote in message
news:lqzib.4539$cT6.106958 at news20.bellglobal.com...
> My idea would be to define imap as follows:
>
>   def imap(&function, *iterables):
>          iterables = map(iter, iterables)
>          while True:
>              args = [i.next() for i in iterables]
>              if function is None:
>                  yield tuple(args)
>              else:
>                  yield function(*args)
>
> and the use could be more like this:
>
> mapped = imap(sequence) with x:
>         print x  # or whatever
>         return x*x
>
> with x: ... creates a thunk, or anonymous function, which will be
fed as an
> argument to the imap function in place of the &function parameter.

I find it counter-intuitive both that 'with xx' tacked on to the end
of an assignment statement should act +- like an lambda and even more
that the result should be fed back and up as an invisible arg in the
expression.  For someone not 'accustomed' to this by Ruby, it seems
rather weird.  I don't see any personal advantage over short lambdas
('func' would have been better) and defs, using 'f' as a default
fname.

...
> or, if we want to be explicit:
>
>  foobar = map(&thunk, list1, list2, list3) with x, y, z:
>         astatement
>         anotherstatement

One could intuitively expect the invisible arg calculated lexically
after the call to be the last rather than first.

> so that we know where the thunk is being fed to as an argument. But,
this
> would probably limit the number of blocks you could pass to a
function.
>
> Anyway, as I've said, these are just some fuzzy little notions I've
had in
> passing. I'm not advocating their inclusion in the language or
anything like
> that.  I just thought I'd mention them in case they're of some use,
even if
> they're just something to point to and say, "we definitely don't
want that".

That is currently my opinion ;-)

Terry J. Reedy