[#9869] a block argument within a block which argument has the same name leaks — <noreply@...>

Bugs item #7680, was opened at 2007-01-08 22:53

34 messages 2007/01/08
[#9871] Re: [ ruby-Bugs-7680 ] a block argument within a block which argument has the same name leaks — Yukihiro Matsumoto <matz@...> 2007/01/08

Hi,

[#9872] Re: [ ruby-Bugs-7680 ] a block argument within a block which argument has the same name leaks — Evan Webb <evan@...> 2007/01/08

On Jan 8, 2007, at 2:30 PM, Yukihiro Matsumoto wrote:

[#9873] Re: [ ruby-Bugs-7680 ] a block argument within a block which argument has the same name leaks — Yukihiro Matsumoto <matz@...> 2007/01/08

Hi,

[#9876] Re: [ ruby-Bugs-7680 ] a block argument within a block which argument has the same name leaks — dblack@... 2007/01/09

Hi --

[#9878] Re: [ ruby-Bugs-7680 ] a block argument within a block which argument has the same name leaks — Yukihiro Matsumoto <matz@...> 2007/01/09

Hi,

[#9879] Re: [ ruby-Bugs-7680 ] a block argument within a block which argument has the same name leaks — dblack@... 2007/01/09

Hi --

[#9880] Re: [ ruby-Bugs-7680 ] a block argument within a block which argument has the same name leaks — Yukihiro Matsumoto <matz@...> 2007/01/09

Hi,

[#9882] Re: [ ruby-Bugs-7680 ] a block argument within a block which argument has the same name leaks — Evan Phoenix <evan@...> 2007/01/09

[#9885] Re: [ ruby-Bugs-7680 ] a block argument within a block which argument has the same name leaks — Yukihiro Matsumoto <matz@...> 2007/01/09

Hi,

[#9887] Re: [ ruby-Bugs-7680 ] a block argument within a block which argument has the same name leaks — Evan Phoenix <evan@...> 2007/01/09

[#9888] Re: [ ruby-Bugs-7680 ] a block argument within a block which argument has the same name leaks — Charles Oliver Nutter <charles.nutter@...> 2007/01/09

Evan Phoenix wrote:

[#9892] Re: [ ruby-Bugs-7680 ] a block argument within a block which argument has the same name leaks — Yukihiro Matsumoto <matz@...> 2007/01/09

Hi,

[#9899] Re: [ ruby-Bugs-7680 ] a block argument within a block which argument has the same name leaks — Charles Oliver Nutter <charles.nutter@...> 2007/01/10

Yukihiro Matsumoto wrote:

[#9904] Re: [ ruby-Bugs-7680 ] a block argument within a block which argument has the same name leaks — Yukihiro Matsumoto <matz@...> 2007/01/10

Hi,

[#9960] Scoping and locating definitions — Jos Backus <jos@...>

Consider the following:

17 messages 2007/01/18
[#9964] Re: Scoping and locating definitions — Pit Capitain <pit@...> 2007/01/19

Jos Backus schrieb:

[#9966] Re: Scoping and locating definitions — Jos Backus <jos@...> 2007/01/19

On Fri, Jan 19, 2007 at 06:40:03PM +0900, Pit Capitain wrote:

[#9972] Re: Scoping and locating definitions — Jos Backus <jos@...> 2007/01/19

On Sat, Jan 20, 2007 at 02:18:19AM +0900, Jos Backus wrote:

[#9996] new method dispatch rule (matz' proposal) — SASADA Koichi <ko1@...>

Hi,

50 messages 2007/01/23
[#10002] Re: new method dispatch rule (matz' proposal) — Daniel DeLorme <dan-ml@...42.com> 2007/01/23

SASADA Koichi wrote:

[#10003] Re: new method dispatch rule (matz' proposal) — Yukihiro Matsumoto <matz@...> 2007/01/23

Hi,

[#10004] Re: new method dispatch rule (matz' proposal) — James Edward Gray II <james@...> 2007/01/23

On Jan 23, 2007, at 7:41 AM, Yukihiro Matsumoto wrote:

[#10017] Re: new method dispatch rule (matz' proposal) — Daniel DeLorme <dan-ml@...42.com> 2007/01/24

Yukihiro Matsumoto wrote:

[#10018] Re: new method dispatch rule (matz' proposal) — Yukihiro Matsumoto <matz@...> 2007/01/24

Hi,

[#10024] Re: new method dispatch rule (matz' proposal) — Daniel DeLorme <dan-ml@...42.com> 2007/01/24

Yukihiro Matsumoto wrote:

[#10027] Re: new method dispatch rule (matz' proposal) — Yukihiro Matsumoto <matz@...> 2007/01/24

Hi,

[#10048] Re: new method dispatch rule (matz' proposal) — Evan Phoenix <evan@...> 2007/01/25

The more this discussion goes on, the more I worry that Joe Q Public

[#10019] stable branch policy & schedule for 1.8.6 — "Akinori MUSHA" <knu@...>

Core developers,

29 messages 2007/01/24
[#10021] Re: stable branch policy & schedule for 1.8.6 — Charles Oliver Nutter <charles.nutter@...> 2007/01/24

Akinori MUSHA wrote:

[#10032] Re: stable branch policy & schedule for 1.8.6 — Joel VanderWerf <vjoel@...> 2007/01/24

Charles Oliver Nutter wrote:

[#10085] Collaborative Ruby Language Specification — "John Lam (CLR)" <jflam@...>

Hi Everyone,

36 messages 2007/01/28
[#10108] Re: Collaborative Ruby Language Specification — Charles Oliver Nutter <charles.nutter@...> 2007/01/29

M. Edward (Ed) Borasky wrote:

[#10112] Re: Collaborative Ruby Language Specification — "Eustaquio Rangel de Oliveira Jr." <eustaquiorangel@...> 2007/01/30

-----BEGIN PGP SIGNED MESSAGE-----

[#10114] add usage of uri.userinfo to open-uri.rb — <noreply@...>

Patches item #8309, was opened at 2007-01-30 15:25

16 messages 2007/01/30
[#10131] Re: [ ruby-Patches-8309 ] add usage of uri.userinfo to open-uri.rb — Yukihiro Matsumoto <matz@...> 2007/01/31

[#10132] Re: [ ruby-Patches-8309 ] add usage of uri.userinfo to open-uri.rb — Paulo Kh <paulo.koch@...> 2007/01/31

On 2007/01/31, at 06:07, Yukihiro Matsumoto wrote:

[#10137] Re: [ ruby-Patches-8309 ] add usage of uri.userinfo to open-uri.rb — Yukihiro Matsumoto <matz@...> 2007/01/31

Hi,

[#10139] Re: [ ruby-Patches-8309 ] add usage of uri.userinfo to open-uri.rb — Sam Roberts <sroberts@...> 2007/01/31

On Thu, Feb 01, 2007 at 01:19:34AM +0900, Yukihiro Matsumoto wrote:

[#10143] Re: [ ruby-Patches-8309 ] add usage of uri.userinfo to open-uri.rb — Yukihiro Matsumoto <matz@...> 2007/02/01

Hi,

Re: String#upto edge case - empty string causes infinite loop

From: "Berger, Daniel" <Daniel.Berger@...>
Date: 2007-01-09 21:00:06 UTC
List: ruby-core #9896
> -----Original Message-----
> From: Arnaud Bergeron [mailto:abergeron@gmail.com] 
> Sent: Tuesday, January 09, 2007 1:36 PM
> To: ruby-core@ruby-lang.org
> Subject: Re: String#upto edge case - empty string causes infinite loop
> 
> 
> On 1/8/07, Berger, Daniel <Daniel.Berger@qwest.com> wrote:
> > > -----Original Message-----
> > > From: Arnaud Bergeron [mailto:abergeron@gmail.com]
> > > Sent: Monday, January 08, 2007 12:49 PM
> > > To: ruby-core@ruby-lang.org
> > > Subject: Re: String#upto edge case - empty string causes infinite 
> > > loop
> >
> > <snip>
> >
> > > Since "\377".succ yields "\001\000" I belive it would make more 
> > > sense having "".succ return "\000" and continue on from there.
> >
> > Hm, it does seem to be a tradition among other languages:
> 
> These examples are not exactly the same situation, as none of 
> these languages have the equivalent of succ for strings.
> 
> > # Perl
> > my $str = "";
> > print ++$str; # 1
> 
> Perl is the only language I'm not familiar with here, so I am 
> not really sure what happens here but I heard about automagic 
> conversion of string to numbers.
> 
> > /* C */
> > #include <stdio.h>
> >
> > int main(){
> >    char* empty = "";
> >    printf("Value: %i\n", atoi(empty) + 1); /* 1 */
> >    return 0;
> > }
> 
> Here you are explicitly converting the string to a number 
> (and due to stupidity, atoi interprets "" as being the number 
> 0).  After adding 1 it is no suprise that it prints 1.

Well, I guess my point was that atoi("") returns 0, stupid or not.
 
> > /* Java */
> > public class EmptyTest{
> >    public static void main(String[] args){
> >       String empty = "";
> >       System.out.println(empty + 1); /* 1 */
> >    }
> > }
> 
> Here you get string concatenation.  You could have written "" 
> + "1" and it would have only been more explicit.  The number 
> 1 gets converted to a string and if you concatenate that 
> string with the empty string you get "1".

Oops, right.

> The .succ function is a different beast than these examples 
> because it returns the next string in order.
> 
> > > However there might be a problem because letters are treated 
> > > differently.  "z".succ yield "aa" and not "}" and the 
> same is true 
> > > for "Z" so this might need more thought, but in my 
> opinion yielding 
> > > the empty string once is the last expected behavior.
> >
> > As you suggest, I'm not sure what repurcussions changing the return 
> > value of "".succ might have.  My approach at least has the 
> advantage 
> > of being safe in that regard.  However, I can live with either 
> > approach. It is just an edge case after all. :)
> 
> I would have it return "\000" because "" < "\000" and is the 
> lowest value for a string for which this inegality is true.  
> Having "".succ return "" breaks the implicit assuption that 
> foo < foo.succ.
> 
> irb(main):001:0> a = 1
> => 1
> irb(main):002:0> a < a.succ
> => true
> irb(main):003:0> a = ""
> => ""
> irb(main):004:0> a < a.succ
> => false

I understand your point, but I could just as well argue that there is no
logical successor to an empty string, and therefore it's a special case.
Another point to consider is that, if we have "".succ return "0", we get
this result from String#upto:

"".upto(2) => ["", "0", "1", "2"]

Either approach feels more or less arbitrary. I vote to err on the side
of caution and stick with my original patch. :)

Regards,

Dan


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.


In This Thread