Brian Sabbey wrote:
I made an example implementation, and this wasn't an issue. It took some code to stick the thunk into the argument list, but it was pretty straightforward.
What does your implementation do with something like f() + g(): ... ? (A syntax error, I would hope.) While no doubt it can be done, I still don't like the idea very much. It seems like a violation of modularity in the grammar, so to speak. The syntax effectively allowed for the expression is severely limited by the fact that a block follows it, which is a kind of backward effect that violates the predominantly LL-flavour of the rest of the syntax. There's a backward effect in the semantics, too -- you can't properly understand what the otherwise-normal-looking function call is doing without knowing what comes later. An analogy has been made with the insertion of "self" into the arguments of a method. But that is something quite different. In x.meth(y), the rules are being followed quite consistently: the result of x.meth is being called with y (and only y!) as an argument; the insertion of self happens later. But here, insertion of the thunk would occur *before* any call was made at all, with no clue from looking at the call itself.
Requiring arguments other than the block to be dealt with by currying can lead to problems. I won't claim these problems are serious, but they will be annoying.
You have some valid concerns there. You've given me something to think about. Here's another idea. Don't write the parameters in the form of a call at all; instead, do this: with_file "foo.txt", "w" as f: f.write("Spam!") This would have the benefit of making it look more like a control structure and less like a funny kind of call. I can see some problems with that, though. Juxtaposing two expressions doesn't really work, because the result can end up looking like a function call or indexing operation. I don't want to put a keyword in between because that would mess up how it reads. Nor do I want to put some arbitrary piece of punctuation in there. The best I can think of right now is with_file {"foo.txt", "w"} as f: f.write("Spam!")
If you google "filetype:rb yield", you can see many the uses of yield in ruby.
I'm sure that use cases can be found, but the pertinent question is whether a substantial number of those use cases from Ruby fall into the class of block-uses which aren't covered by other Python facilities. Also, I have a gut feeling that it's a bad idea to try to provide for this. I think the reason is this: We're trying to create something that feels like a user-defined control structure with a suite, and there's currently no concept in Python of a suite returning a value to be consumed by its containing control structure. It would be something new, and it would require some mental gymnastics to understand what it was doing. We already have "return" and "yield"; this would be a third similar-yet- different thing. If it were considered important enough, it could easily be added later, without disturbing anything. But I think it's best left out of an initial specification. -- Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg.ewing@canterbury.ac.nz +--------------------------------------+