Using _ like in Scala?

Ruby
1

fruits = %w( apple banana orange )

fruits.each { puts _ }

vs

fruits.each { |f| puts f }

I was told that scala uses _ to denote as default block argument (the
first one. I am not sure what else scala does)

Could _ be used in Ruby to allow the same? In blocks that is.

The question is actually a bit larger. I am wondering whether Ruby could
reserve a set of key-names for variables.

In this example it could use _ but it could perhaps make better use of
it too. Perhaps even something like:

array_fruits = %w( apple banana orange )

^^^ And the above would keep the variable permanently as array type.
(With the convention being that the leading name array_ would indicate
that)

2

On Mon, Feb 6, 2012 at 13:54, Marc H. [email protected]
wrote:

I was told that scala uses _ to denote as default block argument (the
first one. I am not sure what else scala does)

Lots of things… some of which we want to do, some not. Let’s not go
down the Perlish path of relying on obscure syntax just to save a few
keystrokes… saving half a second for the writer, by wasting anywhere
from seconds to hours for each future reader.

that)
While those of us who came mostly from statically typed languages
might find that comforting, it would be all too easy to abuse, and
would change the fundamental nature of Ruby. Learn to love duck
typing. (I’ve always wondered how ducks could type so well with
wings, and webbed feet…)

-Dave

3

On Mon, Feb 6, 2012 at 12:54 PM, Marc H. [email protected]
wrote:

Could _ be used in Ruby to allow the same?

It could, but I doubt anyone would go for it. As an example, there are
already language features that add variables:

/a(?<middle_char>.)c/ =~ “abc”
middle_char # => “b”

that)

I don’t think this could be done without a serious overhaul of the type
system, and I can’t imagine why anyone would want to. It would even be
harmful, consider something like this:

def my_join(array_elements, delimiter=“”)
array_elements.drop(1).each_with_object(array_elements.first.to_s) do
|element, result|
result << delimiter.to_s << element.to_s
end
end

my_join [1, 2, 3], " " # => “1 2 3”
my_join 1…3, " " # => raises some kind of error

Now it will break because we passed it a range instead of an array, even
though it’s perfectly capable of performing this operation. Besides,
array_… is spammy (clutters the code with useless information). The
convention is to pluralize the argument if it’s a collection of items,
which reads very well and sufficiently informative.

So I don’t think there is a use case for it, there is definitely a use
case
against it, and it results in gross code.

That said, I actually like static typing, but I consider a type not to
be
the class of the object, but rather the set of methods invoked on the
object by whatever piece of code is using it (in this case, the type
would
be “an object that responds to drop and first” and probably being
extended to drop has an arity of one, and returns an object of type "responds to each_with_object`" further refinements around arity and
how
many arguments it passes to the block). Of course this will never happen
in
Ruby because of how much overhead it would add and because it wouldn’t
be
congruent with hyperdynamic dispatch (responding to methods that don’t
exist).

4

On Mon, Feb 6, 2012 at 7:21 PM, Tony A. [email protected]
wrote:

On Mon, Feb 6, 2012 at 10:54 AM, Marc H. [email protected] wrote:

Could _ be used in Ruby to allow the same?

IMHO, Ruby’s block argument semantics are already crazy enough.

How so?

5

On Mon, Feb 6, 2012 at 10:54 AM, Marc H. [email protected]
wrote:

Could _ be used in Ruby to allow the same?

IMHO, Ruby’s block argument semantics are already crazy enough.

6

On Mon, Feb 6, 2012 at 5:56 PM, Eric C. <
[email protected]> wrote:

IMHO, Ruby’s block argument semantics are already crazy enough.

How so?

The status quo is:

  • Yielding arguments to a block without arguments discards the arguments
  • Yielding a higher arity than what the block accepts truncates the
    arguments bound (the above can be considered the degenerate case of
    this)
  • Yielding a lower arity binds arguments to nil

So okay, given that, maybe a default argument could jive. I’ve seen the
same thing in Groovy, except they call it “it”

_ has precedence in irb already as the result of the last expression
evaluated… but _ might still work for this purpose. I’ve been using in
in
the Erlang sense sometimes to discard a variable in cases where I don’t
care (although thanks to what Ruby syntax allows even that is
superfluous)

7

On Mon, Feb 6, 2012 at 9:07 PM, Tony A. [email protected]
wrote:

  • Yielding arguments to a block without arguments discards the arguments
    care (although thanks to what Ruby syntax allows even that is superfluous)

–
Tony A.

It would make more sense to just eliminate the need to type even a
place holder while keeping the current form. I.E. fruits.each{puts}
Or come up with semantics that allow the interpreter to accept an
input like “puts fruits” and have Ruby unwind the collection.

