Forum: Ruby Rescue clauses on do/end blocks?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Daniel S. (Guest)
on 2006-05-18 18:56
(Received via mailing list)
I know this has been on the table before, but I really see no reason not
to allow do/end blocks to have rescue clauses on them, i.e.

   foo do
     bar
   rescue
     baz
   end

and even

   foo do
     bar
   rescue
     baz
   ensure
     bur
   end

These would be equivalent to

   foo do
     begin
       bar
     rescue
       baz
     ensure
       bur
     end
   end

When an ensure clause is added, the expression evaluated therein will
always be the return value of a call to the block -- just as if there
was a begin/end block inside the do/end block.

This wouldn't offer any new functionality, but would make the use of
rescue and ensure clauses more consistent -- currently they work with
begin, class, and def blocks (more?).

There's of course the case of the curly bracket block syntax, but I see
no need to support it there -- I think it's most commonly used with
one-liners, where rescuing may be overkill.

I'd like some feedback, and if its generally positive, I'll post an RCR.


Cheers,
Daniel
Robert K. (Guest)
on 2006-05-18 19:02
(Received via mailing list)
2006/5/18, Daniel S. <removed_email_address@domain.invalid>:

> I'd like some feedback, and if its generally positive, I'll post an RCR.

Go for it!

robert
Justin B. (Guest)
on 2006-05-18 19:06
(Received via mailing list)
On 5/18/06, Daniel S. <removed_email_address@domain.invalid> wrote:
>
> I know this has been on the table before, but I really see no reason not
> to allow do/end blocks to have rescue clauses on them, i.e.



I've tried that syntax myself and been surprised when it failed. It
seems
like less typing to me- usually a good thing!

Justin
Ross B. (Guest)
on 2006-05-18 19:26
(Received via mailing list)
On Thu, 2006-05-18 at 23:55 +0900, Daniel S. wrote:
> I know this has been on the table before, but I really see no reason not
> to allow do/end blocks to have rescue clauses on them, i.e.
>
>    foo do
>      bar
>    rescue
>      baz
>    end

Just playing Devil's Advocate, what'd happen with this:

	File.open('somefile') do |f|
	  puts f.read
	end rescue puts "Can't open"

?
Daniel S. (Guest)
on 2006-05-18 19:36
(Received via mailing list)
Ross B. wrote:
> Just playing Devil's Advocate, what'd happen with this:
>
> 	File.open('somefile') do |f|
> 	  puts f.read
> 	end rescue puts "Can't open"

The same as there would now; since the rescue clause is not inside the
do/end block, it is not affected by this proposal.

The difference would be that your version would also rescue exceptions
raised by File.open, while the proposed syntax would only rescue
exceptions raised within the block given to File.open.

But I like the devil's advocate approach, it makes the proposals sharper
:)


Daniel
Daniel S. (Guest)
on 2006-05-18 19:49
(Received via mailing list)
Robert K. wrote:
> 2006/5/18, Daniel S. <removed_email_address@domain.invalid>:
>
>> I'd like some feedback, and if its generally positive, I'll post an RCR.
>
> Go for it!

Alrighty then!

<http://www.rcrchive.net/rcr/show/336>


Cheers,
Daniel
Uncutstone W. (Guest)
on 2006-05-18 20:05
Ross B. wrote:
> On Thu, 2006-05-18 at 23:55 +0900, Daniel S. wrote:
>> I know this has been on the table before, but I really see no reason not
>> to allow do/end blocks to have rescue clauses on them, i.e.
>>
>>    foo do
>>      bar
>>    rescue
>>      baz
>>    end
>
> Just playing Devil's Advocate, what'd happen with this:
>
> 	File.open('somefile') do |f|
> 	  puts f.read
> 	end rescue puts "Can't open"
>
> ?

What if rescue has more than one sentence? It seems not a good idea.
But I agree with Daniel S.'s proposal.
Ross B. (Guest)
on 2006-05-18 20:14
(Received via mailing list)
On Fri, 2006-05-19 at 00:34 +0900, Daniel S. wrote:
> >
> raised by File.open, while the proposed syntax would only rescue
> exceptions raised within the block given to File.open.
>

Does that mean that with the proposed syntax, to rescue an exception
from this File.open, we'd have to use:

	begin
	  File.open('somefile') do |f|
	    puts f.read
	  rescue
	    # exception from f.read
	  end
	rescue
	  # exception from File.open
	end

