Using _ like in Scala?

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?

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)

···

--
Posted via http://www.ruby-forum.com/.

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.

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)

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

···

On Mon, Feb 6, 2012 at 13:54, Marc Heiler <shevegen@linuxmail.org> wrote:

--
Dave Aronson: Available Cleared Ruby on Rails Freelancer
(NoVa/DC/Remote) -- see www.DaveAronson.com, and blogs at
www.Codosaur.us, www.Dare2XL.com, www.RecruitingRants.com

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?

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"

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)

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).

···

On Mon, Feb 6, 2012 at 12:54 PM, Marc Heiler <shevegen@linuxmail.org> wrote:

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

···

On Mon, Feb 6, 2012 at 10:54 AM, Marc Heiler <shevegen@linuxmail.org> wrote:

Could _ be used in Ruby to allow the same?

--
Tony Arcieri

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
http://bugs.ruby-lang.org/issues/4830

and

default variable name for parameter
http://bugs.ruby-lang.org/issues/4475

HTH

How so?

···

On Mon, Feb 6, 2012 at 7:21 PM, Tony Arcieri <tony.arcieri@gmail.com> wrote:

On Mon, Feb 6, 2012 at 10:54 AM, Marc Heiler <shevegen@linuxmail.org> wrote:

Could _ be used in Ruby to allow the same?

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

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)

···

On Mon, Feb 6, 2012 at 5:56 PM, Eric Christopherson < echristopherson@gmail.com> wrote:

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

How so?

--
Tony Arcieri

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.

···

On Mon, Feb 6, 2012 at 9:07 PM, Tony Arcieri <tony.arcieri@gmail.com> wrote:

On Mon, Feb 6, 2012 at 5:56 PM, Eric Christopherson < > echristopherson@gmail.com> 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)

--
Tony Arcieri

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

···

On Tue, Feb 7, 2012 at 6:56 AM, Kevin <darkintent@gmail.com> 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.

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

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

···

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

--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]

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.

···

On Tue, Feb 7, 2012 at 4:47 AM, Robert Klemme <shortcutter@googlemail.com>wrote:

On Tue, Feb 7, 2012 at 6:56 AM, Kevin <darkintent@gmail.com> 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.

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

···

On Tue, Feb 7, 2012 at 1:49 PM, Chad Perrin <code@apotheon.net> wrote:

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

--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]

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

···

On Tue, Feb 7, 2012 at 1:00 PM, Josh Cheek <josh.cheek@gmail.com> wrote:

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

As mentioned elsewhere, this works in Ruby, period.

···

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

On Tue, Feb 7, 2012 at 1:49 PM, Chad Perrin <code@apotheon.net> wrote:
> 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

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

--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]

> 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 9:15 AM, Robert Klemme <shortcutter@googlemail.com>wrote:

On Tue, Feb 7, 2012 at 6:30 PM, Kevin <darkintent@gmail.com> wrote:

> What -- like this?
>
> $ irb
> >> fruits = ['apple', 'orange']
> => ["apple", "orange"]
> >> puts fruits
> apple
> orange
> => nil

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

Good to know that Ruby already supports what I thought of doing.

···

On Tue, Feb 7, 2012 at 9:43 PM, Josh Cheek <josh.cheek@gmail.com> wrote:

On Tue, Feb 7, 2012 at 9:15 AM, Robert Klemme <shortcutter@googlemail.com>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 <darkintent@gmail.com> wrote:

> What -- like this?
>
> $ irb
> >> fruits = ['apple', 'orange']
> => ["apple", "orange"]
> >> puts fruits
> apple
> orange
> => nil

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
Method: IO#puts — Documentation for core (1.9.3)

> 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).

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

···

On Wed, Feb 8, 2012 at 3:43 AM, Josh Cheek <josh.cheek@gmail.com> wrote:

On Tue, Feb 7, 2012 at 9:15 AM, Robert Klemme <shortcutter@googlemail.com>wrote:

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

>
>> > 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).

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.

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 ...'

> 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:

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).

···

On Wed, Feb 8, 2012 at 5:58 AM, Robert Klemme <shortcutter@googlemail.com>wrote:

On Wed, Feb 8, 2012 at 3:43 AM, Josh Cheek <josh.cheek@gmail.com> wrote:
> On Tue, Feb 7, 2012 at 9:15 AM, Robert Klemme < > shortcutter@googlemail.com>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).

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.

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 ...'

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:

In this example, for instance
deject/lib/deject/object_oriented.rb at 5bc94b05cfca045afebcb447170d9f549b9e4006 · JoshCheek/deject · GitHub

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).

Again, an editor feature?

Cheers

robert

···

On Wed, Feb 8, 2012 at 4:30 PM, Josh Cheek <josh.cheek@gmail.com> wrote:

On Wed, Feb 8, 2012 at 5:58 AM, Robert Klemme <shortcutter@googlemail.com>wrote:

On Wed, Feb 8, 2012 at 3:43 AM, Josh Cheek <josh.cheek@gmail.com> wrote:
> On Tue, Feb 7, 2012 at 9:15 AM, Robert Klemme < >> shortcutter@googlemail.com>wrote:

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

Ruby has Perl's $_, but only in certain contexts:

$ echo "foo" | ruby -pe 'next unless $_ =~ /(foo|bar|baz)/'
foo
$

For example. I'm not sure when it's valid, as this perl-ism isn't:

1.9.2p290 :001 > fruits = %w( apple banana orange )
=> ["apple", "banana", "orange"]
1.9.2p290 :002 > fruits.each { puts $_ }

=> ["apple", "banana", "orange"]