You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Daniel Sun <re...@hotmail.com> on 2017/09/27 03:37:48 UTC

About if statement in the right hand of assignment statement

Hi all,

      I have been thinking about support some syntax like `def x = if (...)
{ ... } else if (...) { ... } else { ... }`, which will be translated to
`def x = { if (...) { ... } else if (...) { ... } else { ... } }()`

      Any thoughts?

Cheers,
Daniel.Sun



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: About if statement in the right hand of assignment statement

Posted by Daniel Sun <re...@hotmail.com>.
The new feature impacts the performance a lot. It will be only available in
groovy-parser project for the time being.



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: About if statement in the right hand of assignment statement

Posted by Bahman Movaqar <ba...@bahmanm.com>.
You have a valid point. Though from a user's point of view, I'd say using a
relatively quick but non-optimal implementation has the benefit of testing
it in action sooner and making sure it doesn't have side-effects or doesn't
introduce backward incompatibility.


On 5 October 2017 at 08:30, Paul King <pa...@asert.com.au> wrote:

> Nice - though I still wonder whether wrapping within ClosureExpression was
> the way to go.
>
> On the one hand, it makes it clear what return means if you added it in
> such a statement (provided you know it is wrapped that way). On the other,
> it means that normal if/then/else supports non-local returns but
> if/then/else within a declaration doesn't. This is possibly going to be a
> little confusing.
>
> I'd be keen to know what others think. I'm keen to keep the feature but
> wonder whether a slight implementation tweak is the way to go. In either
> case, we need to document it well.
>
> Cheers, Paul.
>
>
> On Thu, Oct 5, 2017 at 3:51 PM, Bahman Movaqar <ba...@bahmanm.com> wrote:
>
>> Beautiful!
>>
>>
>> On 5 Oct 2017 7:18 a.m., "Daniel Sun" <re...@hotmail.com> wrote:
>>
>> The new feature has been implemented, it will be available in 3.0.0 and
>> 2.6.0:
>>
>> https://github.com/apache/groovy/commit/35ae8e484020f2d11b2d
>> d9c7efa3740ee527fa70
>>
>>
>> Cheers,
>> Daniel.Sun
>>
>>
>>
>>
>> --
>> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>>
>>
>>
>

Re: About if statement in the right hand of assignment statement

Posted by Paul King <pa...@asert.com.au>.
Nice - though I still wonder whether wrapping within ClosureExpression was
the way to go.

On the one hand, it makes it clear what return means if you added it in
such a statement (provided you know it is wrapped that way). On the other,
it means that normal if/then/else supports non-local returns but
if/then/else within a declaration doesn't. This is possibly going to be a
little confusing.

I'd be keen to know what others think. I'm keen to keep the feature but
wonder whether a slight implementation tweak is the way to go. In either
case, we need to document it well.

Cheers, Paul.


On Thu, Oct 5, 2017 at 3:51 PM, Bahman Movaqar <ba...@bahmanm.com> wrote:

> Beautiful!
>
>
> On 5 Oct 2017 7:18 a.m., "Daniel Sun" <re...@hotmail.com> wrote:
>
> The new feature has been implemented, it will be available in 3.0.0 and
> 2.6.0:
>
> https://github.com/apache/groovy/commit/35ae8e484020f2d11b2d
> d9c7efa3740ee527fa70
>
>
> Cheers,
> Daniel.Sun
>
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>
>
>

Re: About if statement in the right hand of assignment statement

Posted by Bahman Movaqar <ba...@bahmanm.com>.
Beautiful!

On 5 Oct 2017 7:18 a.m., "Daniel Sun" <re...@hotmail.com> wrote:

The new feature has been implemented, it will be available in 3.0.0 and
2.6.0:

https://github.com/apache/groovy/commit/35ae8e484020f2d11b2dd9c7efa374
0ee527fa70


Cheers,
Daniel.Sun




--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: About if statement in the right hand of assignment statement

Posted by Daniel Sun <re...@hotmail.com>.
The new feature has been implemented, it will be available in 3.0.0 and
2.6.0:

https://github.com/apache/groovy/commit/35ae8e484020f2d11b2dd9c7efa3740ee527fa70


Cheers,
Daniel.Sun




--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: About if statement in the right hand of assignment statement

Posted by David Dawson <da...@simplicityitself.com>.
Hi Daniel,

I would suggest that there are existing edge cases that also look very
ugly. I could write

if ( x == "hello" ? [] : false) { }

and so on and get some very odd looking behaviour. Expression based flow
control has some fascinating use cases, and I think it would be of great
value to at the very least explore them, since this is being discussed.

This is actually something being floated for future Java too, this just
appeared in InfoQ -> https://www.infoq.com/news/
2017/09/pattern-matching-for-java

Pattern matching expressions are a core use case for this type of syntax.
They are proposing to do it somewhat differently, introducing a secondary
expression form. My ideal would be to have a single form, but meh, I'm not
aware of how this would end up being implemented and the implications of
that. What they describe in there though is one thing I would love to have
in groovy.

The full concept of pattern matching could be included in this discussion
too, if there is consensus at all, or perhaps . For a 3.0 feature, having a
full dynamic pattern matching expression syntax would be really, really
cool. Leapfrogging java, scala and the rest with something that, I at least
find so very useful and succinct and expressive.

Something like the following would be my ideal, combining pattern matching
and match-as-an-expression.  This is the same idea as a switch, but as an
expression.

def data = ...

def newval = match(data) {
   "simple": 54321
   "hello": 12345
   ~/stuff/: 9999                   // perhaps also destructure the regex
pattern?
   default: 0
}

It could be useful for Optionals or other container types to destructure
them a little too?  This is clunky, no idea how this could really look. The
aim is to pull out bits of the object during a match

Optional<String> opt = ...

def val = match(opt) {
   it.isPresent(): x:it.get():  x[0..2]
   !it.isPresent(): "nothing here
}

Anyway, I've gotten a little over excited I suspect. This kind of thing
would be awesome to have in Groovy.

Summarised

expression oriented control flow
pattern matching
destructuring during control flow + pattern matching

David.


On 27 September 2017 at 14:58, Daniel Sun <re...@hotmail.com> wrote:

> Hi David,
>
>       If we treat if/switch statements as real expression, we may have some
> ugly code like the following, so I just plan to support declaration and
> assignment.
>
> ```
>    if( if (...) { ... } else if (...) { ... } else if (...) {...} else
> {...}
> ) {
>       ...
>    } else if ( if (...) { ... } else if (...) { ... }  ) {
>       ...
>    }
> ```
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: About if statement in the right hand of assignment statement

Posted by Daniel Sun <re...@hotmail.com>.
Hi David,

      If we treat if/switch statements as real expression, we may have some
ugly code like the following, so I just plan to support declaration and
assignment.

```
   if( if (...) { ... } else if (...) { ... } else if (...) {...} else {...}
) {
      ...
   } else if ( if (...) { ... } else if (...) { ... }  ) {
      ...
   }
```

Cheers,
Daniel.Sun



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: About if statement in the right hand of assignment statement

Posted by David Dawson <da...@simplicityitself.com>.
I would very much appreciate this.  I've been doing a chunk of work in Rust
lately and it has the philosophy of "everything is an expression". It leads
to things like this

def val = if (something) {  "hello" } else { "other stuff" }

being very normal, which helps with a fair few constructs. Specifically in
rust it helps you manage safety blocks, which isn't an issue in Groovy per
se, but I can see that mapping over into DSLs pretty well.

My humble opinion would be that if you were to do it, then I would much
rather it be done "properly", is, having the if/ switch become expression
constructs rather than simple statements.

David.

On 27 September 2017 at 08:25, Jochen Theodorou <bl...@gmx.org> wrote:

>
>
> Am 27.09.2017 um 05:37 schrieb Daniel Sun:
>
>> Hi all,
>>
>>       I have been thinking about support some syntax like `def x = if
>> (...)
>> { ... } else if (...) { ... } else { ... }`, which will be translated to
>> `def x = { if (...) { ... } else if (...) { ... } else { ... } }()`
>>
>>       Any thoughts?
>>
>
> I wonder...
>
> def x = booleanCondition.
>>           iftrue {1}.
>>           elseif (anotherCondidition).
>>           iftrue {2}.
>>           elseif (yetAnotherCondition).
>>           iffalse {3}
>>
>
> would something like this be better ?
>
> bye Jochen
>
>
>

