On Fri, Oct 04, 2002 at 11:37:21AM +0900, Yukihiro Matsumoto wrote: > > The "solution" changes time to time in my mind. Currently I'm > thinking of the following: > > * variables assigned by ":=" should be local to the block (or > possibly local to the nearest compound statements). > > * if ":=" assignee is already defined in outer scope, it should be > warned (no -w needed, probably), and outer variable is shadowed > hereafter. Then there must be a way to turn these warnings off, because shadowing outer scope variables would be quite common IMHO. > * all local variables in block parameters (e.g. var in |var|) should > be treated as if they are assigned by ":=". other types of > variables in block parameter should be warned. What about Hal's 0.upto(99) {|frame.scroll| sleep 0.1} example? Accessors would have to be treated differently (introduces a "special case" in the language). > * scope of local variables assigned by "=" will be a nearest "body" > (method body, class body etc.) consistently. > > This does not change the appearance of Ruby code much, unlke <var> It'd make me think of Pascal :-S Just the thought of such a 'bondage-and-discipline" language could sicken more than one Rubyist :) The "utterly dynamic" vs. "so static it's useless" contrast would be too much. := does change the appearance more than the admittedly more restricted ':' prefix solution. > solution. It is incompatible to the current syntax, for example, > > a = 5 > [1,2,3].each{|a| break if a % 2 == 0} > p a > > prints "2" now. It will print "5" (with shadowing warning) if we > adopt the changes above. Since it is not compatible, it will not be > available in the near future. Perhaps you have to wait until Rite. As you say, it also breaks code, which "':' to indicate local" doesn't. -- _ _ | |__ __ _| |_ ___ _ __ ___ __ _ _ __ | '_ \ / _` | __/ __| '_ ` _ \ / _` | '_ \ | |_) | (_| | |_\__ \ | | | | | (_| | | | | |_.__/ \__,_|\__|___/_| |_| |_|\__,_|_| |_| Running Debian GNU/Linux Sid (unstable) batsman dot geo at yahoo dot com Just go ahead and write your own multitasking multiuser os! Worked for me all the times. -- Linus Torvalds