> But I like the devil's advocate approach, it makes the proposals sharper :)

:) In truth, I think I'm in favour of this change, especially if it
could be done so that the rescue catches exceptions from the block _as
well_ as those from the method to which the block is attached (if any).
Uncutstone W. (Guest)
on 2006-05-18 20:26
uncutstone wu wrote:
> Ross B. wrote:
>> On Thu, 2006-05-18 at 23:55 +0900, Daniel S. wrote:
>>> I know this has been on the table before, but I really see no reason not
>>> to allow do/end blocks to have rescue clauses on them, i.e.
>>>
>>>    foo do
>>>      bar
>>>    rescue
>>>      baz
>>>    end
>>
>> Just playing Devil's Advocate, what'd happen with this:
>>
>> 	File.open('somefile') do |f|
>> 	  puts f.read
>> 	end rescue puts "Can't open"
>>
>> ?
>
> What if rescue has more than one sentence? It seems not a good idea.
> But I agree with Daniel S.'s proposal.

I think the syntax would be changed as below:
        File.open('somefile') do |f|
	  puts f.read
 	rescue
          puts "Can't open"
        end
Austin Z. (Guest)
on 2006-05-18 21:17
(Received via mailing list)
On 5/18/06, Daniel S. <removed_email_address@domain.invalid> wrote:
> I know this has been on the table before, but I really see no reason not
> to allow do/end blocks to have rescue clauses on them, i.e.

The main reason that Matz has opposed it before is:

  foo {
    bar
  rescue
    baz
  }

It does look odd, but I think people will just get used to it.

-austin
Daniel S. (Guest)
on 2006-05-18 21:20
(Received via mailing list)
Ross B. wrote:
> 	  # exception from File.open
> 	end

As I imagine it right now, rescue clauses on do/end blocks would only
rescue exceptions raised *inside* that block -- to rescue exceptions
raised with the method the block is attached to, one must wrap the
method with begin/end.

>> But I like the devil's advocate approach, it makes the proposals sharper :)
>
> :) In truth, I think I'm in favour of this change, especially if it
> could be done so that the rescue catches exceptions from the block _as
> well_ as those from the method to which the block is attached (if any).

I'm not sure I'd like that -- I see a block attached to a method call as
being, in some sense, a child of that call, another kind of argument if
you will; having the child rescue exceptions raised by the parent seems
unintuitive to me, though others may feel different.

People, feel free to chime in.


Daniel
Daniel S. (Guest)
on 2006-05-18 21:24
(Received via mailing list)
uncutstone wu wrote:
> I think the syntax would be changed as below:
>   File.open('somefile') do |f|
>     puts f.read
>   rescue
>     puts "Can't open"
>   end

Rather:

   File.open('pr0n') do |f|
     puts f.read
   rescue
     puts "can't read"
   end

since we won't rescue any exceptions raised by File.open, only those
raised by File#read.


Daniel
Eric H. (Guest)
on 2006-05-18 22:16
(Received via mailing list)
On May 18, 2006, at 7:55 AM, Daniel S. wrote:

> I know this has been on the table before, but I really see no
> reason not to allow do/end blocks to have rescue clauses on them, i.e.
>
>   foo do
>     bar
>   rescue
>     baz
>   end

[...]

> I'd like some feedback, and if its generally positive, I'll post an
> RCR.

Setting up and tearing down an exception handler for every block
invocation is going to be expensive.

I vote no.

--
Eric H. - removed_email_address@domain.invalid - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
Jim W. (Guest)
on 2006-05-18 22:22
Eric H. wrote:
> Setting up and tearing down an exception handler for every block
> invocation is going to be expensive.

Couldn't the setup/teardown be done only if a rescue/ensure clause was
actually present?  It also seems to me that this would mean the the
setup/teardown would have to be in the block itself, not in the calling
method.  Thus making it hard to rescue exceptions from the calling
method (as some have suggested).

For the record,

(A) if it can be done efficiently, I'm for it.
(B) I'm not in favor of rescuing exceptions from the parent method.
That just seems backwards to me.

--
-- Jim W.
Pistos C. (Guest)
on 2006-05-18 22:55
Daniel S. wrote:
>> :) In truth, I think I'm in favour of this change, especially if it
>> could be done so that the rescue catches exceptions from the block _as
>> well_ as those from the method to which the block is attached (if any).
>
> I'm not sure I'd like that -- I see a block attached to a method call as
> being, in some sense, a child of that call, another kind of argument if
> you will; having the child rescue exceptions raised by the parent seems
> unintuitive to me, though others may feel different.

