Hi Daniel,
On 21.03.2018 01:33, Daniel Sun wrote:
Parrot is smart enough to distinguish closure and code block, so
`block` is not necessary.
Under http://groovy-lang.org/releasenotes/groovy-3.0.html it says:
"Be aware though that in Groovy having a code block looking structure
after any method call will be seen as an attempt to pass a closure as
the last parameter in the method call. This happens even after a new
line. So it’s safe to start an anonymous code block after any other
block (e.g. an if-then-else statement or another anonymous code block).
Anywhere else and you might need to terminate the previous statement
with a semicolon. In which case, see the note above about refactoring
your code! :-)"
If that is no longer true, it should be updated :-)
Apart from that, as I said, "block" would make the semantic explicit. I
always found nested code blocks inelegant/error prone, so in C++ I used
#define block if(false) {} else
BTW, new keywords may break existing code ;)
Yes, every new reserverd word / keword must be evaluated whether it is
worth introducing, also under this criteria.
As for `eval`, we can use `{ /* do something here */ }()` instead, e.g.
`{ 'abc' }()`
Yes, that is what I used to use. Now I am wrapping it in a statically
imported helper method, since the "()" at the end of the closure is
syntactically inelegant:
static def eval(finalClosure cls) { cls() }
eval { ... }
But this creates a Closure instance, so it is inefficient. If Groovy had
"inline closure" support, I would use that, but since it looks like this
is still a long way off (if it ever comes - it was shot down a few years
back when someone else created a ticket for it), I suggest this special
version of it.
Cheers,
mg