Re: About if statement in the right hand of assignment statement

Posted by Daniel Sun <re...@hotmail.com>.
Hi Jochen,

     I still like the original proposal... because it is much more flexible
and readable IMHO ;-)

Cheers,
Daniel.Sun



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: About if statement in the right hand of assignment statement

Posted by Jochen Theodorou <bl...@gmx.org>.

Am 27.09.2017 um 05:37 schrieb Daniel Sun:
> Hi all,
>
>       I have been thinking about support some syntax like `def x = if (...)
> { ... } else if (...) { ... } else { ... }`, which will be translated to
> `def x = { if (...) { ... } else if (...) { ... } else { ... } }()`
>
>       Any thoughts?

I wonder...

> def x = booleanCondition.
>           iftrue {1}.
>           elseif (anotherCondidition).
>           iftrue {2}.
>           elseif (yetAnotherCondition).
>           iffalse {3}

would something like this be better ?

bye Jochen



Re: About if statement in the right hand of assignment statement

Posted by Paul King <pa...@asert.com.au>.
My understanding is that the current implementation just adds returns at
the correct places to make it appear like an if statement at the end of a
method is a pseudo expression. So if you just move the whole if statement
into a private method and call that in the declaration statement,
everything else might come for free.

Cheers, Paul.

On Wed, Sep 27, 2017 at 10:30 PM, Daniel Sun <re...@hotmail.com>
wrote:

> Hi Paul,
>
>       I have not investigated the bytecode generation of if statement, so I
> just provide a reference implementation ;)
>
>       It's better to implement at the bytecode level(both static and
> dynamic).
>
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: About if statement in the right hand of assignment statement

Posted by Daniel Sun <re...@hotmail.com>.
Hi Paul,

      I have not investigated the bytecode generation of if statement, so I
just provide a reference implementation ;)

      It's better to implement at the bytecode level(both static and
dynamic).


Cheers,
Daniel.Sun



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: About if statement in the right hand of assignment statement

Posted by Paul King <pa...@asert.com.au>.
I'd be curious whether a much simpler implementation was possible - after
all, the if and switch statements are already treated as pseudo expressions
if they are the last statement in a method for instance.

On Wed, Sep 27, 2017 at 3:57 PM, Daniel Sun <re...@hotmail.com> wrote:

> Hi  Bahman,
>
>       Translating to a clsoure call is just one way to implement, the
> performance will be impacted a bit. We can change the implementation if we
> find performance issue ;-)
>       As to other statements, `switch` will be the next  lucky dog if most
> of developers like it.
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: About if statement in the right hand of assignment statement

Posted by Daniel Sun <re...@hotmail.com>.
Hi  Bahman,

      Translating to a clsoure call is just one way to implement, the
performance will be impacted a bit. We can change the implementation if we
find performance issue ;-)
      As to other statements, `switch` will be the next  lucky dog if most
of developers like it.

Cheers,
Daniel.Sun



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: About if statement in the right hand of assignment statement

Posted by Bahman Movaqar <ba...@bahmanm.com>.
Yay! It's one of the top items on my wish list :-)
IMHO it helps write cleaner and easier to read code --no ugly
intermediate variables set to `null`. It'd be great if we could have
the same approach for `for`, `while`, `switch`, `do` and `while`.

That being said, I'm curious: would translating it to a closure call
incur performance penalties?

--
Bahman


On Wed, Sep 27, 2017 at 5:37 AM, Daniel Sun <re...@hotmail.com> wrote:
> Hi all,
>
>       I have been thinking about support some syntax like `def x = if (...)
> { ... } else if (...) { ... } else { ... }`, which will be translated to
> `def x = { if (...) { ... } else if (...) { ... } else { ... } }()`
>
>       Any thoughts?
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html