Ruby-dev summary 17252-17356

ruby-talk
1

Hi all,

This is a summary of ruby-dev ML in these days.

---- ruby-dev #17252-17356 (2002-06-01 … 2002-06-07) ----

[ruby-dev:17228] ((1.2)…(3.4)).to_a (contd.)

Conclusion: (from ChangeLog)

···

Thu May 30 12:52:42 2002 Yukihiro Matsumoto matz@ruby-lang.org

* range.c (range_step): iteration done using "+" if elements are
  Numeric.  Otherwise using "succ".

* range.c (range_each): iteration done using "succ".  If the
  elements does not respond to "succ", raise TypeError.  As a
  result, all Enumerable methods, e.g. collect, require elements
  to respond to "succ".

* range.c (range_member): comparison done using "each", if
  elements are non-Numeric or no-"succ" objects.  Otherwise
  compare using "<=>".

* range.c (Init_Range): remove "size" and "length".

[ruby-dev:17271] IO#stat

Wakou Aoyama has asked why IO#stat exists, instead of File#stat.
Matz’s answer: Ruby is based on UNIX. IO represents UNIX’s file
descripter, so IO#stat is natural.

[ruby-dev:17276] blocks and local variables

Takaaki Tateishi has requested “true” block local variable.

  • Backward compatibility takes precedence over all.

  • The problem is that block localization may be broken with
    name collision between inside of the block and the outside.

  • It is not true that ruby does not have block local variables.
    The problem is that local variables does NOT shadows outer
    local variables.

  • We must think about both of block parameters and block local
    variables. e.g.

    lambda {|a| # a is block parameter.
    b = nil # b is block variable.
    }

  • a candidate of declaration of block local parameter

    lambda { # a is block patemeter which is block local
    …
    }

  • There’s two strategies to declare that variables are block local.
    (1) using block parameter declarations. e.g.

    lambda {<a,b,c; x,y> # x, y is block local
    …
    }

    (2) using special form of assignment

    x := nil # x is block local

This issue is still open.

[ruby-dev:17329] parsedate: extend or not

Tadayoshi Funaba wants public comments on his library, parsedate.rb.
Current parsedate.rb does “U.S. friendly” parsing, and non-few
people want support of their own locales. But it is impossible to
support all local formats at the same time. At least we will have
to tell desired formats to the parser. Note that single locale
system is useless here, because we will want to parse more than
one format at the same time.

Should we extend the library, or keep the library simple?

2

Minero Aoki wrote:

  • There’s two strategies to declare that variables are block local.
    (1) using block parameter declarations. e.g.

    lambda {<a,b,c; x,y> # x, y is block local
    …
    }