8

On Tue, Feb 7, 2012 at 6:56 AM, Kevin [email protected] wrote:

It would make more sense to just eliminate the need to type even a
place holder while keeping the current form. I.E. fruits.each{puts}
Or come up with semantics that allow the interpreter to accept an
input like “puts fruits” and have Ruby unwind the collection.

Like

irb(main):001:0> class Object
irb(main):002:1> def out(io = $stdout) io.puts(self) end
irb(main):003:1> end
=> nil
irb(main):004:0> fruits = %w( apple banana orange )
=> [“apple”, “banana”, “orange”]
irb(main):005:0> fruits.each &:out
apple
banana
orange
=> [“apple”, “banana”, “orange”]

? Btw, I don’t like _ either.

Kind regards

robert

9

On Tue, Feb 7, 2012 at 1:00 PM, Josh C. [email protected] wrote:

I do this sometimes, but I do it like this

%w[apple banana orange].each &method(:puts)

>> apple

>> banana

>> orange

This one isn’t too bad.

+1

It can get kind of gross when you need to get the
method from elsewhere, though:

%w[apple banana orange].each &Kernel.method(:puts)

>> apple

>> banana

>> orange

I wouldn’t mind if there were cleaner ways of accessing the methods
themselves (some kind of syntax).

I’d make it explicit as long as this “cleaner syntax” is lacking.

Although what I’d really like would be a syntax for naming inline blocks,
then my editor could fold the block body inside the name, something like
%w[apple banana orange].each display

And it would expand to something like
%w[apple banana orange].each { |display → fruit| puts fruit }

How would the above be derived from the line further up?

But never found anything I was very happy with.

Actually in this case “puts fruits” would be the best solution. :wink:
Did anybody suggest it before?

Kind regards

robert

10

On Tue, Feb 7, 2012 at 4:47 AM, Robert K.
[email protected]wrote:

irb(main):003:1> end

I do this sometimes, but I do it like this

%w[apple banana orange].each &method(:puts)

>> apple

>> banana

>> orange

This one isn’t too bad. It can get kind of gross when you need to get
the
method from elsewhere, though:

%w[apple banana orange].each &Kernel.method(:puts)

>> apple

>> banana

>> orange

I wouldn’t mind if there were cleaner ways of accessing the methods
themselves (some kind of syntax).

Although what I’d really like would be a syntax for naming inline
blocks,
then my editor could fold the block body inside the name, something like
%w[apple banana orange].each display

And it would expand to something like
%w[apple banana orange].each { |display → fruit| puts fruit }