I agree with Daniel.  It should only rescue exceptions raised in the
block, not the parent/holder/caller/receiver of the block.

Pistos
Daniel S. (Guest)
on 2006-05-19 00:01
(Received via mailing list)
Austin Z. wrote:
> The main reason that Matz has opposed it before is:
>
>  foo {
>    bar
>  rescue
>    baz
>  }
>
> It does look odd, but I think people will just get used to it.

I think it looks too odd. The do/end and the curly bracket syntaxes are
used in different places -- if I needed error handling, I would never
use the curly brackets anyway. I see the problem, though; I just don't
think it's big enough to block the implementation of this.


Daniel
Daniel S. (Guest)
on 2006-05-19 00:01
(Received via mailing list)
Eric H. wrote:
> Setting up and tearing down an exception handler for every block
> invocation is going to be expensive.
>
> I vote no.

Wouldn't it be possible to only set up an exception handler for blocks
that actually have rescue clauses?


Daniel
unknown (Guest)
on 2006-05-19 00:56
(Received via mailing list)
Hi --

On Fri, 19 May 2006, Daniel S. wrote:

>
> I think it looks too odd. The do/end and the curly bracket syntaxes are used
> in different places -- if I needed error handling, I would never use the
> curly brackets anyway.

I'm not sure I get that distinction -- I mean, I understand that you
do it that way, but I'm not sure there's any generally closer
association between do/end and rescuing than there is between {} and
rescuing.  Also, they're sometimes used in the *same* places, but by
different people :-)


David
Eric H. (Guest)
on 2006-05-19 01:24
(Received via mailing list)
On May 18, 2006, at 12:58 PM, Daniel S. wrote:

> are used in different places
Not true.  do/end and {/} are interchangeable except you may need to
add () for precedence.

--
Eric H. - removed_email_address@domain.invalid - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
Daniel S. (Guest)
on 2006-05-19 01:27
(Received via mailing list)
removed_email_address@domain.invalid wrote:
> I'm not sure I get that distinction -- I mean, I understand that you
> do it that way, but I'm not sure there's any generally closer
> association between do/end and rescuing than there is between {} and
> rescuing.  Also, they're sometimes used in the *same* places, but by
> different people :-)

Maybe it's time we make that distinction. From a syntactical point of
view, they're very different -- only the keyword/end syntax really
allows for such things as if/elsif/else/end and rescue clauses, unless
you want to add this to Ruby:

   proc { foo } rescue { bar } ensure { baz }

Which in my opinion is just too verbose.

I like the curly syntax as a shorthand, but I don't think we need it to
support all the same things the more "flexible" do/end syntax does.


Daniel
Eric H. (Guest)
on 2006-05-19 01:46
(Received via mailing list)
On May 18, 2006, at 11:22 AM, Jim W. wrote:

> Eric H. wrote:
>> Setting up and tearing down an exception handler for every block
>> invocation is going to be expensive.
>
> Couldn't the setup/teardown be done only if a rescue/ensure clause was
> actually present?  It also seems to me that this would mean the the
> setup/teardown would have to be in the block itself, not in the
> calling
> method.

I forgot that the parser will just take care of it.  The patch was
easy, applies to a recentish copy of the 1.8 branch:
Eric H. (Guest)
on 2006-05-19 01:55
(Received via mailing list)
On May 18, 2006, at 2:24 PM, Daniel S. wrote:

> removed_email_address@domain.invalid wrote:
>> I'm not sure I get that distinction -- I mean, I understand that you
>> do it that way, but I'm not sure there's any generally closer
>> association between do/end and rescuing than there is between {} and
>> rescuing.  Also, they're sometimes used in the *same* places, but by
>> different people :-)
>
> Maybe it's time we make that distinction. From a syntactical point
> of view, they're very different

parse.y disagrees with you.

--
Eric H. - removed_email_address@domain.invalid - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
Daniel S. (Guest)
on 2006-05-19 02:33
(Received via mailing list)
Eric H. wrote:
>> view, they're very different
>
> parse.y disagrees with you.

That's implementation. We ought to be able to abstract away from that,
right? Isn't Ruby about the programmer, not the computer?


