As somebody who routinely works with Groovy ( ;-) ) I agree with all of
that.
Using e.g. |> instead of => seems to me a much better choice, for a
multitude of reasons.
While I personally do not have big need for such an operator, and am
generally a fan of using fluent method chaining (when I did e.g. program
in C# I always found that much clearer in 99% of cases than the LINQ
syntax - but opinions differ widely on this), for using Groovy as an
alternative to Unix shell scripts having a pipe operator could be useful...
On 25.02.2018 16:02, Jesper Steen Møller wrote:
Interesting proposal and discussion!
As somebody who routinely work in both Java, Groovy, TypeScript/ES6
and C#, I find this /syntactically/ too close too arrow
functions/lambdas, in other words, they may confuse a lot of readers.
As for the /semantic/ content: I realize that Groovy goes a long way
to support multiple paradigms, but I feel this is trying to cater to
the needs of concatenative / point-free style programming, in a
language and environment which doesn't really have the functional
compositionality to take advantage of it -- because Groovy is at its
heart object-oriented.
Your proposal is essentially the forward pipe operator |> for function
composition, as seen in a number of functional languages, like F# and
Elm (as "&" in Haskell). In those languages, it makes a lot of sense,
since the function is the primarily compositional building block. In
Groovy, it's the object, and many of the core features of Groovy (like
overloading, extension methods, AST transformations, closures) are
added to support those. In practice, I've seen very little Groovy code
which ends up being formulated as baz(bar(foo(x))) -- but I've seen a
lot of x.foo().bar().baz() instead. It's a better match, and Groovy
already has a great operator "." to make programs easy to read and type
-Jesper
On 25 Feb 2018, at 14.38, Daniel.Sun <[email protected]
<mailto:[email protected]>> wrote:
Hi all,
I propose to introduce Concatenative Method Calls to Groovy. It can
make code more readable, for example:
Currently we write method calls like:
y = foo(x)
z = bar(y)
w = baz(z)
OR
w = baz(bar(foo(x)))
Concatenative Method Calls(inspired by [1]):
w = x => foo => bar => baz
Any thoughts?
Cheers,
Daniel.Sun
[1] https://en.m.wikipedia.org/wiki/Concatenative_programming_language
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
