Return values of modifiers

This is logical, but no very useful :

irb(main):007:0> x = 10
=> 10
irb(main):008:0> x = x + 1 if false
=> nil
irb(main):009:0> x = x + 1 if true
=> 11

Idem, a while modifier always returns nil

irb(main):010:0> x += 1 while x < 15
=> nil

It would be nice to get the return value of the last instruction
*before* the test fails.

_md

···

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

Why? What use case is there that would require this or what code
would become (much) more elegant?

Note that the cost (in terms of memory) might be significant if the
expression before "while" returns a large volume of data on each
iteration. That's probably irrelevant for most cases but it may cause
a nasty memory issues in rare cases because every last value needs to
be kept for the duration of the next loop execution.

Kind regards

robert

···

2010/4/30 Michel Demazure <michel@demazure.com>:

This is logical, but no very useful :

irb(main):007:0> x = 10
=> 10
irb(main):008:0> x = x + 1 if false
=> nil
irb(main):009:0> x = x + 1 if true
=> 11

Idem, a while modifier always returns nil

irb(main):010:0> x += 1 while x < 15
=> nil

It would be nice to get the return value of the last instruction
*before* the test fails.

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

Robert Klemme wrote:

irb(main):010:0> x += 1 while x < 15
=> nil

It would be nice to get the return value of the last instruction
*before* the test fails.

Why? What use case is there that would require this or what code
would become (much) more elegant?

I was just cleaning a library and found two methods ending with
something like

  ind += 1 while <some_test>
  ind
end

and tried to get rid of the last line, quite ugly and looking
unnecessary. You're right : not *much* more elegant. But once you get
used to syntactic sugar, you'll ask for some more ... Remember Dijsktra
: "abuse of syntactic sugar gives cancer of the semi-colon".
_md

···

2010/4/30 Michel Demazure <michel@demazure.com>:

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

Hi --

Robert Klemme wrote:

irb(main):010:0> x += 1 while x < 15
=> nil

It would be nice to get the return value of the last instruction
*before* the test fails.

Why? What use case is there that would require this or what code
would become (much) more elegant?

I was just cleaning a library and found two methods ending with
something like

ind += 1 while <some_test>
ind
end

and tried to get rid of the last line, quite ugly and looking
unnecessary. You're right : not *much* more elegant. But once you get
used to syntactic sugar, you'll ask for some more ... Remember Dijsktra
: "abuse of syntactic sugar gives cancer of the semi-colon".

I don't think there's any syntactic sugar here. I always think of
syntactic sugar as "It looks like it's doing X, but it's really [or
also] doing Y." For example, x * y, where it looks like an infix
operator but is really sending a message to an object.

In the case of the while in modifier position, it looks like it's
equivalent to this:

   while <some_test>
     ind += 1
   end

and it is. I prefer this to having it be equivalent to:

   loop do x += 1; break x if <some_test>; end

David

···

On Fri, 30 Apr 2010, Michel Demazure wrote:

2010/4/30 Michel Demazure <michel@demazure.com>:

--
David A. Black, Senior Developer, Cyrus Innovation Inc.

THE Ruby training with Black/Brown/McAnally
     COMPLEAT Coming to Chicago area, June 18-19, 2010!
              RUBYIST http://www.compleatrubyist.com

David A. Black wrote:

In the case of the while in modifier position, it looks like it's
equivalent to this:

   while <some_test>
     ind += 1
   end

and it is. I prefer this to having it be equivalent to:

   loop do x += 1; break x if <some_test>; end

David

Yes, that was my point.
_md

···

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

Hi --

···

On Sat, 1 May 2010, Michel Demazure wrote:

David A. Black wrote:

In the case of the while in modifier position, it looks like it's
equivalent to this:

   while <some_test>
     ind += 1
   end

and it is. I prefer this to having it be equivalent to:

   loop do x += 1; break x if <some_test>; end

David

Yes, that was my point.

I thought you were saying you *did* want it to be equivalent to that
loop construct, rather than to the non-modifier while construct. Did I
misunderstand?

David

--
David A. Black, Senior Developer, Cyrus Innovation Inc.

THE Ruby training with Black/Brown/McAnally
     COMPLEAT Coming to Chicago area, June 18-19, 2010!
              RUBYIST http://www.compleatrubyist.com

Yes, that was my point.
_md

@David : Sorry, I misunderstood you, English is not my native tongue. I
read the opposite "I prefer it to be equivalent ...
_md

···

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

Sure, it would be nice while/until loops return value of the last iteration,
I agree.

···

On 30 April 2010 17:28:44 UTC+2, Michel Demazure <michel@demazure.com>wrote:

David A. Black wrote:

> In the case of the while in modifier position, it looks like it's
> equivalent to this:
>
> while <some_test>
> ind += 1
> end
>
> and it is. I prefer this to having it be equivalent to:
>
> loop do x += 1; break x if <some_test>; end
>
>
> David
>
Yes, that was my point.
_md
--
Posted via http://www.ruby-forum.com/\.

David A. Black wrote:

Hi --

   loop do x += 1; break x if <some_test>; end