Daniel
Austin Z. (Guest)
on 2006-05-19 02:49
(Received via mailing list)
On 5/18/06, Daniel S. <removed_email_address@domain.invalid> wrote:
>
> I think it looks too odd. The do/end and the curly bracket syntaxes are
> used in different places -- if I needed error handling, I would never
> use the curly brackets anyway. I see the problem, though; I just don't
> think it's big enough to block the implementation of this.

No, they're not used in different places, not really.

I know some people use {} for one-liners and do/end for
multiple-liners, but sometimes it is important to use one over the
other because of the binding precedence.

  foo bar {} # the block binds with bar
  foo bar do end # the block binds with foo

If you're going to have it for do/end, you need it for {}, too.

-austin
Eric H. (Guest)
on 2006-05-19 02:52
(Received via mailing list)
On May 18, 2006, at 3:32 PM, Daniel S. wrote:
>>>> different people :-)
>>>
>>> Maybe it's time we make that distinction. From a syntactical
>>> point of view, they're very different
>> parse.y disagrees with you.
>
> That's implementation. We ought to be able to abstract away from
> that, right? Isn't Ruby about the programmer, not the computer?

No, ruby itself directly contradicts you.  The language defines only
one difference between {/} and do/end, precedence.  Increasing the
differences will make ruby more about the computer than the
programmer because you must remember what to put where to please the
interpreter.  Adding syntax is usually makes the language more
complicated and that can only be bad.

--
Eric H. - removed_email_address@domain.invalid - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
Austin Z. (Guest)
on 2006-05-19 02:52
(Received via mailing list)
On 5/18/06, Daniel S. <removed_email_address@domain.invalid> wrote:
> removed_email_address@domain.invalid wrote:
> > I'm not sure I get that distinction -- I mean, I understand that you
> > do it that way, but I'm not sure there's any generally closer
> > association between do/end and rescuing than there is between {} and
> > rescuing.  Also, they're sometimes used in the *same* places, but by
> > different people :-)
> Maybe it's time we make that distinction. From a syntactical point of
> view, they're very different -- only the keyword/end syntax really
> allows for such things as if/elsif/else/end and rescue clauses, unless
> you want to add this to Ruby:

Blocks are blocks. Stylistically, some people prefer braces, some
people prefer do/end. There are people who will do everything they can
to make sure that they always use the same style. There are people who
use {} for blocks that return a value (and the exception handler is
*very* important there) and do/end for those that don't. There are
people who use {} for one-liners and do/end for multi-liners.

The curly syntax is *not* just a shorthand. It has a different binding.

-austin
Austin Z. (Guest)
on 2006-05-19 02:52
(Received via mailing list)
On 5/18/06, Daniel S. <removed_email_address@domain.invalid> wrote:
> >> view, they're very different
> > parse.y disagrees with you.
> That's implementation. We ought to be able to abstract away from that,
> right? Isn't Ruby about the programmer, not the computer?

Yes, but as I said -- and I know you haven't seen it as I'm writing it
-- Ruby treats them exactly the same except for precedence. I like it
that way, personally.

-austin
Yukihiro M. (Guest)
on 2006-05-19 03:39
(Received via mailing list)
Hi,

In message "Re: Rescue clauses on do/end blocks?"
    on Fri, 19 May 2006 01:26:09 +0900, uncutstone wu
<removed_email_address@domain.invalid> writes:

|I think the syntax would be changed as below:
|        File.open('somefile') do |f|
|	  puts f.read
| 	rescue
|          puts "Can't open"
|        end

Which do you expect from above code?

(a)
        File.open('somefile') do |f|
          begin
	    puts f.read
 	  rescue
            puts "Can't open"
          end
        end

(b)
        begin
          File.open('somefile') do |f|
	    puts f.read
          end
        rescue
          puts "Can't open"
        end

It's naturally (a) from my point of view, since I know how blocks work
internally.  But as you did, many might expect (b).  This ambiguity
may become serious disadvantage.

							matz.
Austin Z. (Guest)
on 2006-05-19 04:09
(Received via mailing list)
On 5/18/06, Yukihiro M. <removed_email_address@domain.invalid> wrote:
> |I think the syntax would be changed as below:
> |        File.open('somefile') do |f|
> |         puts f.read
> |       rescue
> |          puts "Can't open"
> |        end
>
> Which do you expect from above code?

I expect (a), personally. The only thing that could confuse it is the
bit about returning or breaking from a block/proc that I *still* don't
quite understand.

