Feature #13581
closedSyntax sugar for method reference
Description
Some another programming languages (even Java, in version 8) has a cool way to refer a method as a reference.
I wrote some examples here: https://gist.github.com/americodls/20981b2864d166eee8d231904303f24b
I miss this thing in ruby.
I would thinking if is possible some like this:
roots = [1, 4, 9].map &Math.method(:sqrt)
Could be like this:
roots = [1, 4, 9].map Math->method
What do you guys thinking about it?
Updated by Hanmac (Hans Mackowiak) over 7 years ago
that might collide with -> {}
a lambda syntax
so i think the chances are low that ruby gets something like that.
so ruby probably does think its "Math(->sqrt)
" and thats a Syntax error.
Updated by americodls (Americo Duarte) over 7 years ago
The ->
was just a suggestion... Could be another symbol or combination of symbols like Math->>sqrt
, Math=>>sqrt
, Math+>sqrt
, Math$>sqrt
, Math:>sqrt
, etc
I just think could have another way to write it than not a method calling with a symbol as argument, something more concise and expressive.
Hanmac (Hans Mackowiak) wrote:
that might collide with -> {} a lambda syntax
so i think the chances are low that ruby gets something like that.so ruby probably does think its "Math(->sqrt)" and thats a Syntax error.
Updated by Hanmac (Hans Mackowiak) over 7 years ago
my current thinking is if that short form should do symbol support.
if Math->sym
should be supported, than the normal variant need to be Math->:sqrt
i currently think if we also could abuse the call method.
so we could harness "Math.(:sqrt)
" into something.
Updated by americodls (Americo Duarte) over 7 years ago
Why the version with symbol (Math->:sqrt
) needs to be supported?
Updated by matz (Yukihiro Matsumoto) about 7 years ago
I am for adding syntax sugar for method reference. But I don't like proposed syntax (e.g. ->
).
Any other idea?
Matz.
Updated by nobu (Nobuyoshi Nakada) about 7 years ago
obj\.method
Updated by Hanmac (Hans Mackowiak) about 7 years ago
nobu (Nobuyoshi Nakada) wrote:
obj\.method
i am not sure about that:
obj\
.method
is already valid ruby code, so i am not sure
PS: when using "&obj.method(:symbol)
" should that be optimized if able?
Updated by zverok (Victor Shepelev) about 7 years ago
I am for adding syntax sugar for method reference. But I don't like proposed syntax (e.g. ->).
Any other idea?
In my pet projects, I often alias method
as m
. It is readable enough, short enough and easy to remember, once you've seen it:
roots = [1, 4, 9].map(&Math.m(:sqrt))
%w[foo bar baz].each(&m(:puts))
..., and, if introduced into language core, can be easily backported to earlier versions (through something like backports
or polyfill
gem).
Another weird-ish idea, following the first one closely, is .:
, which (for me) looks guessable:
[1,2,3].map(&Math.:sqrt)
%w[foo bar baz].each(&.:puts)
(BTW, object-less form should also be considered, when weighing proposals, don't you think?)
Updated by k0kubun (Takashi Kokubun) about 7 years ago
Another idea: &obj:method
It just puts receiver between &
and :
from existing one. I'm not sure it conflicts with existing syntax or not but I feel it's consistent with &:foo
syntax.
roots = [1, 4, 9].map(&Math:sqrt)
%w[foo bar baz].each(&self:puts)
Updated by Hanmac (Hans Mackowiak) about 7 years ago
k0kubun (Takashi Kokubun) wrote:
Another idea:
&obj:method
hm i like that idea, but think that might be a bit conflicting, that depends on if obj is an object or not?
obj = Object.new
obj:method #=> syntax error
but notice that: (xyz not known)
xyz:method #=> undefined method 'xyz' for main
it thinks that it's xyz(:method)
Updated by k0kubun (Takashi Kokubun) about 7 years ago
Oh, I'm so sad to hear obj:method
(without &
) is already valid. I still have hope to have it only when it's put with &
in the last of arguments because that case is not valid for now.
irb(main):001:0> def obj(method); method; end
=> :obj
irb(main):002:0> obj:method
=> :method
irb(main):003:0> obj(&obj:method)
SyntaxError: (irb):3: syntax error, unexpected tSYMBEG, expecting keyword_do or '{' or '('
obj(&obj:method)
^
from /home/k0kubun/.rbenv/versions/2.4.1/bin/irb:11:in `<main>'
irb(main):004:0> obj(&(obj:method))
SyntaxError: (irb):4: syntax error, unexpected tLABEL
obj(&(obj:method))
^
from /home/k0kubun/.rbenv/versions/2.4.1/bin/irb:11:in `<main>'
irb(main):005:0> obj &obj:method
SyntaxError: (irb):5: syntax error, unexpected tSYMBEG, expecting keyword_do or '{' or '('
obj &obj:method
^
from /home/k0kubun/.rbenv/versions/2.4.1/bin/irb:11:in `<main>'
irb(main):006:0> obj &(obj:method)
SyntaxError: (irb):6: syntax error, unexpected tLABEL
obj &(obj:method)
^
from /home/k0kubun/.rbenv/versions/2.4.1/bin/irb:11:in `<main>'
I've never seen a person who writes a(:b)
as a:b
(without space or parenthesis before ":
") and personally I don't expect &a:b
to be &a(:b)
.
Updated by nobu (Nobuyoshi Nakada) about 7 years ago
Hanmac (Hans Mackowiak) wrote:
i am not sure about that:
obj\ .method
is already valid ruby code, so i am not sure
It's different at all.
My example is a token \.
, do not split.
PS: when using "&obj.method(:symbol)" should that be optimized if able?
Probably, but it's not possible to guarantee that it will return the method object.
Updated by nobu (Nobuyoshi Nakada) about 7 years ago
k0kubun (Takashi Kokubun) wrote:
Another idea:
&obj:method
Consider more complex example, &(obj.some.method(args)):method
, not only a simple reciever.
&
and :
are separated too far.
Updated by Hanmac (Hans Mackowiak) about 7 years ago
my idea for optimising &obj.method(:symbol)
is that it already creates a proc (object) without going over a Method
object,
i don't know if that would be an good idea for that.
Updated by mrkn (Kenta Murata) about 7 years ago
How about obj.{method_name}
for the syntax sugar of obj.method(:method_name)
?
Updated by zverok (Victor Shepelev) about 7 years ago
Another pretty unholy idea: resemble the way Ruby docs document the methods:
[1,2,3].map(&Math#sqrt)
%w[foo bar baz].each(&#puts)
Yes, it conflicts with comment syntax, but in fact, no sane person should join the comment sign immediately after non-space symbol.
And we already have parsing ambiguities like this:
-
foo -bar
→foo(-bar)
; -
foo - bar
→foo.-(bar)
.
Updated by tom_dalling (Tom Dalling) about 7 years ago
What about triple colon :::
?
[1,2,3].map(&Math:::sqrt)
[1,2,3].each(&:::puts)
::
is for looking up constants, so it kind of makes sense that :::
is for looking up methods.
Updated by tom-lord (Tom Lord) about 7 years ago
Consider the following:
def get_method(sym, object = Object)
object.send(:method, sym)
end
This allows us to write code like:
[1, 4, 9].map &get_method(:sqrt, Math)
So as an idea, how about introducing some syntax sugar for the above - such as:
[1, 4, 9].map &~>(:sqrt, Math)
Where in general, ~>
(or whatever) could be the "method lookup operator".
For example, this would yield:
~>(:puts) # => #<Method: Class(Kernel)#puts>
~>(:sqrt, Math) # => #<Method: Math.sqrt>
~>(:sqrt) # => NameError: undefined method `sqrt' for class `#<Class:Object>'
Updated by k0kubun (Takashi Kokubun) about 7 years ago
- Is duplicate of Feature #12125: Proposal: Shorthand operator for Object#method added
Updated by americodls (Americo Duarte) about 7 years ago
matz (Yukihiro Matsumoto) wrote:
I am for adding syntax sugar for method reference. But I don't like proposed syntax (e.g.
->
).
Any other idea?Matz.
What do you think about: Kernel:puts
, Kernel~>puts
, Kernel:>puts
?
Updated by zverok (Victor Shepelev) almost 7 years ago
Just to push this forward, here are all the syntaxes from this and duplicate #12125.
I am taking Math.sqrt
and puts
as examples:
-
map(&Math->sqrt)
(and justeach(&->puts)
probably?) -- Matz is explicitly against it; -
map(&Math\.sqrt)
(not sure about puts); -
map(&Math.m(:sqrt))
,each(&m(:puts))
(just shortening, no language syntax change) -
map(&Math.:sqrt)
,each(&.:puts)
-
map(&Math:sqrt)
,each(&self:puts)
-
map(&Math#sqrt)
,each(&#puts)
(it was my proposal, "just how it looks in docs", but I should reconsider: in docs it isMath::sqrt
, in fact) -
map(&Math:::sqrt)
,each(&:::puts)
-
map(&~>(:sqrt, Math)
),each(&~>(:puts))
-
several by @Papierkorb (Stefan Merettig):
-
map(&Math.>sqrt)
,each(&.>puts)
(@nobu (Nobuyoshi Nakada): conflicts with existing syntax) -
map(&Math<sqrt>)
,each(&<puts>)
(@nobu (Nobuyoshi Nakada): conflicts with existing syntax) -
map(&Math&>sqrt)
,each(&&>puts)
-
map(&Math|>sqrt)
,each(&|>puts)
(too confusable with Elixir-like pipe, probably)
-
Can please please somebody lift this question to next Developer Meeting and make an Executive Decision?..
I personally really like .:
(called "tetris operator" in other ticket).
Updated by dsferreira (Daniel Ferreira) almost 7 years ago
zverok (Victor Shepelev) wrote:
map(&Math|>sqrt), each(&|>puts) (too confusable with Elixir-like pipe, probably)
I tend to agree with that.
In fact I was hoping to get the pipe operator introduced in ruby. (Created an issue with that in mind: https://bugs.ruby-lang.org/issues/14392).
Taking that pipe operator example as an operator that sends messages maybe we can use it to send a message to the class or module. Like this:
:sqrt |> Math
Since Math
is not a method the message would extract the method from the object.
If this is not practical maybe we could invert the operator and do:
Math <| :sqrt
Updated by nobu (Nobuyoshi Nakada) almost 7 years ago
zverok (Victor Shepelev) wrote:
map(&Math.>sqrt)
,each(&.>puts)
This conflicts with existing syntax.
map(&Math&>sqrt)
,each(&&>puts)
(@nobu (Nobuyoshi Nakada): conflicts with existing syntax)
Not this.
Updated by zverok (Victor Shepelev) almost 7 years ago
@nobu (Nobuyoshi Nakada) Thanks, I've updated the list.
Can you please add it to next Developer Meeting's agenda?..
Updated by mpapis (Michal Papis) almost 7 years ago
Not sure it's worth it - but while we are at this thinking of a shorthand one of the proposals &Math&>sqrt
made me think if it could be automated and all the iterators could recognize methods and we could avoid the initial &
to this map(Math...)
- skipped the operator as it's not clear what's preferred.
My two cents to the operator - what about !
and @
would they conflict? (yes for the Kernel, not sure about Class'es).
Updated by nobu (Nobuyoshi Nakada) almost 7 years ago
mpapis (Michal Papis) wrote:
Not sure it's worth it - but while we are at this thinking of a shorthand one of the proposals
&Math&>sqrt
made me think if it could be automated and all the iterators could recognize methods and we could avoid the initial&
to thismap(Math...)
- skipped the operator as it's not clear what's preferred.
It can't distinguish passing block and passing Method
object.
My two cents to the operator - what about
!
and@
would they conflict? (yes for the Kernel, not sure about Class'es).
Math!sqrt
and Math@sqrt
?
They are valid syntax now.
You can try with ruby -c
.
$ ruby -wc -e 'Math!sqrt'
Syntax OK
$ ruby -wc -e 'Math@sqrt'
Syntax OK
They are interpreted as a method call without a receiver, Math(!sqrt)
and Math(@sqrt)
respectively.
Updated by duerst (Martin Dürst) almost 7 years ago
nobu (Nobuyoshi Nakada) wrote:
$ ruby -wc -e 'Math!sqrt' Syntax OK $ ruby -wc -e 'Math@sqrt' Syntax OK
They are interpreted as a method call without a receiver,
Math(!sqrt)
andMath(@sqrt)
respectively.
This may be just me, but I think this kind of syntax without spaces could (or even should) be depreciated.
That doesn't mean that for the purpose of this issue, I like !
or @
. But they might be usable for other purposes.
Updated by nobu (Nobuyoshi Nakada) almost 7 years ago
duerst (Martin Dürst) wrote:
This may be just me, but I think this kind of syntax without spaces could (or even should) be depreciated.
It would hurt code-golfers and quine-makers. :)
Updated by Hanmac (Hans Mackowiak) almost 7 years ago
Question for @nobu (Nobuyoshi Nakada) :
i don't know about the rubyVM but can xyz(&method(:symbol))
or xyz(&obj.method(:symbol))
be optimized like xyz(&:symbol)
is?
the one with the Symbol was optimized to not create a Proc object if not needed.
can be something similar with the Method object? or if not overwritten maybe not even creating a Method object at all?
Updated by nobu (Nobuyoshi Nakada) almost 7 years ago
Hanmac (Hans Mackowiak) wrote:
i don't know about the rubyVM but can
xyz(&method(:symbol))
orxyz(&obj.method(:symbol))
be optimized likexyz(&:symbol)
is?
They have different meanings all.
xyz(&method(:symbol))
== xyz {|x| symbol(x)}
xyz(&obj.method(:symbol))
== xyz {|x| obj.symbol(x)}
xyz(&:symbol)
== xyz {|x| x.symbol}
Updated by Hanmac (Hans Mackowiak) almost 7 years ago
nobu (Nobuyoshi Nakada) wrote:
Hanmac (Hans Mackowiak) wrote:
i don't know about the rubyVM but can
xyz(&method(:symbol))
orxyz(&obj.method(:symbol))
be optimized likexyz(&:symbol)
is?They have different meanings all.
xyz(&method(:symbol))
==xyz {|x| symbol(x)}
xyz(&obj.method(:symbol))
==xyz {|x| obj.symbol(x)}
xyz(&:symbol)
==xyz {|x| x.symbol}
i know they are different meanings,
i was just wondering if they can be optimized for the VM too, to make them run faster if able
like with not creating extra ruby objects if not needed
Updated by nobu (Nobuyoshi Nakada) almost 7 years ago
Hanmac (Hans Mackowiak) wrote:
i know they are different meanings,
Sorry, misread.
i was just wondering if they can be optimized for the VM too, to make them run faster if able
like with not creating extra ruby objects if not needed
Once a Method
as the result of &
to passing a block is allowed, optimization of calling a Method
object might be possible by adding a new block handler type for methods.
No "extra ruby objects" would be the next step.
Updated by landongrindheim (Landon Grindheim) over 6 years ago
map(&Math->sqrt)
(and justeach(&->puts)
probably?) -- Matz is explicitly against it;
Is map(&Math.&(:sqrt)
viable? Perhaps it would be confused with the safe navigation operator.
Updated by jeremyevans0 (Jeremy Evans) over 6 years ago
landongrindheim (Landon Grindheim) wrote:
Is
map(&Math.&(:sqrt)
viable? Perhaps it would be confused with the safe navigation operator.
No. It would break backward compatibility, as that is currently interpreted as:
Math.&(:sqrt).to_proc
That code currently works if you do:
def Math.&(x) proc{|a| a} end
Updated by sevos (Artur Roszczyk) over 6 years ago
Have we ruled out map(&obj:method)
syntax? Intuitively I find it consistent with Symbol#to_proc
class Foo
def initialize(array)
@array = array
end
def call
@array
.map(&Math:sqrt)
.map(&self:magic)
.map(&self:boo(2.0))
.map(&:ceil)
.each(&Kernel:puts)
end
private
def magic(x)
x ** 3
end
def boo(a, b)
a / b
end
end
Alternatively, I am for triple colon:
class Foo
def initialize(array)
@array = array
end
def call
@array
.map(&Math:::sqrt)
.map(&self:::magic)
.map(&:::boo(2.0)) # with triple colon we could omit self
.map(&:ceil)
.each(&Kernel:::puts)
end
private
def magic(x)
x ** 3
end
def boo(a, b)
a / b
end
end
This could translate to:
class Foo
def initialize(array)
@array = array
end
def call
@array
.map { |x| Math.public_send(:sqrt, x) }
.map { |x| self.send(:magic, x) }
.map { |x| self.send(:boo, x, 2.0) }
.map { |x| x.ceil }
.each { |x| Kernel.public_send(:puts, x) }
end
private
def magic(x)
x ** 3
end
def boo(a, b)
a / b
end
end
Applying additional arguments (aka .map(&self:boo(2.0))
is just a proposal - I am not sure if this should be even possible - Symbol#to_proc
does not allow that.
Another interesting question which we need to answer is:
What visibility scope should be used when making a method call?
Given the syntax receiver:method
or receiver:::method
if the receiver is self
then we should expand this syntax sugar to send()
allowing accessing the private interface of the current object (which is not the item from the iterator - we would use symbol to proc in that case). However, if the receiver is something else, we should expand to public_send
to disallow accessing private methods of other objects.
Just my two cents ;)
Cheers,
Artur
Updated by nobu (Nobuyoshi Nakada) over 6 years ago
Note that &:
isn't a single operator, but combination of &
prefix + a part of :symbol
.
So it should be valid syntax solely without &
.
Updated by sevos (Artur Roszczyk) over 6 years ago
After a while I am becoming a bigger fan of the triple colon operator. We could implement a class MethodSelector for handling the logic and the operator would be expected to return an instance of the class:
class MethodSelector
def initialize(b, receiver, m)
@binding = b
@receiver = receiver
@method = m
end
def call(*args, **kwargs, &block)
# ...
end
def to_proc
if @binding.eval("self") == @receiver
proc do |*args, **kwargs, &block|
if kwargs.empty?
@receiver.send(@method, *args, &block)
else
@receiver.send(@method, *args, **kwargs, &block)
end
end
else
proc do |*args, **kwargs, &block|
if kwargs.empty?
@receiver.public_send(@method, *args, &block)
else
@receiver.public_send(@method, *args, **kwargs, &block)
end
end
end
end
end
# Instead of MS() method we should implement ::: operator (taking two argiments):
# receiver:::method expands to MS(binding, receiver, method)
class Object
def MS(b, receiver, m)
MethodSelector.new(b, receiver, m)
end
end
# Example usage
> MS(binding, Kernel, :puts) # the triple colon operator should expand current binding by default
=> #<MethodSelector:0x007fdba89bd0a8 @binding=#<Binding:0x007fdba89bd0d0>, @receiver=Kernel, @method=:puts>
> [1,2,3].each(&MS(binding, Kernel, :puts))
1
2
3
=> nil
There is still the question how to enable meta-programming with triple colon operator.
Imagine the situation when the method name is dynamic. How to distinguish it from the symbol?
method = :puts
Kernel:::puts
Kernel:::method
The only logical solution to me is the presence of the fourth colon for the symbol:
method = :puts
Kernel::::puts # evaluates as Kernel:::(:puts)
Kernel:::method # evaluates as Kernel:::(method)
What are your thoughts?
Updated by phluid61 (Matthew Kerwin) over 6 years ago
sevos (Artur Roszczyk) wrote:
What are your thoughts?
I have two:
-
As always: do we really need more magic symbols? I like reading Ruby because it's not Perl.
-
If you're adding new syntax, you don't have to be clever. Symbol has
:"#{x}"
so why not proposey:::"#{x}"
? Not that it adds much overy.method(x)
Updated by sevos (Artur Roszczyk) over 6 years ago
phluid61 (Matthew Kerwin) wrote:
sevos (Artur Roszczyk) wrote:
What are your thoughts?
I have two:
- As always: do we really need more magic symbols? I like reading Ruby because it's not Perl.
I totally agree, but we still like -> {} syntax for lambdas, right? Let's play with ideas, maybe we can find something nice for a method selector, too ;)
- If you're adding new syntax, you don't have to be clever. Symbol has
:"#{x}"
so why not proposey:::"#{x}"
? Not that it adds much overy.method(x)
You're totally right! I was looking at triple-colon as an operator taking two arguments. Your idea of looking at this as a double-colon lookup operator is actually great, look:
irb(main):006:0> a :: :to_s
SyntaxError: (irb):6: syntax error, unexpected tSYMBEG, expecting '('
a :: :to_s
^
from /Users/sevos/.rbenv/versions/2.4.0/bin/irb:11:in `<main>'
irb(main):007:0> Kernel :: :t
SyntaxError: (irb):7: syntax error, unexpected tSYMBEG, expecting tCONSTANT
A :: :t
^
from /Users/sevos/.rbenv/versions/2.4.0/bin/irb:11:in `<main>'
We already have a lookup operator which takes object, constant on the left side and method name or constand on the right side.
Maybe it would be possible to support symbols on the right side and expand them to method(:symbol)
call?
I would like just to emphasise again the need of respecting the method-to-be-called visibility depending on the current binding.
Updated by phluid61 (Matthew Kerwin) over 6 years ago
sevos (Artur Roszczyk) wrote:
phluid61 (Matthew Kerwin) wrote:
sevos (Artur Roszczyk) wrote:
What are your thoughts?
I have two:
- As always: do we really need more magic symbols? I like reading Ruby because it's not Perl.
I totally agree, but we still like -> {} syntax for lambdas, right? Let's play with ideas, maybe we can find something nice for a method selector, too ;)
Personally I hate it, and never use it. I like my code to say lambda
when I make a Lambda, and (more often) proc
when I make a Proc.
- If you're adding new syntax, you don't have to be clever. Symbol has
:"#{x}"
so why not proposey:::"#{x}"
? Not that it adds much overy.method(x)
You're totally right! I was looking at triple-colon as an operator taking two arguments. Your idea of looking at this as a double-colon lookup operator is actually great, [...]
Actually I was just suggesting a simple token, like obj:::foo
or obj.:foo
; if you really want to accept variable method names why not obj:::"#{x}"
or obj.:"#{x}"
?
Although I doubt I'd ever use it.
(Personally I find the idea of partially applied methods more useful.)
Cheers
Updated by cben (Beni Cherniavsky-Paskin) over 6 years ago
A non-syntax idea: could Math.method.sqrt
look significantly nicer than Math.method(:sqrt)
?
That is, .method without args would return a magic object that for any message returns the bound method of that name.
[1, 4, 9].map(&Math.method.sqrt).each(&method.puts)
[1, 4, 9].map(&Math.method(:sqrt)).each(&method(:puts))
[1, 4, 9].map{|*a| Math.sqrt(*a)}.each{|*a| puts(*a)}
Naive implementation (some names don't work, eg. Math.method.method_missing
, and doesn't take visibility and refinements into account):
class Methods < BasicObject
def initialize(obj)
@obj = obj
end
def method_missing(name)
@obj.method(name)
end
def responds_to_missing?(name)
true
end
end
module MethodWithoutArgs
def method(*args)
if args.empty?
Methods.new(self)
else
super
end
end
end
Object.prepend(MethodWithoutArgs)
[14] pry(main)> [1, 4, 9].map(&Math.method.sqrt).each(&method.puts)
1.0
2.0
3.0
=> [1.0, 2.0, 3.0]
BTW, what about refinements? Is .method(:foo) ignorant about them? A benefit of a real syntax might be that it could "see" methods from lexically active refinements.
As for syntax, I'm wondering if something postfix might work. The reason I say this is I'm thinking of both &: and this as shorthands for writing out a block.
&:
can be read locally, it roughly "stands for" |x| x.
:
[1, 2, 3].map{|x| x.to_s}
[1, 2, 3].map(&:to_s)
And with a bound method, we want to elide the argument declaration, plus the call that comes after the receiver.message:
[1, 4, 9].map{|*a| Math.sqrt(*a)}.each{|*a| puts(*a)}
[1, 4, 9].map(&Math.sqrt:).each(&puts:) # half baked idea
[1, 4, 9].map(Math.sqrt&).each(puts&) # quarter baked
OK, actually there is a more generic feature I'd love much more than a syntax for bound methods: implicit notation for block arg:
[1, 2, 3].map{|x| x.to_s}
[1, 2, 3].map{_.to_s}
[1, 4, 9].map{|x| Math.sqrt(x)}.each{|x| puts(x)}
[1, 4, 9].map{Math.sqrt(_)}.each{puts(_)}
[1, 2, 3].map{|x| 1/x}
[1, 2, 3].map{1/_}
(I don't think _
is possible, just an example)
The part I love most about this is that {}
does not become (&...)
!
This doesn't easily handle multiple args, like bound methods do, but I think one arg is sweet spot for such shorthand anyway.
- I've tried prototyping this once by defining
Kernel._
that would look in caller frame, but didn't find any way to access arg in a block that didn't declare any |args|.
Updated by sevos (Artur Roszczyk) over 6 years ago
cben (Beni Cherniavsky-Paskin) wrote:
A non-syntax idea: could
Math.method.sqrt
look significantly nicer thanMath.method(:sqrt)
?
That is, .method without args would return a magic object that for any message returns the bound method of that name.
Hey Beni! Thank you! This is a great idea! For my taste it looks significantly better!
Also, I took the liberty of implementing a prototype gem and I've added my two cents:
- method visibility check
- arguments currying
You can check it out on Github
Updated by pvande (Pieter van de Bruggen) over 6 years ago
As a blue sky alternative, why not consider something like this:
[1, 2, 3].map(&> {Math.sqrt})
# or perhaps more simply
[1, 2, 3].map(&> Math.sqrt)
Pros:
- It's clean
- It's readable
- It reads like passing a block
- Specifically, passing a lambda as a block
- It also reads something like the Elixir pipe operator
Cons:
- It's only looks like Ruby code
- Is
x.map(&> { a.b.c.d ; Math.sqrt })
valid? (I hope not.) - Is
x.map(&> do; Math.sqrt; end)
valid? (I hope not.) - Is
x.map(&> { begin; rescue; end })
valid? (I hope not.) - Is
x.map(&> { Math.sqrt if x })
valid? (I hope not.) - Is
x.map(&> { Math.sqrt rescue nil })
valid? (I hope not.)
- Is
- It's not actually a shorthand for
Object#method
.- The two clearest implementation paths are as a "macro", and as an "atypical evaluation context"
- The macro approach simply transforms the code into a "proper" block, and passes the argument implicitly (see below for an example)
- The other approach requires the interpreter to all non-terminal method calls, then produce a block invoking the terminal call with the yielded argument (see below for an example)
- The two clearest implementation paths are as a "macro", and as an "atypical evaluation context"
Despite the "oddness" of this particular syntax, I think the clarity of expression is very much inline with the Ruby ideals, and is therefore worth discussing.
Macro Example
fn(&> { a.b.c.d })
# => fn() { |__x| a.b.c.d(__x) })
Atypical Evaluation Example
fn(&> { a.b.c.d })
# => __target = a.b.c; fn() { |__x| __target.d(__x) })
Updated by baweaver (Brandon Weaver) over 6 years ago
sevos (Artur Roszczyk) wrote:
After a while I am becoming a bigger fan of the triple colon operator. We could implement a class MethodSelector for handling the logic and the operator would be expected to return an instance of the class:
class MethodSelector def initialize(b, receiver, m) @binding = b @receiver = receiver @method = m end def call(*args, **kwargs, &block) # ... end def to_proc if @binding.eval("self") == @receiver proc do |*args, **kwargs, &block| if kwargs.empty? @receiver.send(@method, *args, &block) else @receiver.send(@method, *args, **kwargs, &block) end end else proc do |*args, **kwargs, &block| if kwargs.empty? @receiver.public_send(@method, *args, &block) else @receiver.public_send(@method, *args, **kwargs, &block) end end end end end # Instead of MS() method we should implement ::: operator (taking two argiments): # receiver:::method expands to MS(binding, receiver, method) class Object def MS(b, receiver, m) MethodSelector.new(b, receiver, m) end end # Example usage > MS(binding, Kernel, :puts) # the triple colon operator should expand current binding by default => #<MethodSelector:0x007fdba89bd0a8 @binding=#<Binding:0x007fdba89bd0d0>, @receiver=Kernel, @method=:puts> > [1,2,3].each(&MS(binding, Kernel, :puts)) 1 2 3 => nil
There is still the question how to enable meta-programming with triple colon operator.
Imagine the situation when the method name is dynamic. How to distinguish it from the symbol?method = :puts Kernel:::puts Kernel:::method
The only logical solution to me is the presence of the fourth colon for the symbol:
method = :puts Kernel::::puts # evaluates as Kernel:::(:puts) Kernel:::method # evaluates as Kernel:::(method)
What are your thoughts?
I like the idea of triple-colon as well for succinctness.
Most of the alternative in terms of succinctness would involve discussing the no-parens syntax which is likely a non-starter for obvious compatibility reasons.
That is, unless there's a way to stop paren-free method calling in the presence of an &
or to_proc
:
[1,2,3].map(&Math.sqrt)
Math.sqrt.to_proc
...but that feels like an excess of black magic in the parser and would likely be prone to bugs.
I really do like what Scala does with underscores:
[1,2,3].map(_ * 10)
...but I also understand that that would also be hugely breaking in terms of syntax as well.
Really though I think given what Ruby already does the triple-colon is the cleanest route for now.
Updated by matz (Yukihiro Matsumoto) over 6 years ago
Out of ruby-core:85038 candidates, .:
looks best to me (followed by :::
).
Let me consider it for a while.
Matz.
Updated by cben (Beni Cherniavsky-Paskin) over 6 years ago
Matz, could you give your thoughts on obj::method (with lowercase on right side) syntax?
AFAICT it's synonym to obj.method?
Does anybody use :: for method calls in practice?
I understand breaking compatibility can't be justified here, but I'm just curious — do you see this syntax as a feature to be preserved, or something to be avoided that might be (slowly) deprecated one day?
Updated by ianks (Ian Ker-Seymer) almost 6 years ago
matz (Yukihiro Matsumoto) wrote:
Out of ruby-core:85038 candidates,
.:
looks best to me (followed by:::
).
Let me consider it for a while.Matz.
Would love to see see either one implemented at this point. Not having an ergonomic way for functional composition is a pain.
My dream:
slug = title
.then(&:strip)
.then(&:downcase)
.then(I18n:::transliterate)
.then(Utils:::hyphenate)
.then(Validations:::check_length)
.tap(PostLogger:::info)
Updated by zverok (Victor Shepelev) almost 6 years ago
@nobu (Nobuyoshi Nakada) Awesome!
Am I correct that receiver-less call, like something.map(&.:puts)
, will be impossible?
Is it a voluntary design decision, or limitation of what can be parsed?
Updated by shevegen (Robert A. Heiler) almost 6 years ago
I think .:
is better than :::
but it is not very pretty either. I have
no better suggestion, though. Good syntax is not easy to use. :(
I agree with the functionality by the way.
Updated by nobu (Nobuyoshi Nakada) almost 6 years ago
zverok (Victor Shepelev) wrote:
Am I correct that receiver-less call, like
something.map(&.:puts)
, will be impossible?
To allow that, .:puts
should be a sole expression by itself.
However ruby has the line continuation for “fluent interface” (like https://bugs.ruby-lang.org/issues/13581#change-74822), for a decade.
If .:
will be introduced, I think it should obey that syntax too, and allowing it without the receiver feels confusing.
Is it a voluntary design decision, or limitation of what can be parsed?
It is easy to add a receiver-less syntax.
https://github.com/ruby/ruby/commit/2307713962c3610f4e034e328af37b19be5c7c45
Updated by zverok (Victor Shepelev) almost 6 years ago
If
.:
will be introduced, I think it should obey that syntax too, and allowing it without the receiver feels confusing.
Can you please show some example of confusing statements? I can't think of any from the top of my head, it seems that (if the parser can handle it), the context for .:something
and .something
is always clearly different.
I am concerned about receiver-less version because in our current codebase we found this idiom to be particularly useful:
# in a large data-processing class
some_input
.compact
.map(&method(:process_item)) # it is private method of current class
.reject(&method(:spoiled?))
.tap(&method(:pp)) # temp debugging statement
.group_by(&method(:grouping_criterion))
.yield_self(&method(:postprocess))
# which I'd be really happy to see as
some_input
.compact
.map(&.:process_item)
.reject(&.:spoiled?)
.tap(&.:pp)
.group_by(&.:grouping_criterion)
.then(&.:postprocess)
Having to explicitly state map(&self.:process_item)
is much less desirable.
Updated by AlexWayfer (Alexander Popov) almost 6 years ago
zverok (Victor Shepelev) wrote:
If
.:
will be introduced, I think it should obey that syntax too, and allowing it without the receiver feels confusing.Can you please show some example of confusing statements? I can't think of any from the top of my head, it seems that (if the parser can handle it), the context for
.:something
and.something
is always clearly different.I am concerned about receiver-less version because in our current codebase we found this idiom to be particularly useful:
# in a large data-processing class some_input .compact .map(&method(:process_item)) # it is private method of current class .reject(&method(:spoiled?)) .tap(&method(:pp)) # temp debugging statement .group_by(&method(:grouping_criterion)) .yield_self(&method(:postprocess)) # which I'd be really happy to see as some_input .compact .map(&.:process_item) .reject(&.:spoiled?) .tap(&.:pp) .group_by(&.:grouping_criterion) .then(&.:postprocess)
Having to explicitly state
map(&self.:process_item)
is much less desirable.
Just an opinion:
processed =
some_input
.compact
.map { |element| ProcessingItem.new(element) } # or `.map(&ProcessingItem.method(:new))`
.reject(&:spoiled?)
.each(&:pp) # temp debugging statement
.group_by(&:grouping_criterion)
postprocess processed
Or you can even use ProcessingItems
collection class. With itself state and behavior. Instead of bunch of private methods in a processing class with the same (collection) argument.
Updated by zverok (Victor Shepelev) almost 6 years ago
Just an opinion
It is funny how when you show some imaginary code, quick-written just to illustrate the point of a language feature, people tend to discuss this code's design approaches instead.
Yes, obviously, in the situation like "several consecutive, algorithmically complex methods working on the same collection" it is typically wise to just wrap collection items. But that has absolutely nothing to do with the point of my example.
Updated by AlexWayfer (Alexander Popov) almost 6 years ago
zverok (Victor Shepelev) wrote:
Just an opinion
It is funny how when you show some imaginary code, quick-written just to illustrate the point of a language feature, people tend to discuss this code's design approaches instead.
Yes, obviously, in the situation like "several consecutive, algorithmically complex methods working on the same collection" it is typically wise to just wrap collection items. But that has absolutely nothing to do with the point of my example.
I just try to use good (existing) sides of a language. Ruby already has nice Symbol#to_proc
syntax. And yes, different "syntax sugars" allow to use different design approaches (classes vs functions, for example). But sometimes they also allow to create bad practices. I'm not sure, and I'm not against syntax sugar, but… I like solutions for real problems, not imaginary. With knowledge of solutions for imaginary problems we can create these problems later, without resolving them with other approaches.
Updated by zverok (Victor Shepelev) almost 6 years ago
I like solutions for real problems, not imaginary.
The map(&method(:local_method))
or yield_self(&method(:local_method))
pattern is absolutely real and very useful. My point was, we have plenty in our current codebase (and no, they are not "you just need to wrap collection items", my example was exaggerated for the illustrative purposes).
And I can definitely say it brings value for code design and clarity, and will be even more so with map(&.:local_method)
syntax.
Updated by shevegen (Robert A. Heiler) almost 6 years ago
The map(&method(:local_method)) or yield_self(&method(:local_method)) pattern is absolutely real
and very useful.
Everyone who suggests something tends to think of it as useful and often pretty too. :-)
I personally have become too picky perhaps. I already don't like yield_self much at all; "then"
is better than yield_self though.
In ruby it is possible to avoid a lot of things and still end up writing pretty code that is
fun.
My point was, we have plenty in our current codebase
I think a pretty syntax is great, but it is not necessarily ruby's primary design goal. It is
difficult to say because I am not matz :) but I think matz has said before that ruby should
be fun to use; and solve real problems; and help people. If you look at the safe navigation
operator, this is a good example, in my opinion. Someone had a use case and suggested a
solution to his problem, and matz agreed with the problem description and added the safe
navigation operator.
There are lots of things I myself have not yet used, including the safe navigation operator.
I also have not yet used the -> lambda variant. I no longer use @@variables either. I am
sure other people have different means how to use and approach ruby. What I do use, and
that has been somewhat newish (well not yet 10 years old I think), was the new additional
hash syntax, since it has a net benefit - less to type, e. g.:
:foo => :bar
versus
foo: :bar
Especially if I have lots of entries, the second variant is indeed easier to use for me.
And I can definitely say it brings value for code design and clarity, and will
be even more so with map(&.:local_method) syntax.
Using this reasoning we can say that EVERY addition is GOOD and USEFUL because we have
more features. But it is not quite like that. More and more features make a language
harder to use and more complicated too. Some features also look strange. For example,
I personally dislike the map(&.:local_method). I don't have an alternative suggestion
that is nice to read, but it is hard for me to visually distinguish between what is
going on there.
Ultimately it is up to matz how he wants to change ruby, but I really don't feel that
in all the discussions the trade off was or is really worth it. This may be up to
personal preferences or habits, yes - but ... I don't know.
When I look at things such as map(&.:local_method) then the original suggestion in
the issue of:
roots = [1, 4, 9].map Math->method
becomes a LOT cleaner and easier to read. ;)
(Only thing that puts me off is that -> is used in e. g. LPC to invoke methods;
I much prefer just the single "." notation. Do also note that I agree that we
should be able to pass arguments to .map(&) but ... I don't know. It's visually
not very pleasing to my eyes. :\ )
Updated by shuber (Sean Huber) almost 6 years ago
matz (Yukihiro Matsumoto) wrote:
Out of ruby-core:85038 candidates,
.:
looks best to me (followed by:::
).
Let me consider it for a while.Matz.
@matz (Yukihiro Matsumoto) and @nobu (Nobuyoshi Nakada)
What do you guys think about this alternative syntax? (working proof of concept: https://github.com/LendingHome/pipe_operator)
-9.pipe { abs | Math.sqrt | to_i }
#=> 3
[9, 64].map(&Math.|.sqrt)
#=> [3.0, 8.0]
[9, 64].map(&Math.|.sqrt.to_i.to_s)
#=> ["3", "8"]
"https://api.github.com/repos/ruby/ruby".| do
URI.parse
Net::HTTP.get
JSON.parse.fetch("stargazers_count")
yield_self { |n| "Ruby has #{n} stars" }
Kernel.puts
end
#=> Ruby has 15120 stars
There's nothing really new/special here - it's just a block of expressions like any other Ruby DSL and the pipe | operator has been around for decades!
The https://github.com/LendingHome/pipe_operator README contains many more examples and the implementation details - I would love to hear your thoughts!
Thanks,
Sean Huber
Updated by nobu (Nobuyoshi Nakada) almost 6 years ago
shuber (Sean Huber) wrote:
What do you guys think about this alternative syntax? (working proof of concept: https://github.com/LendingHome/pipe_operator)
It conflicts with existing |
methods.
p 1.|2 #=> 3
Updated by shuber (Sean Huber) almost 6 years ago
It conflicts with existing
|
methods.p 1.|2 #=> 3
@nobu (Nobuyoshi Nakada) That's just an alias for syntactic sugar - the actual method is named __pipe__
! My thinking was that it's pretty similar to how we commonly use send
(which can have conflicts in certain domains e.g. delivery services) but it's actually an "alias" of __send__
which is double underscored to avoid conflicts. Some objects may have their own definitions of |
but we always have pipe
or __pipe__
available to remove any ambiguity. Does that make sense?
def __pipe__(*args, &block)
Pipe.new(self, *args, &block)
end
alias | __pipe__
alias pipe __pipe__
Within the context of a __pipe__
block we don't have to worry about conflicting |
since we "own" that definition:
-9.pipe { abs | Math.sqrt | to_i } #=> 3
But like you stated, outside of a __pipe__
block the definition of |
could conflict:
1.|2 #=> 3
One thought comes to mind though - this "pipe" behavior really only needs to trigger in two cases:
- pipe
|
is called with NO arguments e.g.Math.|.sqrt
- pipe
|
is called with ONLY a block e.g. `"test".| { Marshal.dump | Base64.encode64 }
Do you know of any existing implementations of |
in the Ruby stdlib that either accept NO arguments or ONLY a block? I believe most if not all expect an argument to be passed? If so then that would make conflicts more rare if it's something we could build logic around!
Updated by shuber (Sean Huber) almost 6 years ago
@matz (Yukihiro Matsumoto) This pipe_operator
syntax actually looks very similar to https://github.com/matz/streem!
url.pipe { URI.parse | Net::HTTP.get | JSON.parse }
"https://api.github.com/repos/ruby/ruby".pipe do
URI.parse
Net::HTTP.get
JSON.parse.fetch("stargazers_count")
then { |n| "Ruby has #{n} stars" }
Kernel.puts
end
#=> Ruby has 15120 stars
Updated by shuber (Sean Huber) almost 6 years ago
Also discussing pipe operators in https://bugs.ruby-lang.org/issues/14392#note-26
Updated by headius (Charles Nutter) almost 6 years ago
Triple :
doesn't parse right now and has some synergy with constant references:
obj:::foo # => obj.method(:foo)
Updated by zverok (Victor Shepelev) almost 6 years ago
From developer's meeting log:
2.7 or later
knu: Introducing “…” (as in Lua) would allow for writing this way: ary.each { puts(...) }
Matz: Allowing omission of “self” sounds like a bad idea because that makes each(&:puts) and each(&.:puts) look very similar but act so differently.
The last Matz's notice makes a lot of sense for me, so I withdraw my petition for self
-less operator :)
Updated by nobu (Nobuyoshi Nakada) almost 6 years ago
- Status changed from Open to Closed
Updated by znz (Kazuhiro NISHIYAMA) almost 5 years ago
- Related to Feature #16275: Revert `.:` syntax added
Updated by hsbt (Hiroshi SHIBATA) almost 3 years ago
- Project changed from 14 to Ruby master