David

Yes, that was my point.

I thought you were saying you *did* want it to be equivalent to that
loop construct, rather than to the non-modifier while construct. Did I
misunderstand?

No, you did not. This is was I suggested. But I misunderstood your first
comment, guessing you agreed with me. Sorry for the noise.
_md

···

On Sat, 1 May 2010, Michel Demazure wrote:

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

Benoit Daloze wrote:

Sure, it would be nice while/until loops return value of the last
iteration,
I agree.

This boils down to the fact that 'if false ; end' returns nil, hence
means 'do nil' and not 'do nothing' (as a comment does).

Inserting a piece of code between 'if false' and 'end' is not equivalent
to commenting it out, and does not means 'jump over it'. I feel it
should.

···

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

The parser parses it, that is all, it is never executed I fail to see
what your desired behavior is?
Cheers
R.

···

On Sat, May 1, 2010 at 8:38 AM, Michel Demazure <michel@demazure.com> wrote:

Benoit Daloze wrote:

Inserting a piece of code between 'if false' and 'end' is not equivalent
to commenting it out, and does not means 'jump over it'. I feel it
should.

--
The best way to predict the future is to invent it.
-- Alan Kay

Robert Dober wrote:

···

On Sat, May 1, 2010 at 8:38 AM, Michel Demazure <michel@demazure.com> > wrote:

Benoit Daloze wrote:

Inserting a piece of code between 'if false' and 'end' is not equivalent
to commenting it out, and does not means 'jump over it'. I feel it
should.

The parser parses it, that is all, it is never executed I fail to see
what your desired behavior is?
Cheers
R.

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

Michel Demazure wrote:

Robert Dober wrote:

Benoit Daloze wrote:

Inserting a piece of code between 'if false' and 'end' is not equivalent
to commenting it out, and does not means 'jump over it'. I feel it
should.

The parser parses it, that is all, it is never executed I fail to see
what your desired behavior is?
Cheers
R.

I would like the return value of à block 'if <false> ; ... ; end' to be
the last return value before parsing the 'if'. As if the block did not
exist, or was commented out.

···

On Sat, May 1, 2010 at 8:38 AM, Michel Demazure <michel@demazure.com> >> wrote:

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

Michel Demazure wrote:

I would like the return value of a block 'if <false> ; ... ; end' to be
the last return value before parsing the 'if'. As if the block did not
exist, or was commented out.

I am not familiar with the ruby parser. What I suggest could be just to
pop the stack when exiting from the block.
_md

···

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

That would seem very surprising to me. In general, I do not expect the
return value of an expression to be the return value of some other expression
which was in no way a part of it.

-s

···

On 2010-05-01, Michel Demazure <michel@demazure.com> wrote:

I would like the return value of à block 'if <false> ; ... ; end' to be
the last return value before parsing the 'if'. As if the block did not
exist, or was commented out.

--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
| Seebs.Net <-- lawsuits, religion, and funny pictures
Fair game (Scientology) - Wikipedia <-- get educated!

It is impossible, how could the parser continue its work??

···

On Sat, May 1, 2010 at 9:30 AM, Michel Demazure <michel@demazure.com> wrote:

Michel Demazure wrote:

I would like the return value of a block 'if <false> ; ... ; end' to be
the last return value before parsing the 'if'. As if the block did not
exist, or was commented out.

I am not familiar with the ruby parser. What I suggest could be just to
pop the stack when exiting from the block.
_md

--
The best way to predict the future is to invent it.
-- Alan Kay

Robert Dober wrote:

It is impossible, how could the parser continue its work??

OK !

···

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

What I meant is:

i = 0

=> 0

while i < 10
  i += 1
  33
  end

=> nil # should be 33

This is already the case for class Foo..end, and if/unless

It should be for the loops too (without explicit break).

And when the condition is wrong and then the "block" is never used,
then nil should be returned.

What do you think?

Benoit Daloze wrote:

What I meant is:

i = 0

=> 0

while i < 10
  i += 1
  33
  end

=> nil # should be 33

This is already the case for class Foo..end, and if/unless

It should be for the loops too (without explicit break).

And when the condition is wrong and then the "block" is never used,
then nil should be returned.

What do you think?

Benoit, if you have only
i = 0
while i < 10
   i += 1
end
which is the same as
i = 0
while i < 10
   i += 1
   i
end
then it should return 10, as I wanted ?
_md

···

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

Sure, that's my point.

(But I think the 'if/unless' behavior is correct and "foo if false"
should return nil as it is)

···

2010/5/1 Michel Demazure <michel@demazure.com>:

Benoit Daloze wrote:

What I meant is:

i = 0

=> 0

while i < 10
i += 1
33
end

=> nil # should be 33

This is already the case for class Foo..end, and if/unless

It should be for the loops too (without explicit break).

And when the condition is wrong and then the "block" is never used,
then nil should be returned.

What do you think?

Benoit, if you have only
i = 0
while i < 10
i += 1
end
which is the same as
i = 0
while i < 10
i += 1
i
end
then it should return 10, as I wanted ?
_md