-austin
Yukihiro M. (Guest)
on 2006-05-19 04:16
(Received via mailing list)
Hi,

In message "Re: Rescue clauses on do/end blocks?"
    on Fri, 19 May 2006 09:07:49 +0900, "Austin Z."
<removed_email_address@domain.invalid> writes:

|I expect (a), personally. The only thing that could confuse it is the
|bit about returning or breaking from a block/proc that I *still* don't
|quite understand.

If (a) is the case, the value from the rescue clause is used for a
block value when an exception happens.  The value from the ensure
clause is ignored always.

							matz.
Hal F. (Guest)
on 2006-05-19 04:31
(Received via mailing list)
Eric H. wrote:
>
>
I guess I assumed that it would only do the setup if the rescue
clause actually appeared. But I don't know how the parser and
such really work.


Hal
Uncutstone W. (Guest)
on 2006-05-19 07:01
Yukihiro M. wrote:
> (a)
>         File.open('somefile') do |f|
>           begin
> 	    puts f.read
>  	  rescue
>             puts "Can't open"
>           end
>         end
> (b)
>         begin
>           File.open('somefile') do |f|
> 	    puts f.read
>           end
>         rescue
>           puts "Can't open"
>         end
> It's naturally (a) from my point of view, since I know how blocks work
> internally.  But as you did, many might expect (b).  This ambiguity
> may become serious disadvantage.

I expect case a. Sorry I didn't carefully check the code I gave,  "Can't
open " should be " Can't read". That made the ambiguity.
Eric H. (Guest)
on 2006-05-19 07:22
(Received via mailing list)
On May 18, 2006, at 5:29 PM, Hal F. wrote:
>>>   end
>> [...]
>>> I'd like some feedback, and if its generally positive, I'll post
>>> an  RCR.
>> Setting up and tearing down an exception handler for every block
>> invocation is going to be expensive.
>> I vote no.
>
> I guess I assumed that it would only do the setup if the rescue
> clause actually appeared. But I don't know how the parser and
> such really work.

I misremembered what AST would be built.  The setup only occurs when
there is a rescue clause.

--
Eric H. - removed_email_address@domain.invalid - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
Robert K. (Guest)
on 2006-05-19 12:44
(Received via mailing list)
2006/5/18, Ross B. <removed_email_address@domain.invalid>:
>           # exception from File.open
>         end

No.  You still decide where to catch the exception.  You can do it
inside the block or outside.  It's just a syntactical change which
obsoletes a pair of begin end inside the block.

Kind regards

robert
Robert K. (Guest)
on 2006-05-19 12:51
(Received via mailing list)
2006/5/19, Yukihiro M. <removed_email_address@domain.invalid>:
> |        end
>         end
> It's naturally (a) from my point of view, since I know how blocks work
> internally.  But as you did, many might expect (b).  This ambiguity
> may become serious disadvantage.

Hm, I beg to differ: the "rescue" is *inside* the block so it can
catch only exceptions raised from within the block.  I for my part
would find it rather strange to expect that you can catch an exception
that was thrown because of problems opening the file. So my natural
expectation would be (a).

Kind regards

robert
Daniel S. (Guest)
on 2006-05-19 15:43
(Received via mailing list)
Robert K. wrote:
>> |       rescue
>>             puts "Can't open"
>>         end
>>
>> It's naturally (a) from my point of view, since I know how blocks work
>> internally.  But as you did, many might expect (b).  This ambiguity
>> may become serious disadvantage.
>
> Hm, I beg to differ: the "rescue" is *inside* the block so it can
> catch only exceptions raised from within the block.  I for my part
> would find it rather strange to expect that you can catch an exception
> that was thrown because of problems opening the file. So my natural
> expectation would be (a).

I'm on the same page as Robert -- I didn't even think of rescuing
exceptions raised by the method before someone here mentioned it.

Besides, Ruby's exception handling differs pretty much from other
languages, in that you can put rescue clauses on class and method
definitions.


Daniel
Daniel S. (Guest)
on 2006-05-19 15:46
(Received via mailing list)
Austin Z. wrote:
> Blocks are blocks. Stylistically, some people prefer braces, some
> people prefer do/end. There are people who will do everything they can
> to make sure that they always use the same style. There are people who
> use {} for blocks that return a value (and the exception handler is
> *very* important there) and do/end for those that don't. There are
> people who use {} for one-liners and do/end for multi-liners.
>
> The curly syntax is *not* just a shorthand. It has a different binding.