Is there any reason this syntax wouldn’t work?

    lambda {|a,b,c; x,y| ...

It seems more conservative.

3

Should we perhaps take a vote and see how many folks have ruby
programs that depend on block parameters referencing outer variables?

I’ve always treated block variables as block local – perhaps breaking
backwards compatibility won’t have such a huge impact.

···

On Tue, 11 Jun 2002 13:20:03 +0900 “Minero Aoki” aamine@mx.edit.ne.jp wrote:

  • Backward compatibility takes precedence over all.

  • The problem is that block localization may be broken with
    name collision between inside of the block and the outside.

  • It is not true that ruby does not have block local variables.
    The problem is that local variables does NOT shadows outer
    local variables.

Jim Hranicky, Senior SysAdmin UF/CISE Department |
E314D CSE Building Phone (352) 392-1499 |
jfh@cise.ufl.edu http://www.cise.ufl.edu/~jfh |

4

Hi,

···

In message “Re: ruby-dev summary 17252-17356” on 02/06/11, Joel VanderWerf vjoel@PATH.Berkeley.EDU writes:

  • There’s two strategies to declare that variables are block local.
    (1) using block parameter declarations. e.g.

    lambda {<a,b,c; x,y> # x, y is block local
    …
    }

Is there any reason this syntax wouldn’t work?

   lambda {|a,b,c; x,y| ...

It seems more conservative.

In case we choose <a,b,c; x,y> form, |a,b,c; x,y| will perhaps be
available too.

						matz.
5

Hi,

Should we perhaps take a vote and see how many folks have ruby
programs that depend on block parameters referencing outer variables?

My codes sometimes do it.

I’ve always treated block variables as block local – perhaps breaking
backwards compatibility won’t have such a huge impact.

Maybe.

···

At Wed, 12 Jun 2002 09:19:46 +0900, James F.Hranicky jfh@cise.ufl.edu wrote:

–
Nobu Nakada

6

“James F.Hranicky” jfh@cise.ufl.edu writes:

Should we perhaps take a vote and see how many folks have ruby
programs that depend on block parameters referencing outer variables?

sum = 0
arr.each { |a| sum += a }
p sum

(Very common before #inject came along…)

7

I don’t think I agree.

Bear in mind that these don’t have to be
simple variables. Because multiple assignment
is used, they can be any “assignable” entity,
even a “setter” (method=) for an object.

Someone once posted an example like:

1.upto(100) {|scrollbar.value| sleep 0.1 }

Kind of neat, and I’d hate to break this kind
of orthoganality.

Devil’s advocate: On the other hand, we aren’t
actually talking about removing functionality,
just changing syntax… and it’s the sort of
thing that we could generate a warning for, or
even create a tool to find the cases and update
them.

Hal Fulton

···

----- Original Message -----
From: “James F.Hranicky” jfh@cise.ufl.edu
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Tuesday, June 11, 2002 7:19 PM
Subject: Re: ruby-dev summary 17252-17356

Should we perhaps take a vote and see how many folks have ruby
programs that depend on block parameters referencing outer variables?
I’ve always treated block variables as block local – perhaps breaking
backwards compatibility won’t have such a huge impact.

8

Hello,

  • Backward compatibility takes precedence over all.

  • The problem is that block localization may be broken with
    name collision between inside of the block and the outside.

  • It is not true that ruby does not have block local variables.
    The problem is that local variables does NOT shadows outer
    local variables.

Should we perhaps take a vote and see how many folks have ruby
programs that depend on block parameters referencing outer variables?

I have some such parameters, I wish the reference would be more
obvious/readable.

I’ve always treated block variables as block local – perhaps breaking
backwards compatibility won’t have such a huge impact.

I wish block variables had been block local “by default”. I have had a few
nasty bugs with it. Now, whenever I select a name for a block variable,
I double check that it is not already in scope… boring.

What about:
xxx.each do |a, new b|
xxx
end
Where “new” asks for a fresh new b (versus the potential one already in
scope). “my” instead of “new” would be more Perlish. “local” maybe ?

Unfortunately I suspect that I would use “new/my/local” variables most of
the time and that, as a result, my code would be cluttered with it.

Had the default been the opposite (i.e. if block variables were local):
xxxx.each do | a again, b |
xxx
end
Where “again” tells that the variable a is the one from the outer scope,
if any.

BTW: I sometimes end up having code like this:
begin
my_obj = obj
xxx do
xxx my_obj xxx
end
end
I need “my_obj” because I want the value of “obj” at the time the block
was created, versus the value when the block is called. Is there a
shorter way to do this ? When the <> or |;| construction is introduced it
would be nice if it could provide an initial value for the local variables:
xxx do |x; my_obj = obj| # |x;obj = obj| |x, new obj = obj| |x, obj now|
xxx my_obj xxx # The stuff after = being evaluated when the block
end # is created, not when it is called.

BTW: I love the closure thing, but sometimes it makes me nervous that
the binding of the block results in objects being uselessly referenced ;
“ensure x = nil, y = nil, other_vars = nil” is not really a decent option,
is it ?

Jean-Hugues

···

At 09:19 12/06/2002 +0900, Jim Hranicky wrote:

On Tue, 11 Jun 2002 13:20:03 +0900 >“Minero Aoki” aamine@mx.edit.ne.jp wrote:

Web: @jhr is virteal, virtually real
Phone: +33 (0) 4 92 27 74 17

9

James F.Hranicky wrote:

  • Backward compatibility takes precedence over all.

  • The problem is that block localization may be broken with
    name collision between inside of the block and the outside.

  • It is not true that ruby does not have block local variables.
    The problem is that local variables does NOT shadows outer
    local variables.

Should we perhaps take a vote and see how many folks have ruby
programs that depend on block parameters referencing outer variables?

I would vote for local behaviour = shadowing.
And special syntax for non-shadowed:

a=nil;(1…2).each{|{a}|}; puts a # prints 2

This is since my mind wants to concern always to local behaviour.
Attention to all other non-local scopes is more painful for the mind.

I’ve always treated block variables as block local – perhaps breaking
backwards compatibility won’t have such a huge impact.

This impact can be minimized. For transition sources could declare
behaviour they want. Like in the python (which imports functionality by
declaring what you want) imho, there could be syntax for specifying
that all of this file will use behaviour of ruby1.8 (or whatever).
example:
#pragma localshadow
but many other ways are possible.

This way can be used for transition for other differences between versions.
i.e priority of parenthesis:

this does not work in ruby1.6, extra parenthesis are needed

puts (1…2).collect{|x| “#{x}”}

This also breaks some code. And new way is imho better, but transition
of some code will be required.

Problem with #pragma approach is eval. You cannot know what behaviour was
intended, but simple inheriting of caller pragmas will almost always work.

Ruby interpreter could detect where behaviour will be different (this is
relatively easy for shadowing) when run with some parameter. This will make
process of porting old way to new easy. It is also possible to use list of these
warnings to update code to new ruby version automatically.

I think that this isn’t the last change to ruby that could break some code.
Ruby needs syntax for specifying intended version behavoiur.

Jakub Travnik
jabber://jtra@jabber.com

disclaimer:
I’m not native english speaker.
At least, I’m not trying to convince you all to learn czech :wink:

···

On Tue, 11 Jun 2002 13:20:03 +0900 > “Minero Aoki” aamine@mx.edit.ne.jp wrote:

10

matz@ruby-lang.org (Yukihiro Matsumoto) writes:

In case we choose <a,b,c; x,y> form, |a,b,c; x,y| will perhaps be
available too.

Matz:

I’m not sure I understand why we’d want to change the ‘|…|’ to
“<…>”. If we don’t need to use ‘<…>’ for lexical reasons, wouldn’t
it be better to use ‘|…|’? That way we’d leave the ‘<…>’ option
free for use for some other purpose in future.

Dave

11

Hi,

···

At Wed, 12 Jun 2002 11:00:45 +0900, Dave Thomas wrote:

Should we perhaps take a vote and see how many folks have ruby
programs that depend on block parameters referencing outer variables?

sum = 0
arr.each { |a| sum += a }
p sum

(Very common before #inject came along…)

It’s another scope issue, block parameter issue means:

sum = 0
a = nil
arr.each { |a| sum += a }
p sum
p a == arr.last #=> true or false

–
Nobu Nakada

12

Perhaps not so bad – it appears to me that Ruby’s scoping rules are similar
to C++'s, that is, a declared variable exists in the declaring scope and
those below, but not above, so you’d only need “new/my/local” when you
need to enforce block-local .

int main(int atgc, char **argv)
{
int i = 3;
int j = 10;

for (i = 0; i < 10; i++)      // i references first declared i
  {
     j = 11;		  // j references first declared j
     printf("%d %d\n", i, j);
  }

printf("%d %d\n", i, j);

}

Change it to this:

int main(int atgc, char **argv)
{
int i = 3;
int j = 10;

for (int i = 0; i < 10; i++)      // i local to this scope
  {
     int j = 11;		      // j local to this scope
 int k = 42;		      // k local to this scope

 for (int q = 10 ; q < 13 ; q++) 
   {
      printf("q is %d, k is %d\n", q, k); // k references previous 
					  // scope, q local
   }

     printf("%d %d\n", i, j);
  }

printf("%d %d\n", i, j);

}

The difference is that Ruby has no explicit variable declaration like
“int i” .

This C++ style of scoping is why I haven’t ever had a problem with
block-declared variables referencing variables in the previous scope, but
I’ve always considered (erroneously) that block parameters (|x,y|) were
considered block local, with the || functioning as an explicit declaration
of a new scope.

I guess then my preference would be that || declares block local, and that
we have another way of explicitly localizing block variables, like

foo = 12
bar = 1
baz = 2

x.each { |foo| # foo is explicitly local
local bar = 10 # bar explicitly local
baz = 3 # baz references previous scope
}

As I discussed in my last post, I don’t know if there are a lot of scripts
that depend on block parameters referencing the previous scope, so I’m not
sure how important backwards compatibility is for block paramters.

My feeling is that if we implemented the above scenario, the impact would
be small enough to be worth it.

Just my $.02 .

···

On Wed, 12 Jun 2002 16:49:56 +0900 “Jean-Hugues ROBERT” jean_hugues_robert@yahoo.com wrote:

Unfortunately I suspect that I would use “new/my/local” variables most of
the time and that, as a result, my code would be cluttered with it.

Jim Hranicky, Senior SysAdmin UF/CISE Department |
E314D CSE Building Phone (352) 392-1499 |
jfh@cise.ufl.edu http://www.cise.ufl.edu/~jfh |

13

True…it would have to be rewritten as

1.upto(100) {|x| scrollbar.value = x ; sleep 0.1 }

right?

Hmmm, well, this doesn’t seem like a huge problem to me. OTOH, we
could add an operator “outer” (or something) to go along with
the “local” I and others have proposed for block variables:

1.upto(100) { |outer scrollbar.value| sleep 0.1 }

Not quite as nice.

My preference is still for || declaring block local, and having
an explicit declaration for block local parameters. I’ll live
with the final decision, though, whatever it is :->

···

On Wed, 12 Jun 2002 15:01:17 +0900 “Hal E. Fulton” hal9000@hypermetrics.com wrote:

Bear in mind that these don’t have to be
simple variables. Because multiple assignment
is used, they can be any “assignable” entity,
even a “setter” (method=) for an object.

Someone once posted an example like:

1.upto(100) {|scrollbar.value| sleep 0.1 }

Kind of neat, and I’d hate to break this kind
of orthoganality.

Jim Hranicky, Senior SysAdmin UF/CISE Department |
E314D CSE Building Phone (352) 392-1499 |
jfh@cise.ufl.edu http://www.cise.ufl.edu/~jfh |

14

Hi,

···

In message “Re: ruby-dev summary 17252-17356” on 02/06/11, Dave Thomas Dave@PragmaticProgrammer.com writes:

I’m not sure I understand why we’d want to change the ‘|…|’ to
“<…>”. If we don’t need to use ‘<…>’ for lexical reasons, wouldn’t
it be better to use ‘|…|’? That way we’d leave the ‘<…>’ option
free for use for some other purpose in future.

No, the idea was not changing, but providing both. ‘|…|’ is for the
current block parameters, which is processed by multiple assignment.
And ‘<…>’ is for function-like parameters, which is processed just
like method arguments.

						matz.
15

nobu.nokada@softhome.net writes:

Hi,

Should we perhaps take a vote and see how many folks have ruby
programs that depend on block parameters referencing outer variables?

sum = 0
arr.each { |a| sum += a }
p sum

(Very common before #inject came along…)

It’s another scope issue, block parameter issue means:

sum = 0
a = nil
arr.each { |a| sum += a }
p sum
p a == arr.last #=> true or false

True: I was incorrectly talking about the |a;sum| side of the question.

Dave

···

At Wed, 12 Jun 2002 11:00:45 +0900, > Dave Thomas wrote:

16

In that case, what does the semicolon
mean?

Hal Fulton

···

----- Original Message -----
From: “Yukihiro Matsumoto” matz@ruby-lang.org
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Tuesday, June 11, 2002 11:18 AM
Subject: Re: ruby-dev summary 17252-17356

Hi,

In message “Re: ruby-dev summary 17252-17356” > on 02/06/11, Dave Thomas Dave@PragmaticProgrammer.com writes:

I’m not sure I understand why we’d want to change the ‘|…|’ to
“<…>”. If we don’t need to use ‘<…>’ for lexical reasons, wouldn’t
it be better to use ‘|…|’? That way we’d leave the ‘<…>’ option
free for use for some other purpose in future.

No, the idea was not changing, but providing both. ‘|…|’ is for the
current block parameters, which is processed by multiple assignment.
And ‘<…>’ is for function-like parameters, which is processed just
like method arguments.

17

“Hal E. Fulton” wrote:

From: “Yukihiro Matsumoto” matz@ruby-lang.org

No, the idea was not changing, but providing both. ‘|…|’ is for the
current block parameters, which is processed by multiple assignment.
And ‘<…>’ is for function-like parameters, which is processed just
like method arguments.

In that case, what does the semicolon
mean?

The same, I would assume. Even if the parameter assignment is done like
with functions, you wouldn’t want the all variables to be local to the
block only. Function-like doesn’t mean a full-on stacklevel (I hope),
but a move away from the sometimes very confusing parallell assignment
rules that go into effect in blocks.

… if I understood the pervious posts correctly …

···

–
([ Kent Dahl ]/)_ ~ [ http://www.stud.ntnu.no/~kentda/ ]/~
))_student/(( _d L b_/ NTNU - graduate engineering - 4. year )
( __õ|õ// ) )Industrial economics and technological management(
_/ö____/ (_engineering.discipline=Computer::Technology)

18

“Hal E. Fulton” hal9000@hypermetrics.com writes:

I’m not sure I understand why we’d want to change the ‘|…|’ to
“<…>”. If we don’t need to use ‘<…>’ for lexical reasons, wouldn’t
it be better to use ‘|…|’? That way we’d leave the ‘<…>’ option
free for use for some other purpose in future.

No, the idea was not changing, but providing both. ‘|…|’ is for the
current block parameters, which is processed by multiple assignment.
And ‘<…>’ is for function-like parameters, which is processed just
like method arguments.

In that case, what does the semicolon mean?

It separates parameters from variables which are local to the block.

a = 1
i = 2
(1..10).each do |i|
  a = i*i
end

p a   #=> 100
p i   #=> 10

…

a = 1
i = 2
(1..10).each do |i;a|
  a = i*i
end

p a   #=> 1
p i   #=> 10

and I assume

a = 1
i = 2
(1..10).each do <i;a>
  a = i*i
end

p a   #=> 1
p i   #=> 2

As a somewhat tongue-in-cheek alternative (which breaks backwards
compatibility) we could have ‘do!’ which inherits variables from the
enclosing scope and ‘do’ which doesn’t…

Dave

19

“Hal E. Fulton” wrote:

From: “Yukihiro Matsumoto” matz@ruby-lang.org

No, the idea was not changing, but providing both. ‘|…|’ is for
the
current block parameters, which is processed by multiple assignment.
And ‘<…>’ is for function-like parameters, which is processed just
like method arguments.

In that case, what does the semicolon
mean?

The same, I would assume. Even if the parameter assignment is done like
with functions, you wouldn’t want the all variables to be local to the
block only. Function-like doesn’t mean a full-on stacklevel (I hope),
but a move away from the sometimes very confusing parallell assignment
rules that go into effect in blocks.

… if I understood the pervious posts correctly …

I would bet a nickel (a yen?) this is not
what Matz has in mind.

I don’t think that the parallel assignment rules
were what made this confusing, but the fact that
outside variables were used if they existed. Well,
that can be viewed as a consequence, I guess.

I doubt that we will see function-like non-local
pseudo-parameters in the future. But I could be
very wrong. :slight_smile:

Hal Fulton

···

----- Original Message -----
From: “Kent Dahl” kentda@stud.ntnu.no
Newsgroups: comp.lang.ruby
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Tuesday, June 11, 2002 4:00 PM
Subject: Re: ruby-dev summary 17252-17356

20

In that case, what does the semicolon mean?

It separates parameters from variables which are local to the block.

[snippage]

Well, Matz is much smarter than I am… but this
makes me wince.

Complaint #1: This introduces an ordering constraint on
the items. If the “natural” order is a,b,c but we need
b to be local, we will write something like |a,c;b|

Complaint #2: The <x;y> case is exceptionally annoying
to me if I understand it correctly. Doesn’t it send two
contradictory messages (to the reader) about x? The fact
that it appears on the lefthand side of the semicolon
says it’s nonlocal; but the fact it’s in brackets says
it’s local.

As a somewhat tongue-in-cheek alternative (which breaks backwards
compatibility) we could have ‘do!’ which inherits variables from the
enclosing scope and ‘do’ which doesn’t…

Sure, and let’s have { and {! also… that’s even more
tongue-in-cheek.

I still wish we could use something other than <> for the
new notation. At the least I’d prefer something that didn’t
balance left-right (as || doesn’t). But we run out of
punctuation, don’t we? On American non-APL keyboards,
anyway.

For another less-than-half-serious suggestion: I propose
we use /…/ instead of <…> How to distinguish this
from an expression starting with a regex is left as an
exercise for the parser. :wink:

Hal Fulton

···

----- Original Message -----
From: “Dave Thomas” Dave@PragmaticProgrammer.com
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Tuesday, June 11, 2002 4:07 PM
Subject: Re: ruby-dev summary 17252-17356