From: “Gavin Sinclair” gsinclair@soyabean.com.au
Apologies if this can of worms is better left buried.
(dog.let_lie while dog.sleep?) >
(horse.beat while horse.dead? ||
can.worms.open ||
(barn.door.open; until barn.empty? {}; barn.door.close))Hal
Inspiring. Truly.
Gavin
From: “Hal E. Fulton” hal9000@hypermetrics.com
Hello Yukihiro,
Friday, October 04, 2002, 12:19:50 PM, you wrote:
Yes. But I feel “‘:’ to indicate local” is ugly. Many (or most)
people want their block parameters “local to the block”. But “‘:’ to
indicate local” requires additional mark for common case. “‘:’ to
indicate external” is better in this sense, but this also breaks
existing code.
may be some pragma like 'use ruby1.7" can help in providing
non-compatible changes to language?
–
Best regards,
Bulat mailto:bulatz@integ.ru
So how about the “::” to indicate non-local? This does break things,
though.
a and c are local
::b and ::c refer to the enclosing environment.
array.each {|a, ::b|
c = a + ::b
::d = a - ::b
}
– Nikodemus
On Fri, 4 Oct 2002, Yukihiro Matsumoto wrote:
Yes. But I feel “‘:’ to indicate local” is ugly. Many (or most)
chestnut)
I’m not convinced that the scope of a variable is determined by the
operations applied to it. I’d have thought that scope was intrinsic to
the variable itself.
As I was initially confused that Ruby distinguished
between methods and local variables by whether it
saw an assignment or a method call first.
Tentatively I’m OK with the := idea… I’m sure
there are many pathological cases to think about,
though.
Hal
----- Original Message -----
From: “Dave Thomas” Dave@PragmaticProgrammer.com
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Saturday, October 05, 2002 12:33 PM
Subject: Re: Specifying local and external block parameters (that old
"1", with warning.
Something like this ?
pigeon% cat b.rb
#!./ruby
def a(b := 'ff')
b, i := 12, 24
[1, 2].each do |i|
b = i; b *= 2; p b
b := i; b *= 4; p b
end
p b, i
end
a
pigeon%
pigeon% b.rb
./b.rb:2: warning: useless use of `:='
./b.rb:3: warning: useless use of `:='
./b.rb:4: warning: shadowing variable `i'
./b.rb:6: warning: shadowing variable `b'
2
4
4
8
4
24
pigeon%
pigeon% make test | wc -l
make: *** [test] Error 1
254
pigeon% make test | tail
make: *** [test] Error 1
/h/nblg/ts/ruby/ts/r17/var/ruby/sample/test.rb:985: warning: shadowing variable `i'
/h/nblg/ts/ruby/ts/r17/var/ruby/sample/test.rb:991: warning: shadowing variable `i'
/h/nblg/ts/ruby/ts/r17/var/ruby/ext/syslog/test.rb:69: warning: shadowing variable `param'
/h/nblg/ts/ruby/ts/r17/var/ruby/ext/tk/lib/tk.rb:1420: warning: shadowing variable `elem'
/h/nblg/ts/ruby/ts/r17/var/ruby/ext/tk/lib/tk.rb:1531: warning: shadowing variable `conf'
/h/nblg/ts/ruby/ts/r17/var/ruby/ext/tk/lib/tk.rb:1590: warning: shadowing variable `conf'
/h/nblg/ts/ruby/ts/r17/var/ruby/ext/tk/lib/tk.rb:3718: warning: shadowing variable `slot'
/h/nblg/ts/ruby/ts/r17/var/ruby/ext/tk/lib/tk.rb:3718: warning: shadowing variable `value'
not ok iterator 5 -- /h/nblg/ts/ruby/ts/r17/var/ruby/sample/test.rb:584
test failed
pigeon%
pigeon% ruby -c lib/matrix.rb
lib/matrix.rb:598: warning: shadowing variable `i'
lib/matrix.rb:657: warning: shadowing variable `i'
Syntax OK
pigeon%
Guy Decoux
b = 12
2.times do |i|
i.times {|b| ...}
end
p b #=> ?
For me, it give
pigeon% ruby
b = 12
2.times do |i|
i.times {|b| }
-:3: warning: shadowing variable `b'
end
p b
^D
12
pigeon%
Guy Decoux
I proposed this a while back, too. In this case, though, you wouldn’t need
to specify “::b” within the block, as it was declared external to the block
in the paramter list, right:
array.each {|a, ::b|
c = a + b
::d = a - b
}
That is, unless this fall into the same category as “__var” , where we
have to specify scope at compile time (why “attr_private” won’t work).
On Fri, 4 Oct 2002 18:54:45 +0900 Nikodemus Siivola tsiivola@cc.hut.fi wrote:
a and c are local
::b and ::c refer to the enclosing environment.array.each {|a, ::b|
c = a + ::b
::d = a - ::b
}
Jim Hranicky, Senior SysAdmin UF/CISE Department |
E314D CSE Building Phone (352) 392-1499 |
jfh@cise.ufl.edu http://www.cise.ufl.edu/~jfh |
“Given a choice between a complex, difficult-to-understand, disconcerting
explanation and a simplistic, comforting one, many prefer simplistic
comfort if it’s remotely plausible, especially if it involves blaming
someone else for their problems.”
– Bob Lewis, Infoworld
here we go, down the perl road to disaster…
what happened to the ‘principle of least surprise’ in this question?
On Fri, 04 Oct 2002 17:32:01 +0000, Bulat Ziganshin wrote:
Hello Yukihiro,
Friday, October 04, 2002, 12:19:50 PM, you wrote:
Yes. But I feel “‘:’ to indicate local” is ugly. Many (or most)
people want their block parameters “local to the block”. But “‘:’ to
indicate local” requires additional mark for common case. “‘:’ to
indicate external” is better in this sense, but this also breaks
existing code.may be some pragma like 'use ruby1.7" can help in providing
non-compatible changes to language?
–
/* Name: Nikolai ‘pcp’ Weibull – Age: 22 – Born in: Chicago, IL USA *
It seems theoretically ok, but I am not wild about it. It seems to
have the combined smell of explicit and implicit about it, that I find hard
to digest.
The current behaviour may cause newcomers some surpirises, but is it really
wrong? How many cases that have been made harder or uglier to solve has it
caused? How many of those would the new behaviour fix?
– Nikodemus
On Sun, 6 Oct 2002, Hal E. Fulton wrote:
Tentatively I’m OK with the := idea… I’m sure
Hi,
In message “Re: Specifying local and external block parameters (that old chestnut)” on 02/10/06, ts decoux@moulon.inra.fr writes:
“1”, with warning.
Something like this ?
pigeon% cat b.rb
#!./ruby
def a(b := ‘ff’)
b, i := 12, 24
[1, 2].each do |i|
b = i; b *= 2; p b
b := i; b *= 4; p b
end
p b, i
end
Yes, exactly (although I was not going to allow “:=” in parameter list).
Do you mean you have implemented? Incredible.
matz.
“ts” decoux@moulon.inra.fr wrote in message
news:200210060619.g966JZL25770@moulon.inra.fr…
#!./ruby
def a(b := ‘ff’)
b, i := 12, 24
[1, 2].each do |i|
b = i; b *= 2; p b
b := i; b *= 4; p b
end
p b, i
end
I have not been following this thread, so I’m sorry if I got it wrong.
:= assigns to local block scope, = assigns to outside the local block scope.
What happens with nested scopes.
I can see that := deals with the inner block scope, but = assignement
becomes a bit vague.
I know Ruby isn’t big on declarations, but what if you declared local
variables and just used normal assignment:
attr_local :b # or just “local b”
b = 2
Thus there is always exactly one meaning of a variable and you get problems
when changing code from being a function to a block you just have to add the
local declaration in one place.
Mikkel
Yes. But I feel “‘:’ to indicate local” is ugly. Many (or most)
people want their block parameters “local to the block”. But “‘:’ to
indicate local” requires additional mark for common case. “‘:’ to
indicate external” is better in this sense, but this also breaks
existing code.may be some pragma like 'use ruby1.7" can help in providing
non-compatible changes to language?
Yes, that was I say under a different topic…
here we go, down the perl road to disaster…
what happened to the ‘principle of least surprise’ in this question?
That way
a=2
[1,2,3].map {|a| a}
puts a
CAN be avoided. So using this pragmas, new features comes more quickly
to the language. (I prefer marking “old” programs, but this would be
unfair, you don’t want to hunt for bugs in a completely written program)
It doesn’t break any working programs
Warning for changes is helpful
Anyway, say a better or quicker solution…
Gergo
±[Kontra, Gergely @ Budapest University of Technology and Economics]-+
Email: kgergely@mcl.hu, kgergely@turul.eet.bme.hu |URL: turul.eet.bme.hu/~kgergely Mobile: (+36 20) 356 9656 |
±------“Olyan langesz vagyok, hogy poroltoval kellene jarnom!”-------+
.
Magyar php mirror es magyar php dokumentacio: http://hu.php.net
Yes, exactly (although I was not going to allow ":=" in parameter list).
Do you mean you have implemented? Incredible.
If I'm right you just need to change one node when it find :=, i.e.
NODE_LASGN and NODE_DASGN is modified in NODE_DASGN_CURR and create a
block local variable (i.e. rb_dvar_push(node->nd_vid, Qnil)
Guy Decoux
The current behaviour may cause newcomers some surpirises,
May I ask, surprises to whom?
Java doesn’t let you do this at all:
int foo = 3;
if (true) {
int foo = 4;
Maybe C++ folks?
but is it really wrong?
I don’t recall ever having considered it wrong or being surprised by
it. I always use it explicitly when a variable’s value depends on an
analysis done inside an iterator:
txt_file = nil
files.each do |file|
if file =~ /.txt$/
txt_file = file
break
end
end
txt_file >> "foo.txt"
# Yes I know about Enumerable#find ;-)
Massimiliano (bard on IRC)
On Sun, Oct 06, 2002 at 09:19:25AM +0900, Nikodemus Siivola wrote:
:= assigns to local block scope,
:= assign to a variable which is always local to the block, even if a
variable with the same name exist in an outer block. For example
b = 12
1.times { b := 2 }
`b := 2' will create a new block variable which shadow the previous
variable `b'
= assigns to outside the local block scope.
= has the same meaning than actually, if a previous variable exist ruby
use this variable otherwise it create a variable local to the block
What happens with nested scopes.
same
Guy Decoux
Hello MikkelFJ,
Sunday, October 06, 2002, 6:51:01 PM, you wrote:
:= assigns to local block scope, = assigns to outside the local block scope.
i personally think that this usage will be very strange nad
untraditional. for me, it is better to use ‘=’ for constant assignment
and ‘:=’ for variable assignment, as done in algol-68 and in some
modern FP languages
–
Best regards,
Bulat mailto:bulatz@integ.ru
Hello Gergely,
Friday, October 04, 2002, 6:18:20 PM, you wrote:
Yes. But I feel “‘:’ to indicate local” is ugly. Many (or most)
people want their block parameters “local to the block”. But “‘:’ to
indicate local” requires additional mark for common case. “‘:’ to
indicate external” is better in this sense, but this also breaks
existing code.may be some pragma like 'use ruby1.7" can help in providing
non-compatible changes to language?
Yes, that was I say under a different topic…
here we go, down the perl road to disaster…
what happened to the ‘principle of least surprise’ in this question?
That way
- The bug
a=2
[1,2,3].map {|a| a}
puts a
CAN be avoided.
“documented bug becomes a feature” 
So using this pragmas, new features comes more quickly
to the language. (I prefer marking “old” programs, but this would be
unfair, you don’t want to hunt for bugs in a completely written program)
impossible. as each version of ruby can introduce new incompatible
features, it is better to mark program text which ruby language version
it uses
–
Best regards,
Bulat mailto:bulatz@integ.ru
Hi –
The current behaviour may cause newcomers some surpirises,
May I ask, surprises to whom?
Java doesn’t let you do this at all:
int foo = 3; if (true) { int foo = 4;Maybe C++ folks?
The arguments I’ve heard for having block-local variables in Ruby
more or less resolve into three:
#3 is the one that stops me from agitating too strongly against it
My main qualms about the whole thing come from the way the extra
punctuation (in the many solutions talked about) looks, as well as the
question of how problematic the underlying problem is. I guess my
inclination would just be to say, “Ruby code blocks don’t have
block-local variables. How unusual. Now, back to programming”
David
On Sun, 6 Oct 2002, Massimiliano Mirra wrote:
On Sun, Oct 06, 2002 at 09:19:25AM +0900, Nikodemus Siivola wrote:
–
David Alan Black | Register for RubyConf 2002!
home: dblack@candle.superlink.net | November 1-3
work: blackdav@shu.edu | Seattle, WA, USA
Web: http://pirate.shu.edu/~blackdav | http://www.rubyconf.com
I was referring to the argument assignment:
a = 0
[1].each { |a| … }
a == 1
– Nikodemus
On Sun, 6 Oct 2002, Massimiliano Mirra wrote:
I don’t recall ever having considered it wrong or being surprised by
it. I always use it explicitly when a variable’s value depends on an
analysis done inside an iterator:
Hi,
In message “Re: Specifying local and external block parameters (that old chestnut)” on 02/10/07, “Bulat Ziganshin” bulatz@integ.ru writes:
i personally think that this usage will be very strange nad
untraditional. for me, it is better to use ‘=’ for constant assignment
and ‘:=’ for variable assignment, as done in algol-68 and in some
modern FP languages
Could you describe “constant assignment” and “variable assignment” in
algol-68 bit more in depth?
matz.