Rescue clauses on do/end blocks?

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. - [email protected] - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com

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. - [email protected] - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com

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

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.

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.

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

On May 21, 2006, at 6:54 AM, Mauricio F. wrote:

| klEND '{' compstmt '}'

Not that it matters.


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

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

Hi,

In message “Re: Curly brackets”
on Mon, 22 May 2006 05:02:37 +0900, Hal F.
[email protected] 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.

On 5/19/06, Daniel S. [email protected] 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.

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