Re: Local variables & blocks (a bit long, but worth it :-)

On Sunday 02 February 2003 09:11 am, ahoward wrote:
> how about some simple means on introducing a local scope?  a new
> keyword/method?  perhaps 'scope/end' and '{{/}}'.  this could allow the
> programmer to work as wished, added to your current plan one would end up
> with
>
>  ...
>
> maybe that syntax is no good, but what would be the problem of allowing
> programmers to introduce scopes (most languages do)?  this would allow to
> the introduce your new plan, and in cases (like threads) or for people
> where it might be an imperfect fit you could say 'just introduce a scope
> and it will be as before'.  i guess one could simply use guy's 'local'
> method, but it would be nice if that were built in for people who like
> scopes.  using this, the default for thread might be to introduce a new
> scope - there are some cases where POLS means blocks should start a new
> scope.

though it would not be backwards compatilble, yet it has some merit i think, 
say if block using { } defined a new scope and  those using  do end  did not? 
--just an aside thought.

i can't help but feel that this whole problem is so thorny b/c there's some 
fundemental assumptions that have been made in Ruby that at this point make 
it hard to get past with out some sort of hack, whatever it may be.

it may be beneficial to step back and look at this. for starters i have always 
felt a bit odd about the distinction between methods and variables:

	def bar() 4 end
	puts bar
vs.
	bar = 4
	puts bar

the use of bar after definition is ISOMORPHIC. the only exception being when 
both froms are used, thus self becomes required to get to the method (the 
infamous ambiguity)

likewise Procs being distinct from methods adds fruther to the layers of 
complexity. i have often thought that doing:

	class Foo
		bar = Proc { 4 }
	end

or prefereably without the Proc (such that { } meant Proc inheritly)

	class Foo
		bar = { 4 }
	end

would make for a reasonable means of defining a method, equiv. to

	class Foo
		def bar
			4
		end
	end

(hence i never liked the #call method) but anyhow, what's this to do with 
local scope? well, the "pure" idea of a scope is to shelter the inner-context 
from the outer-context. thus generally, no outer definition should get in, 
and all such out-definitions that one might want inside an inner-scope would 
have to be passed in.

	bar =  4
	non = { |bar| bar + 1}  # hey, these are not the same bar
	puts non(bar)  # bar ain't getting in unless passed.

the only "pure OO" way to get around this would be to offer an object 
reference to the previous scope.

	bar = 4
	non = { last_scope.bar + 1}  # now they the same
	puts non

some sytatical suger might help: non = { &bar + 1 }

but the lack of distiction between method and variable make it clearer, i 
think, where scopes are coming from. normally with,

	class Foo
		def bar() 4 end
		def non() bar end
	end

defines only a partial scope, if we wrote:

	class Foo
		bar = { 4 }
		non = { bar }
	end

we might actually consider if bar should actually be seen at all in non, but 
this would lead to a lot of the above & use. imagine having to write:

	class Foo
		def bar() 4 end
		def non() &bar end
	end

so, we end up in a fight between what's visible everywhere throughout the 
scope of an object, sort of like object localized globals, and what's truly 
local to blocks and methods. that's really the bottom line.

what syntax do you use to draw that line?

-transami

p.s. though i know that taking greater advatage of isomprophism with variables 
and methods is quite a departure from today's Ruby, i none the less think it 
one to think carefully about and would like to hear what others think of it 
and how it might effect the language over all.

-- 
tom sawyer, aka transami
[e-mail]