Re: brace placement - a possible solution

Agreed with all of that.

Just a thought on the named parameter passing...

On 4 Mar 2005, at 08:06, John Rose wrote:
> The grammar changes are probably simple:
>
>         LPAREN argList RPAREN
>    -    ( appendedBlock )?     // maybe append a closure
>    +    ( nls appendedBlock )?     // maybe append a closure
>
> The lookahead for an appended block becomes NLS? LCURLY, which is 
> LL(2).
>
> As a consequence of reaching across the newline, there could be a few 
> errors where blocks are unexpectedly appended.
> But I agree that, with the restrictions on free-floating left-braces, 
> this won't be so common as to ruin the language.
>
> The occasional accidentally-appended block will be a pitfall, though.
> If there's enough static typing, it will be caught at compile time, 
> but the worst case is run-time errors.
> Personally, I'd feel a little safer if some lint-like mode would warn 
> me if I put a NL before a left-brace, but that's just me.
>
> So, I like it on balance.
>
> There's one small wrinkle in this proposal I want to call out 
> explicitly.
> Some of use have spoken of the possibility of appending multiple 
> blocks with keywords:
> 	foo { bar } lock: {baz } unlock: {bat}
>
> This would be more or less equivalent to:
> 	foo( { bar }, lock: {baz }, unlock: {bat} )
>
> The right answer is possibly to close the door firmly on this future, 
> and rely on a slightly less groovy pattern:
> 	foo( lock: {baz }, unlock: {bat} ) { bar }

Agreed

> But, if we want to keep this possibility open, then the first 
> workaround for free-floating blocks isn't so robust anymore:
> 	foo
> 	{ bar }
> 	lock:
> 	{baz}
> 	unlock:
> 	{bat}
>
> The amended labeling workaround would have to be something a little 
> less obvious, like:
>
> 	foo
> 	; myblock: {
> 	  // free standing block
> 	}

Yes - though even if parens are not used, we can use commas to 
distinguish between named parameter passing and labelled free standing 
blocks.

e.g.

foo lock:{..},
unlock:{...}

would be parsed as

foo(lock:{...}, unlock:{...})

but

foo lock:{..}	// no comma
unlock:{...}

would be parsed as

foo(lock:{...});
if (true) {...}

> If we really love the keyworded appended blocks, I'm thinking we might 
> want a standard global function which takes an appended block and 
> executes it:
> 	def eval(Closure c) { c() }
> 	//...
> 	foo
> 	execute {
> 	  // free standing block
> 	}
>
> (Along these lines, note that Groovy can be completely specified in 
> terms of closed blocks only; the Java-compatible if/while/for syntaxes 
> can be regarded as manipulating closures.)

Agreed

James
-------
http://radio.weblogs.com/0112098/