Then it looks good if it’s in plain text or managed by the editor. The
biggest benefit to me is that it allows you to abstract the
implementation
of what you want to do with this thing from its implementation, but
without
littering your class with methods only used in one place (also methods
aren’t closures, so often won’t work for this.

I’ve played around with this idea using methods
def display
lambda { |fruit| puts fruit }
end
%w[apple banana orange].each &display

and using local variables
display = lambda { |fruit| puts fruit }
%w[apple banana orange].each &display

But never found anything I was very happy with.

11

You’ve already got a lot of responses, on top of my head these are the
two most relevant tickets which have been opened so far:

Provide Default Variables for Array#each and other iterators

and

default variable name for parameter

HTH

12

On Tue, Feb 07, 2012 at 02:56:30PM +0900, Kevin wrote:

It would make more sense to just eliminate the need to type even a
place holder while keeping the current form. I.E. fruits.each{puts}
Or come up with semantics that allow the interpreter to accept an
input like “puts fruits” and have Ruby unwind the collection.

What – like this?

$ irb
>> fruits = ['apple', 'orange']
=> ["apple", "orange"]
>> puts fruits
apple
orange
=> nil
13

On Tue, Feb 7, 2012 at 9:15 AM, Robert K.
[email protected]wrote:

Although what I’d really like would be a syntax for naming inline blocks,
then my editor could fold the block body inside the name, something like
%w[apple banana orange].each display

And it would expand to something like
%w[apple banana orange].each { |display → fruit| puts fruit }

How would the above be derived from the line further up?

The name would have no impact on the language, it is still just a block
which takes one argument. It exists to help the developer (and be used
by
the editor).

But never found anything I was very happy with.

Actually in this case “puts fruits” would be the best solution. :wink:
Did anybody suggest it before?

In this case, yes :stuck_out_tongue:

Often examples become more complicated, I often feel that the contents
of a
block are at a different level of abstraction from the containing code
(the
block is a “how I do it” but I’d like to just look at a “what I am
doing”,
which is where the name has relevance).

On Tue, Feb 7, 2012 at 6:30 PM, Kevin [email protected] wrote:

Yes. Does this only work in the REPL? I’ve never tried that kind of
order in real code.

No, this works everywhere. It is just how the puts method deals with
arrays
http://rubydoc.info/stdlib/core/1.9.3/IO:puts

14

On Tue, Feb 7, 2012 at 9:43 PM, Josh C. [email protected] wrote:

What – like this?
order in real code.

No, this works everywhere. It is just how the puts method deals with arrays
Method: IO#puts — Documentation for core (1.9.3)
Good to know that Ruby already supports what I thought of doing.

15

On Tue, Feb 7, 2012 at 1:49 PM, Chad P. [email protected] wrote:

fruits = [‘apple’, ‘orange’]
=> [“apple”, “orange”]
puts fruits
apple
orange
=> nil

–
Chad P. [ original content licensed OWL: http://owl.apotheon.org ]

Yes. Does this only work in the REPL? I’ve never tried that kind of
order in real code.

16

On Wed, Feb 8, 2012 at 3:43 AM, Josh C. [email protected] wrote:

The name would have no impact on the language, it is still just a block
which takes one argument. It exists to help the developer (and be used by
the editor).

Hmm… Maybe I wasn’t clear enough. I was trying to ask how any
automated mechanism could read

%w[apple banana orange].each display

and know it must make

%w[apple banana orange].each { |display → fruit| puts fruit }

from it. I am asking specifically since “puts” is nowhere mentioned
in the line above. So even if the syntax would be allowed there would
have to be some ruling which leads to an interpretation equivalent to
the second line.

Often examples become more complicated, I often feel that the contents of a
block are at a different level of abstraction from the containing code (the
block is a “how I do it” but I’d like to just look at a “what I am doing”,
which is where the name has relevance).

But examples posted here should be at least realistic so we are not
discussing the wrong use case. In case of printing an Enumerable
“puts enum” is certainly the best option. :slight_smile:

Kind regards

robert

17

On Wed, Feb 8, 2012 at 5:58 AM, Robert K.
[email protected]wrote:

And it would expand to something like

Not sure about other editors, but TextMate knows what context it is in
if
you write something like [].each { |e| } put your cursor before the e
and
press C-P, it tells you variable.other.block.ruby. So it knows when it
is
in block paramaters, it would just need to then understand that within
this
context, if it sees something like |name -> var| that “name” is the
name
of this block, and then just allow for block folding. It actually
already
does all this
https://s3.amazonaws.com/josh.cheek/images/scratch/block_folding.png but
instead of showing ‘…’ it could show ‘name …’

“puts enum” is certainly the best option. :slight_smile:

I just used that because it was the example provided by the OP.

In this example, for instance

It would be nice if I could define the block like this |override_body -> value=nil, &initializer|

Which would then get folded up like this (with visual distinction clues
provided by the highlighter)

def define_override
ivar, meth = self.ivar, self.meth
klass.send :define_method, “with_#{meth}” override_body…
end

That method is pretty easy to understand, but when you expand it, the
code
of the body is inline with the code that sets up the definition, causing
it
to take much more effort to understand (you parse/interpret it to
determine
what is and is not relevant to you).

18

On Wed, Feb 08, 2012 at 09:30:42AM +0900, Kevin wrote:

19

On Wed, Feb 8, 2012 at 4:30 PM, Josh C. [email protected] wrote:

%w[apple banana orange].each display
Hmm… Maybe I wasn’t clear enough. I was trying to ask how any
have to be some ruling which leads to an interpretation equivalent to
https://s3.amazonaws.com/josh.cheek/images/scratch/block_folding.png but
instead of showing ‘…’ it could show ‘name …’

So you are talking about an editor feature and not a language feature?
I am starting to get an idea of where I misunderstood you… :slight_smile:

ivar, meth = self.ivar, self.meth
klass.send :define_method, “with_#{meth}” override_body…
end

That method is pretty easy to understand, but when you expand it, the code
of the body is inline with the code that sets up the definition, causing it
to take much more effort to understand (you parse/interpret it to determine
what is and is not relevant to you).

Again, an editor feature?

Cheers

robert

20

On Wed, Feb 8, 2012 at 12:26 PM, Steve K. [email protected]
wrote:

1.9.2p290 :002 > fruits.each { puts $_ }

=> [“apple”, “banana”, “orange”]

Wouldn’t the general use case at issue here be addressed by adding
standalone versions of various functions traditionally associated with
collections so that one could call say reduce like “reduce myarray,
:+”? Granted if we started doing that we might get tempted to
parenthesize everything and at that point we may as well go write
Lisp.