groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject Re: [GEP] Concatenative Method Calls
Date Sun, 25 Feb 2018 16:26:30 GMT
On 25.02.2018 14:38, Daniel.Sun 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

I think if we want to become a concatenative programming language, we 
should first try to allow tacit programming... I would not start with 
composition here. You start with how to actually reference a function in 
the first place. If you go with method references you can do some things:

this.&baz << this.&bar << this.&foo (x)

Or with a lambda style:

this::baz << this::bar << this::foo (x)

And you can even leave the (x) to get the composition. And you can do 
even something like

def barfoo = this::bar << this::foo
this::baz << barfoo (x)

In your variant I find it questionable if you can do without the "this". 
Otherwise you will have an overlap between local variables and methods.

So what I would like to see is 1-n more complex examples, that do not 
concentrate on one line only. It should contain a "reference" to method, 
that is no on "this"; it should show how the shadowing by a local 
variable is supposed to be handled (if any); and it show how arguments 
are handled, especially for different arities... After that we can talk 
about if that is really better readable.

I actually do think our method references need rework in how they are 
formed, because they are actually functionally incomplete, as can be 
easily seen in this example:

> class X {
>   private bar(){1}
>   def b = this.&bar
> }
> println new X().b()
> class Y extends X {}
> println new Y().b()

That's why I said I would prefer cleaning those elements up and make 
them actually working correctly before we go to composition in the next 
step and then talk maybe about a concatenative programming language and 
how much that clashes with command expressions ;)

bye Jochen


Mime
View raw message