Groov 3.0 - nested code blocks - block/eval

classic Classic list List threaded Threaded
5 messages Options
MG
Reply | Threaded
Open this post in threaded view
|

Groov 3.0 - nested code blocks - block/eval

MG
With regards to the Groovy 3.0 Release Notes
(http://groovy-lang.org/releasenotes/groovy-3.0.html) "Nested code
blocks" section:
What about in addition supporting two reserved keywords, "block" and
"eval", as follows:

void foo() {
   block {
     // Makes nested code block explicit (without it, the block could
e.g. have a missing if or else construct before it)
     // Avoids the need to use semicolon before nested code block to
distinguish code block from a closure
     // Otherwise no difference to Java nested code block
   }

   // equivalent to:
   if(true) { ... }


   final x = eval {
      // Nested code block whose final evaluated statement is its return
value
   }

   // semi-equivalent to:
    final x =  true ? (...;...;...) : null
}


The application for these constructs for me lie in cases where one needs
to create a scope with a local variables, but where one would need to
pass a large number of parameters to a helper method that coud be
introduced, or one would really have to try hard to come up with a
meaningful method name (implying that the functionality is too
small/specialized to be moved into a seperate method).

Thoughts ?
mg



Reply | Threaded
Open this post in threaded view
|

Re: Groov 3.0 - nested code blocks - block/eval

Daniel Sun
Hi mg,

     Parrot is smart enough to distinguish closure and code block, so
`block` is not necessary. BTW, new keywords may break existing code ;)

     As for `eval`, we can use `{ /* do something here */ }()` instead, e.g.
`{ 'abc' }()`

P.S. I am open to any proposal for grammar ;-)

Cheers,
Daniel.Sun



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html
MG
Reply | Threaded
Open this post in threaded view
|

Re: Groov 3.0 - nested code blocks - block/eval

MG
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




Reply | Threaded
Open this post in threaded view
|

Re: Groov 3.0 - nested code blocks - block/eval

Dierk König
I’m against breaking changes and changing core concepts for so little gain.

Groovy has (x) to make x an expression. We could make that lexically scoped.

Dierk

sent from:mobile

> Am 21.03.2018 um 01:53 schrieb MG <[hidden email]>:
>
> 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
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Unsubscribe

Atom
In reply to this post by MG


On Tue, Mar 20, 2018, 5:15 PM MG, <[hidden email]> wrote:
With regards to the Groovy 3.0 Release Notes
(http://groovy-lang.org/releasenotes/groovy-3.0.html) "Nested code
blocks" section:
What about in addition supporting two reserved keywords, "block" and
"eval", as follows:

void foo() {
   block {
     // Makes nested code block explicit (without it, the block could
e.g. have a missing if or else construct before it)
     // Avoids the need to use semicolon before nested code block to
distinguish code block from a closure
     // Otherwise no difference to Java nested code block
   }

   // equivalent to:
   if(true) { ... }


   final x = eval {
      // Nested code block whose final evaluated statement is its return
value
   }

   // semi-equivalent to:
    final x =  true ? (...;...;...) : null
}


The application for these constructs for me lie in cases where one needs
to create a scope with a local variables, but where one would need to
pass a large number of parameters to a helper method that coud be
introduced, or one would really have to try hard to come up with a
meaningful method name (implying that the functionality is too
small/specialized to be moved into a seperate method).

Thoughts ?
mg