Personally, I wouldn't mind a distinction between the two. Maybe an
official convention?


Daniel
Daniel S. (Guest)
on 2006-05-19 15:49
(Received via mailing list)
Okay, if this proposal is blocked by the lack of an elegant way to add
clauses to curly bracket blocks, let's be proactive (hehe) and see if we
can't come up with one.

Off the top of my head, I thought of this:

   foo {
     bar
   } rescue {
     baz
   } ensure {
     bur
   }

which is a bit like in PHP, if I remember correctly.

  a)  Would this be implementable?
  b)  Would this be a tolerable syntax for y'all?


Daniel
Austin Z. (Guest)
on 2006-05-19 17:18
(Received via mailing list)
On 5/19/06, Daniel S. <removed_email_address@domain.invalid> wrote:
> Okay, if this proposal is blocked by the lack of an elegant way to add
> clauses to curly bracket blocks, let's be proactive (hehe) and see if we
> can't come up with one.

I don't think that it's elegant or inelegant. It's just something that
looks odd. I personally want it.

> which is a bit like in PHP, if I remember correctly.
>
>   a)  Would this be implementable?
>   b)  Would this be a tolerable syntax for y'all?

It might be implementable, but I find it intolerable.

-austin
Eric H. (Guest)
on 2006-05-19 21:10
(Received via mailing list)
On May 19, 2006, at 6:16 AM, Austin Z. wrote:
>>
>> which is a bit like in PHP, if I remember correctly.
>>
>>   a)  Would this be implementable?
>>   b)  Would this be a tolerable syntax for y'all?
>
> I find it intolerable.

Agreed.

--
Eric H. - removed_email_address@domain.invalid - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
Daniel S. (Guest)
on 2006-05-19 21:29
(Received via mailing list)
Eric H. wrote:
>>>    foo {
>>>      bar
>>>    } rescue {
>>>      baz
>>>    } ensure {
>>>      bur
>>>    }
>> I find it intolerable.
> Agreed.

I don't think it's pretty, either. But you seem very keen on destroying
this proposal -- you say you need a way to add rescue clauses to curly
bracket blocks, and when I present one, you just dismiss it.

I'd like you to be more constructive here.

  1.  Do we *really* need to allow rescue clauses
      on curly bracket blocks?

  2.  If yes, what syntax would you propose?

Personally, I don't think we need it. Curly brackets don't look like
begin/end, class/end, or def/end at all; do/end does. I've tried adding
a rescue clause to a do/end block, expecting it to work, I've never done
that with curly brackets blocks.


Daniel
Eric H. (Guest)
on 2006-05-19 21:44
(Received via mailing list)
On May 19, 2006, at 10:26 AM, Daniel S. wrote:
>
> I don't think it's pretty, either. But you seem very keen on
> destroying this proposal

I've been using Ruby for a long time, and I can count on my two hands
the number of times I've placed a begin inside a block.  This makes
my highly skeptical of your need for it.

If you read through the mailing list you'll find all syntax change
proposals meet this kind of treatment.

> -- you say you need a way to add rescue clauses to curly bracket
> blocks, and when I present one, you just dismiss it.

Probably because we don't think it is rubyish.  Note that this has
been proposed before and nobody's come up with a good-enough solution
yet.

Here's what I see as the problems with your proposal:

