From: Christophe Grandsire Date: 2005-10-13T17:40:33+09:00 Subject: Re: Default argument values for blocks Selon Phil Tomson : > > I think the other option is to pass on the whole idea of default > arguments to blocks for now if we can't get the nice lambda > {|foo='bar'| puts foo } sort of syntax to work. The idea could be > resurrected later when we have a better parser technology. Why open > the door for this arrow operator for this very special (and likely very > rarely used) case. > True. I'd rather have it like that too. But it seems a sizeable amount of people *want* default block argument values and aren't willing to wait until Ruby3. So if we *have* to have this new syntax, at least let's not use the arrow and let us find a better syntax. If at the end the whole idea is thrown away and Ruby2 doesn't support it, it won't be a problem anyway. I just want to secure the ground in the case the syntax finds its way into Ruby2. Better safe than sorry. > > 1.9 is a testing ground for ideas for Ruby2 (at least that's how I > understand it). I don't think that everything in 1.9 (as it currently > stands) will be exactly as it is in 2.0. > No, not their look and feel in any case. But for the case it would stay, let us work out a "least ugly" syntax. > > Sure that's true, however, it doesn't seem like a good idea to > introduce a whole new syntax to support a feature that seems to have > limited utility. Especially when the new syntax essentially introduces > a new and very different way to define blocks (a central feature of > Ruby). > I completely agree. But once again you argue at cross-purpose from me. I'd rather do without default block argument values until we find a parser that does "{ |foo=bar| ... }" correctly. But since the feature seems to be seen of enough importance to have found its way in Ruby 1.9 already, in a way that I find too ugly for words, I find it more productive to propose an alternative rather than just say that I don't want the feature at all. Once again, I'd prefer not have the new syntax at all, but if we are to have it at least have something that isn't too ugly. > > As I said above, I think that if we can't have the syntax that most > everyone agrees is the most pleasant and the one which causes the least > disruption ( {|foo='bar'| } ) in that it doesn't introduce a special > case then perhaps we should forgo the support for the feature until we > can get the syntax that fits best with the way things are done now. It's OK by me. But I was under the impression that this had been discussed already and that it was decided to use default block argument values anyway. > I'd just hate to see this '->' thingy introduced and in all the Ruby > books and then someone comes along and figures out how to parse the > pathological case: {|foo=a|b| } (something very hard and perhaps > impossible in yacc, but who knows what some yacc wizard might be able > to come up with?). Then what? do we deprecate '->'? Probably not, > because there will be code out in the wild that depends on it. At that > point we have to live with it. > Exactly! Hence my proposal for ":". At least we do *not* introduce a completely new symbol (Eric's proposal of "." is also good for this purpose). As for deprecating features, it can be done. I doubt after Ruby2 is out that the language will not evolve anymore to a point where compatibility-breaking changes won't have to be added (like they are at the moment for Ruby2). Deprecating features can be done then. We agree on many things. The only thing we disagree on is whether it is useful to discuss a new syntax we actually don't want to appear in the language. You say it's not, and we should just argue against the whole feature if we can't get it without a whole new syntax. I say it is, because the fact that there is a discussion means there *is* a chance that the new syntax will find its way into Ruby2, in which case I'd rather have it in a way I can live with rather than in a way that I cannot. -- Christophe Grandsire. http://rainbow.conlang.free.fr It takes a straight mind to create a twisted conlang.