Riddle me this (a question about expressions)

ruby-talk
21

Hi --

···

On Mon, 25 Sep 2006, Rick DeNatale wrote:

On 9/24/06, dblack@wobblini.net <dblack@wobblini.net> wrote:

I am fairly certain that the return value can never be captured. At
least I can't figure out how to do it.

In this:

  def raise_value
    x = raise
  rescue
    x
  end

  p raise_value # nil

I'm pretty sure that x is nil because of the thing where the parser
sees an assignment and defines the variable. I don't think an
assignment ever actually takes place -- as witness the fact that:

   x = raise || 1

also leaves x as nil.

But try:

x = raise rescue nil || 1

Of course this is a trivial example, but the point is that raise can
in fact have a value.

Even more trivial:

   x = raise rescue 1

:slight_smile: But I'd still say that the return value of the call to raise is
not what's being captured in x.

David

--
                   David A. Black | dblack@wobblini.net
Author of "Ruby for Rails" [1] | Ruby/Rails training & consultancy [3]
DABlog (DAB's Weblog) [2] | Co-director, Ruby Central, Inc. [4]
[1] Ruby for Rails | [3] http://www.rubypowerandlight.com
[2] http://dablog.rubypal.com | [4] http://www.rubycentral.org

22

But try:

x = raise rescue nil || 1

Of course this is a trivial example, but the point is that raise can
in fact have a value.

Even more trivial:

   x = raise rescue 1

:slight_smile: But I'd still say that the return value of the call to raise is
not what's being captured in x.

Of course not :slight_smile: viz.

(x = raise) rescue 1; x #=> nil
x = (raise rescue 1); x #=> 1

and indeed it's more trivial than the case at the top of this post, I'm not
going to enumerate all possibilities of that :wink:

Bye,
Kero.

23

Well, from a syntax point of view, it sure LOOKs like the rvalue of
the assignment is the expression "raise rescue 1"

It's an interested corner of the language. Kernel#raise is a method
so it should have a value, even though unless it's rescued it causes a
non-local return.

···

On 9/25/06, dblack@wobblini.net <dblack@wobblini.net> wrote:

Hi --

On Mon, 25 Sep 2006, Rick DeNatale wrote:

> On 9/24/06, dblack@wobblini.net <dblack@wobblini.net> wrote:
>>
>> I am fairly certain that the return value can never be captured. At
>> least I can't figure out how to do it.
>>
>> In this:
>>
>> def raise_value
>> x = raise
>> rescue
>> x
>> end
>>
>> p raise_value # nil
>>
>> I'm pretty sure that x is nil because of the thing where the parser
>> sees an assignment and defines the variable. I don't think an
>> assignment ever actually takes place -- as witness the fact that:
>>
>> x = raise || 1
>>
>> also leaves x as nil.
>
> But try:
>
> x = raise rescue nil || 1
>
> Of course this is a trivial example, but the point is that raise can
> in fact have a value.

Even more trivial:

   x = raise rescue 1

:slight_smile: But I'd still say that the return value of the call to raise is
not what's being captured in x.

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

24

s/interested/interesting/

···

On 9/25/06, Rick DeNatale <rick.denatale@gmail.com> wrote:

It's an interested corner of the language.

--
Rick

25

Hi --

···

On Tue, 26 Sep 2006, Rick DeNatale wrote:

On 9/25/06, dblack@wobblini.net <dblack@wobblini.net> wrote:

Hi --

On Mon, 25 Sep 2006, Rick DeNatale wrote:

> On 9/24/06, dblack@wobblini.net <dblack@wobblini.net> wrote:
>>
>> I am fairly certain that the return value can never be captured. At
>> least I can't figure out how to do it.
>>
>> In this:
>>
>> def raise_value
>> x = raise
>> rescue
>> x
>> end
>>
>> p raise_value # nil
>>
>> I'm pretty sure that x is nil because of the thing where the parser
>> sees an assignment and defines the variable. I don't think an
>> assignment ever actually takes place -- as witness the fact that:
>>
>> x = raise || 1
>>
>> also leaves x as nil.
>
> But try:
>
> x = raise rescue nil || 1
>
> Of course this is a trivial example, but the point is that raise can
> in fact have a value.

Even more trivial:

   x = raise rescue 1

:slight_smile: But I'd still say that the return value of the call to raise is
not what's being captured in x.

Well, from a syntax point of view, it sure LOOKs like the rvalue of
the assignment is the expression "raise rescue 1"

It is; that expression evaluates to 1, and that's what x gets. But I
don't think the call to raise is, itself, returning 1.

David

--
                   David A. Black | dblack@wobblini.net
Author of "Ruby for Rails" [1] | Ruby/Rails training & consultancy [3]
DABlog (DAB's Weblog) [2] | Co-director, Ruby Central, Inc. [4]
[1] Ruby for Rails | [3] http://www.rubypowerandlight.com
[2] http://dablog.rubypal.com | [4] http://www.rubycentral.org

26

I'm still thinking a "stacked" exception might explain the behavior.
When an unrescued raise enters the exception handler, then the further
void assignment exception that you get with return never happens
because the interpreter is already in an exception context and simply
aborts before it sees the next exception (right side of assignment
evaluated first). But if the exception is rescued, the nil return from
raise is assigned (unless the value of the rescue is used, ala Kero's
example?). With return you simply break out of the context and leave
the assignment dangling, so you get the void assignment exception. That
seems to make sense...

Regards,
Jordan

27

Regardless of what happens under the covers with setjmp/longjmp, I
can't see anyway to explain the results syntactically other than
saying that the 'raise .. rescue ...' is an rvalue in the assigment.

The genesis of this thread was why the ruby compiler disallows:

     x = return y

but allows

     x = raise rescue 1

And some have expressed the opinion that both should be disallowed.

I can't agree. I think that the proper documentation of
Kernel#raise/Thread#raise should be that it causes a non-local return
unless it is rescued, in which case the value is the value of the
expression in the rescue. That's how it works now.

Of course the final arbiter is Matz.

···

On 9/25/06, dblack@wobblini.net <dblack@wobblini.net> wrote:

Hi --

On Tue, 26 Sep 2006, Rick DeNatale wrote:

> On 9/25/06, dblack@wobblini.net <dblack@wobblini.net> wrote:
>> Hi --
>>
>> On Mon, 25 Sep 2006, Rick DeNatale wrote:
>>
>> > On 9/24/06, dblack@wobblini.net <dblack@wobblini.net> wrote:
>> >>
>> >> I am fairly certain that the return value can never be captured. At
>> >> least I can't figure out how to do it.
>> >>
>> >> In this:
>> >>
>> >> def raise_value
>> >> x = raise
>> >> rescue
>> >> x
>> >> end
>> >>
>> >> p raise_value # nil
>> >>
>> >> I'm pretty sure that x is nil because of the thing where the parser
>> >> sees an assignment and defines the variable. I don't think an
>> >> assignment ever actually takes place -- as witness the fact that:
>> >>
>> >> x = raise || 1
>> >>
>> >> also leaves x as nil.
>> >
>> > But try:
>> >
>> > x = raise rescue nil || 1
>> >
>> > Of course this is a trivial example, but the point is that raise can
>> > in fact have a value.
>>
>> Even more trivial:
>>
>> x = raise rescue 1
>>
>> :slight_smile: But I'd still say that the return value of the call to raise is
>> not what's being captured in x.
>
> Well, from a syntax point of view, it sure LOOKs like the rvalue of
> the assignment is the expression "raise rescue 1"

It is; that expression evaluates to 1, and that's what x gets. But I
don't think the call to raise is, itself, returning 1.

David

--
                   David A. Black | dblack@wobblini.net
Author of "Ruby for Rails" [1] | Ruby/Rails training & consultancy [3]
DABlog (DAB's Weblog) [2] | Co-director, Ruby Central, Inc. [4]
[1] Ruby for Rails | [3] http://www.rubypowerandlight.com
[2] http://dablog.rubypal.com | [4] http://www.rubycentral.org

--
Rick

28

Hi --

Hi --

>> Hi --
>>
>> >>
>> >> I am fairly certain that the return value can never be captured. At
>> >> least I can't figure out how to do it.
>> >>
>> >> In this:
>> >>
>> >> def raise_value
>> >> x = raise
>> >> rescue
>> >> x
>> >> end
>> >>
>> >> p raise_value # nil
>> >>
>> >> I'm pretty sure that x is nil because of the thing where the parser
>> >> sees an assignment and defines the variable. I don't think an
>> >> assignment ever actually takes place -- as witness the fact that:
>> >>
>> >> x = raise || 1
>> >>
>> >> also leaves x as nil.
>> >
>> > But try:
>> >
>> > x = raise rescue nil || 1
>> >
>> > Of course this is a trivial example, but the point is that raise can
>> > in fact have a value.
>>
>> Even more trivial:
>>
>> x = raise rescue 1
>>
>> :slight_smile: But I'd still say that the return value of the call to raise is
>> not what's being captured in x.
>
> Well, from a syntax point of view, it sure LOOKs like the rvalue of
> the assignment is the expression "raise rescue 1"

It is; that expression evaluates to 1, and that's what x gets. But I
don't think the call to raise is, itself, returning 1.

Regardless of what happens under the covers with setjmp/longjmp, I
can't see anyway to explain the results syntactically other than
saying that the 'raise .. rescue ...' is an rvalue in the assigment.

I still agree with you :slight_smile: I find it interesting to look at what
raise is actually doing/returning, but clearly x gets its 1 from that
whole expression, and there's no way (that I can see) to drive a wedge
between the calling of raise and the execution of the rescue clause.

The genesis of this thread was why the ruby compiler disallows:

   x = return y

but allows

   x = raise rescue 1

And some have expressed the opinion that both should be disallowed.

I can't agree.

Neither can I. The rescue modifier is a special dispensation, but
raise is still just a method call and shouldn't cause a syntax error.

David

···

On Tue, 26 Sep 2006, Rick DeNatale wrote:

On 9/25/06, dblack@wobblini.net <dblack@wobblini.net> wrote:

On Tue, 26 Sep 2006, Rick DeNatale wrote:
> On 9/25/06, dblack@wobblini.net <dblack@wobblini.net> wrote:
>> On Mon, 25 Sep 2006, Rick DeNatale wrote:
>> > On 9/24/06, dblack@wobblini.net <dblack@wobblini.net> wrote:

--
                   David A. Black | dblack@wobblini.net
Author of "Ruby for Rails" [1] | Ruby/Rails training & consultancy [3]
DABlog (DAB's Weblog) [2] | Co-director, Ruby Central, Inc. [4]
[1] Ruby for Rails | [3] http://www.rubypowerandlight.com
[2] http://dablog.rubypal.com | [4] http://www.rubycentral.org

29

Regardless of what happens under the covers with setjmp/longjmp, I
can't see anyway to explain the results syntactically other than
saying that the 'raise .. rescue ...' is an rvalue in the assigment.

The genesis of this thread was why the ruby compiler disallows:

     x = return y

but allows

     x = raise rescue 1

And some have expressed the opinion that both should be disallowed.

I can't agree. I think that the proper documentation of
Kernel#raise/Thread#raise should be that it causes a non-local return
unless it is rescued, in which case the value is the value of the
expression in the rescue. That's how it works now.

Well, those words are sort of confusing:

begin
  @x = raise
rescue
  42
end

p @x #=> nil

@x = raise rescue 42

p @x #=> 42

To put the result into better perspective, the binding of = is to the
entire expression including the rescue, which has the result of 42
[1]. This makes much more sense as one could imagine an invisble
wrapper like:

@x = begin raise rescue 42 end

So should raise w/o the rescue be illegal? (no begin/end semantically)

Of course the final arbiter is Matz.

Agreed. I personally think that this is a rather unimportant corner
case. I'm not sure I would change anything myself.

Brian.

[1] Note that:

x = begin
  raise
resue
  42
end

p x #=> 42

···

On 9/25/06, Rick DeNatale <rick.denatale@gmail.com> wrote:

30

I think that the proper documentation of

> Kernel#raise/Thread#raise should be that it causes a non-local return
> unless it is rescued, in which case the value is the value of the
> expression in the rescue. That's how it works now.

Well, those words are sort of confusing:

begin
  @x = raise
rescue
  42
end

p @x #=> nil

@x = raise rescue 42

p @x #=> 42

No it's the same thing. The value of the lvalue in this case is the
value of raise, which since the raise was rescued is 42.

I think that my proposed documentation covers this case.

To put the result into better perspective, the binding of = is to the
entire expression including the rescue, which has the result of 42
[1].

Except in this case the only 'entire expression' which includes the rescue is:

begin; x=raise;rescue; 42;end

And x is not being assigned the value of this expression.

This makes much more sense as one could imagine an invisble
wrapper like:

@x = begin raise rescue 42 end

But I think it makes even more sense to explain the syntax as it is
rather than modifying it.

So should raise w/o the rescue be illegal? (no begin/end semantically)

Too fussy, I think.

> Of course the final arbiter is Matz.

Agreed. I personally think that this is a rather unimportant corner
case. I'm not sure I would change anything myself.

Brian.

[1] Note that:

x = begin
  raise
resue
  42
end

p x #=> 42

Again this is the same case in slightly different clothing.

The value of the begin expression is that of the last statement, which
is the raise expression, ...

···

On 9/25/06, Brian Mitchell <binary42@gmail.com> wrote:

On 9/25/06, Rick DeNatale <rick.denatale@gmail.com> wrote:

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

31

Hi --

>>Hi --
>>
>>
>>>> Hi --
>>>>
>>>>
>>>> >>
>>>> >> I am fairly certain that the return value can never be captured. At
>>>> >> least I can't figure out how to do it.
>>>> >>
>>>> >> In this:
>>>> >>
>>>> >> def raise_value
>>>> >> x = raise
>>>> >> rescue
>>>> >> x
>>>> >> end
>>>> >>
>>>> >> p raise_value # nil
>>>> >>
>>>> >> I'm pretty sure that x is nil because of the thing where the parser
>>>> >> sees an assignment and defines the variable. I don't think an
>>>> >> assignment ever actually takes place -- as witness the fact that:
>>>> >>
>>>> >> x = raise || 1
>>>> >>
>>>> >> also leaves x as nil.
>>>> >
>>>> > But try:
>>>> >
>>>> > x = raise rescue nil || 1
>>>> >
>>>> > Of course this is a trivial example, but the point is that raise can
>>>> > in fact have a value.
>>>>
>>>> Even more trivial:
>>>>
>>>> x = raise rescue 1
>>>>
>>>> :slight_smile: But I'd still say that the return value of the call to raise is
>>>> not what's being captured in x.
>>>
>>> Well, from a syntax point of view, it sure LOOKs like the rvalue of
>>> the assignment is the expression "raise rescue 1"
>>
>>It is; that expression evaluates to 1, and that's what x gets. But I
>>don't think the call to raise is, itself, returning 1.
>>
>Regardless of what happens under the covers with setjmp/longjmp, I
>can't see anyway to explain the results syntactically other than
>saying that the 'raise .. rescue ...' is an rvalue in the assigment.

I still agree with you :slight_smile: I find it interesting to look at what
raise is actually doing/returning, but clearly x gets its 1 from that
whole expression, and there's no way (that I can see) to drive a wedge
between the calling of raise and the execution of the rescue clause.

>The genesis of this thread was why the ruby compiler disallows:
>
> x = return y
>
>but allows
>
> x = raise rescue 1
>
>And some have expressed the opinion that both should be disallowed.
>
>I can't agree.

Neither can I. The rescue modifier is a special dispensation, but
raise is still just a method call and shouldn't cause a syntax error.

David

I think a more interesting question is, whether or not raise _should_ be
a method. It is a method in, Smalltalk for instance, but Smalltalk also
reifies the callstack. I agree that a method should not cause a syntax
error (in that position), but I'm not
so sure I agree with the idea that raise should be a method. But it
isn't my baby.

···

On Tue, Sep 26, 2006 at 06:24:38AM +0900, dblack@wobblini.net wrote:

On Tue, 26 Sep 2006, Rick DeNatale wrote:
>On 9/25/06, dblack@wobblini.net <dblack@wobblini.net> wrote:
>>On Tue, 26 Sep 2006, Rick DeNatale wrote:
>>> On 9/25/06, dblack@wobblini.net <dblack@wobblini.net> wrote:
>>>> On Mon, 25 Sep 2006, Rick DeNatale wrote:
>>>> > On 9/24/06, dblack@wobblini.net <dblack@wobblini.net> wrote:

--
                  David A. Black | dblack@wobblini.net
Author of "Ruby for Rails" [1] | Ruby/Rails training & consultancy [3]
DABlog (DAB's Weblog) [2] | Co-director, Ruby Central, Inc. [4]
[1] Ruby for Rails | [3] http://www.rubypowerandlight.com
[2] http://dablog.rubypal.com | [4] http://www.rubycentral.org

32

>> I think that the proper documentation of
> > Kernel#raise/Thread#raise should be that it causes a non-local return
> > unless it is rescued, in which case the value is the value of the
> > expression in the rescue. That's how it works now.
>
> Well, those words are sort of confusing:
>
> begin
> @x = raise
> rescue
> 42
> end
>
> p @x #=> nil
>
> @x = raise rescue 42
>
> p @x #=> 42

No it's the same thing. The value of the lvalue in this case is the
value of raise, which since the raise was rescued is 42.

I think that my proposed documentation covers this case.

No it doesn't. I would say that is was rescued in my example as well.
The language might look like:

Kernel#raise/Thread#raise causes a non-local return unless it is
rescued, in which case the result _of the begin..end block_ is the
result of the expression in the rescue clause.

> To put the result into better perspective, the binding of = is to the
> entire expression including the rescue, which has the result of 42
> [1].

Except in this case the only 'entire expression' which includes the rescue is:

begin; x=raise;rescue; 42;end

And x is not being assigned the value of this expression.

Actually, single line rescue has tighter bindings than =. So it would
be like I show.

x = raise rescue 42

becomes:

x = (raise rescue 42)

>This makes much more sense as one could imagine an invisble
> wrapper like:
>
> @x = begin raise rescue 42 end

But I think it makes even more sense to explain the syntax as it is
rather than modifying it.

That was my attempt. I am explaining that:

x = raise "something" rescue 42

has the same result as:

x = begin raise "something" rescue 42 end

This dispelling any doubt about what other differences might be. We
could safely use such a mechanism mentally if it happened to help us.

> So should raise w/o the rescue be illegal? (no begin/end semantically)

Too fussy, I think.

I'm not sure what you mean here. I am trying to say that it is overly
complex to think of raise as an expression which returns. It's kind of
like trying to get the result of calling a continuation; it doesn't
return one. It is much easier to use a structured interpretation where
there are begin..end clauses which happen to behave very dependably.

Brian.

···

On 9/25/06, Rick DeNatale <rick.denatale@gmail.com> wrote:

On 9/25/06, Brian Mitchell <binary42@gmail.com> wrote:
> On 9/25/06, Rick DeNatale <rick.denatale@gmail.com> wrote: