Do/end vs braces

[Paul_Sanchez2 (Paul Sanchez)]

In article <200512082012.03896.slitt@earthlink.net>,

···

Steve Litt <slitt@earthlink.net> wrote:

On Thursday 08 December 2005 06:06 pm, Jacob Fugal wrote:
> On 12/8/05, Steve Litt <slitt@earthlink.net> wrote:
> > Except I can't put in the parentheses:
> >
> > #!/usr/bin/ruby
> > my_array = ["alpha", "beta", "gamma"]
> > puts (my_array.collect do
> >
> > >word>
> >
> > word.capitalize
> > end)
> >
> > Output:
> > [slitt@mydesk slitt]$ ./test.rb
> > ./test.rb:3: syntax error
> > ./test.rb:6: syntax error
>
> Take out the space between puts and the open paren:

Confirmed! Thanks Jacob. This is the first time I've seen Ruby conflict with
the Rule of Least Surprise (http://www.faqs.org/docs/artu/ch11s01.html\).

Is there any chance of a Ruby change so as not to require the paren to be
flush up against the function name?

Interestingly, it worked for me with a space or without the parens when
I did the puts as a one-liner:

puts my_array.collect {|word| word.capitalize}

or

puts (my_array.collect {|word| word.capitalize})

--paul

[MenTaLguY1 (MenTaLguY)]

Egh... I think that'd introduce more ambiguities into the grammar...
it's pretty bad that way already.

-mental

···

On Fri, 2005-12-09 at 10:11 +0900, Steve Litt wrote:

Is there any chance of a Ruby change so as not to require the paren to be
flush up against the function name?

[Logan_Capaldo]

Except I can't put in the parentheses:

#!/usr/bin/ruby
my_array = ["alpha", "beta", "gamma"]
puts (my_array.collect do

        >word>

        word.capitalize
end)

Output:
[slitt@mydesk slitt]$ ./test.rb
./test.rb:3: syntax error
./test.rb:6: syntax error

Take out the space between puts and the open paren:

Confirmed! Thanks Jacob. This is the first time I've seen Ruby conflict with
the Rule of Least Surprise (http://www.faqs.org/docs/artu/ch11s01.html\).

Is there any chance of a Ruby change so as not to require the paren to be
flush up against the function name?

Thanks

SteveT

Doubtful. Matz. has been trying to move in the opposite direction:
irb(main):003:0> puts ("Hello", "World")
(irb):3: warning: don't put space before argument parentheses
Hello
World
=> nil

···

On Dec 8, 2005, at 8:11 PM, Steve Litt wrote:

On Thursday 08 December 2005 06:06 pm, Jacob Fugal wrote:

On 12/8/05, Steve Litt <slitt@earthlink.net> wrote:

Steve Litt
http://www.troubleshooters.com
slitt@troubleshooters.com

[7rans]

I've sometimes thought, "man wouldn't it be tight if we had some sort
of vertical brackets?"

  task :test .--.
    ruby "test/unittest.rb"
  '--'

T.

[Steve_Litt]

Hi Paul,

It works as expected with braces, but not with do/end.

Thanks

SteveT

Steve Litt

Troubleshooters.Com

slitt@troubleshooters.com

···

On Thursday 08 December 2005 08:42 pm, Paul Sanchez wrote:

In article <200512082012.03896.slitt@earthlink.net>,

Steve Litt <slitt@earthlink.net> wrote:
> On Thursday 08 December 2005 06:06 pm, Jacob Fugal wrote:
> > On 12/8/05, Steve Litt <slitt@earthlink.net> wrote:
> > > Except I can't put in the parentheses:
> > >
> > > #!/usr/bin/ruby
> > > my_array = ["alpha", "beta", "gamma"]
> > > puts (my_array.collect do
> > >
> > > >word>
> > >
> > > word.capitalize
> > > end)
> > >
> > > Output:
> > > [slitt@mydesk slitt]$ ./test.rb
> > > ./test.rb:3: syntax error
> > > ./test.rb:6: syntax error
> >
> > Take out the space between puts and the open paren:
>
> Confirmed! Thanks Jacob. This is the first time I've seen Ruby conflict
> with the Rule of Least Surprise
> (http://www.faqs.org/docs/artu/ch11s01.html\).
>
> Is there any chance of a Ruby change so as not to require the paren to be
> flush up against the function name?

Interestingly, it worked for me with a space or without the parens when
I did the puts as a one-liner:

puts my_array.collect {|word| word.capitalize}

or

puts (my_array.collect {|word| word.capitalize})

[Chad_Perrin1 (Chad Perrin)]

I'd be happy with it either way, as long as it's consistent.

···

On Fri, Dec 09, 2005 at 05:00:13PM +0900, Logan Capaldo wrote:

Doubtful. Matz. has been trying to move in the opposite direction:
irb(main):003:0> puts ("Hello", "World")
(irb):3: warning: don't put space before argument parentheses
Hello
World
=> nil

--
Chad Perrin [ CCD CopyWrite | http://ccd.apotheon.org ]

unix virus: If you're using a unixlike OS, please forward
this to 20 others and erase your system partition.

[Christian_Neukirche1 (Christian Neukirchen)]

"Trans" <transfire@gmail.com> writes:

I've sometimes thought, "man wouldn't it be tight if we had some sort
of vertical brackets?"

  task :test .--.
    ruby "test/unittest.rb"
  '--'

Cuuute. Imagine the possibilities, e.g. vertical XHTML:

/\
html
xmlns="http://www.w3.org/1999/xhtml&quot;
\/
/\
title
\/
What a pervert idea!
/\
\
\
title
\/
/\
\
\
html
\/

You get a nice "overview" by turning your head 270°.

···

T.

--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org

[daz]

Chad Perrin wrote:

···

On Fri, Dec 09, 2005 at 05:00:13PM +0900, Logan Capaldo wrote:
>
> Doubtful. Matz. has been trying to move in the opposite direction:
> irb(main):003:0> puts ("Hello", "World")
> (irb):3: warning: don't put space before argument parentheses
> Hello
> World
> => nil
>

I'd be happy with it either way, as long as it's consistent.

Without space, it's consistent.
It's not always what we want it to mean, though.

Take this example (with which I frequently inconvenience myself):

#-----------------------------------------------------
(0..5).map do |n|
  10*n
end
#-----------------------------------------------------

* I want to see the result, so I prepend "p ":

#-----------------------------------------------------
p (0..5).map do |n|
  10*n
end
#=> C:/TEMP/rb284.TMP:1: warning: (...) interpreted as grouped expression
# [- Okay, that's what it is.]
#=> [0, 1, 2, 3, 4, 5]
# [- But that's not what I wanted. The block binds to method #p
# - the argument to #p is ((0..5).map) - an Array (in Ruby 1.8.2)
#-----------------------------------------------------

* Remove the space after p

#-----------------------------------------------------
p(0..5).map do |n|
  10*n
end
#=> 0..5
# [Oh, no !]
#=> C:/TEMP/rb284.TMP:1: undefined method `map' for nil:NilClass (NoMethodError)
# [Aargh!]
#-----------------------------------------------------

* Parenthesise correctly but "uglily" ;))

#-----------------------------------------------------
p((0..5).map do |n|
  10*n
end)
#=> [0, 10, 20, 30, 40, 50] # no problem at all
#-----------------------------------------------------

* But we don't need to do any of those.
* From the initial example, just prepend "<var> = "
  and there's no "binding" issue ...

#-----------------------------------------------------
r = (0..5).map do |n|
  10*n
end
p r #=> [0, 10, 20, 30, 40, 50]
#-----------------------------------------------------

IMHO, it's our problem, not Ruby's.
The problem could appear in many places but, for me,
it's almost always when prepending p, puts or print.

Things could be a lot worse than this

daz

[Steve_Litt]

Yes, at least the warning would get me out of the habit ast.

SteveT

Steve Litt

Troubleshooters.Com

slitt@troubleshooters.com

···

On Friday 09 December 2005 03:12 am, Chad Perrin wrote:

On Fri, Dec 09, 2005 at 05:00:13PM +0900, Logan Capaldo wrote:
> Doubtful. Matz. has been trying to move in the opposite direction:
> irb(main):003:0> puts ("Hello", "World")
> (irb):3: warning: don't put space before argument parentheses
> Hello
> World
> => nil

I'd be happy with it either way, as long as it's consistent.

[Chad_Perrin1 (Chad Perrin)]

There's a problem of understanding there, not of consistency. When you
butt the parentheses up against a method like that, you're basically
saying that the method's parameters are exactly what's in the
parentheses -- no more and no less. At least, that's what seems logical
to me. When you separate it with a space, parentheses make for a great
way to set precedence within the larger statement while still allowing
the whole thing to be your set of method parameters (or, perhaps more
accurately, let the whole thing return your method parameter(s)).

The problem that arises for me isn't that the meaning of an arrangement
of character on the screen is different from another arrangement: it's
that you can have the parentheses flush with the method or not and it
works the same either way, unless it doesn't. It just seems to me that,
for consistency's sake, what you use as block delimiters shouldn't
affect whether parentheses for method parameters have to be flush with
the method name itself.

I can do just fine with the way it is, but it seems that it shouldn't
require such a convoluted understanding of how the language behaves.
Ruby, in other ways, conforms very well to the "rule of least surprise";
why should that change in this one instance?

Then again, maybe that's just me.

···

On Fri, Dec 09, 2005 at 07:52:36PM +0900, daz wrote:

Chad Perrin wrote:
>
> I'd be happy with it either way, as long as it's consistent.
>

Without space, it's consistent.
It's not always what we want it to mean, though.

* I want to see the result, so I prepend "p ":

#-----------------------------------------------------
p (0..5).map do |n|
  10*n
end
#=> C:/TEMP/rb284.TMP:1: warning: (...) interpreted as grouped expression
# [- Okay, that's what it is.]
#=> [0, 1, 2, 3, 4, 5]
# [- But that's not what I wanted. The block binds to method #p
# - the argument to #p is ((0..5).map) - an Array (in Ruby 1.8.2)
#-----------------------------------------------------

* Remove the space after p

#-----------------------------------------------------
p(0..5).map do |n|
  10*n
end
#=> 0..5
# [Oh, no !]
#=> C:/TEMP/rb284.TMP:1: undefined method `map' for nil:NilClass (NoMethodError)
# [Aargh!]
#-----------------------------------------------------

--
Chad Perrin [ CCD CopyWrite | http://ccd.apotheon.org ]

unix virus: If you're using a unixlike OS, please forward
this to 20 others and erase your system partition.

[Jacob_Fugal]

1) Choice of block delimiters has no more influence on whether
parentheses for method parameters have to be flush with the method
name itself than choosing 'and' vs. '&&' does... and that is none.

In my ruby (1.8.2, 2005-04-11, i386-linux) I don't even get the
warning about not putting spaces in. As far as I can tell, putting a
space between the method and the open parenthesis is equivalent to not
parenthesizing your argument list; the parentheses that had been an
argument list marker are now only a precedence operation. On that
assumption, the warning is either newer or older, and only serves to
chastise (ie. *warn*) those that are making the mistake of thinking
their parens are marking the parameter list when they really aren't.

2) With regards to implicit method parameters, the effect of choosing
do/end over braces is no different than the choice of 'and' over '&&'
-- or 'or' over '||'. Example:

  puts(false) or true # explicit, or => prints false, returns true
  puts(false) || true # explicit, || => prints false, returns true
  puts false or true # implicit, or => prints false, returns true
  puts false || true # implicit, || => prints true, returns nil

Both explicit method calls know their arguments exactly. The implicit
method calls, however, get different argument lists depending on the
*precedence*. The || operator binds higher than the implicit method
call, but the 'or' operator does not.

Similarly, the {} block syntax binds higher than the implicit method
call. The 'do ... end' block syntax does not:

  def foo
    block_given?
  end

  def bar( arg )
    puts arg
    block_given?
  end

  bar(foo) do ; end # explicit, do/end => prints false, returns true
  bar(foo) { ; } # explicit, braces => prints false, returns true
  bar foo do ; end # implicit, do/end => prints false, returns true
  bar foo { ; } # implicit, braces => prints true, returns false

That's it. That's the difference between do/end and braces. Period.
Any other difference is only convention and personal preference.

Jacob Fugal

···

On 12/9/05, Chad Perrin <perrin@apotheon.com> wrote:

... It just seems to me that,
for consistency's sake, what you use as block delimiters shouldn't
affect whether parentheses for method parameters have to be flush with
the method name itself.

[Chad_Perrin1 (Chad Perrin)]

[lots of stuff]

Thanks for the clarification. I blame my momentary lapse on lack of
sleep.

. . . and unfortunately largely superficial familiarity with Ruby.

···

On Sat, Dec 10, 2005 at 06:14:21AM +0900, Jacob Fugal wrote:

--
Chad Perrin [ CCD CopyWrite | http://ccd.apotheon.org ]

unix virus: If you're using a unixlike OS, please forward
this to 20 others and erase your system partition.