You omitted how you would specify which exceptions would be rescued.

} else { would be very confusing.

Your current solution looks entirely unlike ruby's current exception
catching syntax.

Your current solution looks entirely unlike any current ruby code.

--
Eric H. - removed_email_address@domain.invalid - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
Daniel S. (Guest)
on 2006-05-19 23:14
(Received via mailing list)
Eric H. wrote:
> You omitted how you would specify which exceptions would be rescued.
>
> } else { would be very confusing.
>
> Your current solution looks entirely unlike ruby's current exception
> catching syntax.
>
> Your current solution looks entirely unlike any current ruby code.

So you agree that there's no way in hell a Ruby programmer would never
try to add exception handling to curly bracket blocks? Then why oh why
must we support it? Why not just add exception handling capabilities to
do/end blocks, period -- that's where it feels natural to add rescue
clauses, anyway.

If it's possible to add clauses to do/end blocks and not {} blocks, I
don't see a problem at all.


Daniel
Hal F. (Guest)
on 2006-05-21 10:14
(Received via mailing list)
Daniel S. wrote:
>
>
> So you agree that there's no way in hell a Ruby programmer would never
> try to add exception handling to curly bracket blocks? Then why oh why
> must we support it?

Are you deliberately misunderstanding? The only agreement I saw is
that this is ugly.

> Why not just add exception handling capabilities to
> do/end blocks, period -- that's where it feels natural to add rescue
> clauses, anyway.
>
> If it's possible to add clauses to do/end blocks and not {} blocks, I
> don't see a problem at all.

That would be yet another difference between do/end and {}.

Right now, precedence is the only difference. It works well.

If we added it to do/end, we'd have to add it to {}. But heavens,
not using the insane syntax in your last message. Better to leave
it alone.

Furthermore, I question the need for this feature in the first place.


Hal
Mauricio F. (Guest)
on 2006-05-21 14:56
(Received via mailing list)
On Sun, May 21, 2006 at 03:12:03PM +0900, Hal F. wrote:
> Daniel S. wrote:
> >If it's possible to add clauses to do/end blocks and not {} blocks, I
> >don't see a problem at all.
>
> That would be yet another difference between do/end and {}.
>
> Right now, precedence is the only difference. It works well.

<unimportant-info>
For the record, there's another difference: you cannot use do/end with
BEGIN/END.

parse.y:
stmt		: kALIAS fitem {lex_state = EXPR_FNAME;} fitem
[...]
		| klBEGIN
[...]
		  '{' compstmt '}'
[...]
		| klEND '{' compstmt '}'

Not that it matters.

</unimportant-info>
Logan C. (Guest)
on 2006-05-21 22:32
(Received via mailing list)
On May 21, 2006, at 6:54 AM, Mauricio F. wrote:

> <unimportant-info>
> 		| klEND '{' compstmt '}'
>
> Not that it matters.
>
> </unimportant-info>
>
> --
> Mauricio F.  -   http://eigenclass.org   -  singular Ruby
>

Well BEGIN and END almost seem like they should be control structures
to me anyway. (Esepecially since the { } following BEGIN and END
aren't blocks (in the sense of being yield-able or convertable to a
proc)

% cat begin_proc.rb
p = lambda { puts "Hello" }
BEGIN( &p )


% ruby begin_proc.rb
-:2: parse error, unexpected '(', expecting '{'
BEGIN( &p )
       ^

I almost think the syntax should be

BEGIN
   ...
end

END
   ...
end

Although that does look really odd, esp. for END.

Since we use "ensure" for exceptions, that frees up finally. Why not

initially
   ...
end

and

finally
  ...
end
Hal F. (Guest)
on 2006-05-22 00:05
(Received via mailing list)
Mauricio F. wrote:
>
> For the record, there's another difference: you cannot use do/end with
> BEGIN/END.

I never knew that. Is there an obvious reason I'm not seeing?

Hal
Yukihiro M. (Guest)
on 2006-05-22 03:16
(Received via mailing list)
Hi,

In message "Re: Curly brackets"
    on Mon, 22 May 2006 05:02:37 +0900, Hal F.
<removed_email_address@domain.invalid> writes:

|> For the record, there's another difference: you cannot use do/end with
|> BEGIN/END.
|
|I never knew that. Is there an obvious reason I'm not seeing?

Since it's from AWK, I honored the AWK syntax, and saw no need to
support do..end.  Consistency?  Nah.

							matz.
Austin Z. (Guest)
on 2006-05-24 20:50
(Received via mailing list)
On 5/19/06, Daniel S. <removed_email_address@domain.invalid> wrote:
> I don't think it's pretty, either. But you seem very keen on destroying
> this proposal -- you say you need a way to add rescue clauses to curly
> bracket blocks, and when I present one, you just dismiss it.
>
> I'd like you to be more constructive here.
>
>   1.  Do we *really* need to allow rescue clauses
>       on curly bracket blocks?

Yes.

>   2.  If yes, what syntax would you propose?

foo { bar rescue baz }

or

foo {
  bar
rescue
  baz
}

> Personally, I don't think we need it. Curly brackets don't look like
> begin/end, class/end, or def/end at all; do/end does. I've tried adding
> a rescue clause to a do/end block, expecting it to work, I've never done
> that with curly brackets blocks.

If we're going to have it in do/end blocks, we need it in blocks.
Period.

-austin
This topic is locked and can not be replied to.