From: Eric Mahurin <eric_mahurin@...>
Date: 2005-10-02T15:33:23+09:00
Subject: Re: ideas for an RCR: variable locality

--- Trans <transfire@gmail.com> wrote:

> 
> Eric Mahurin wrote:
> 
> > Again, my module/end proposal would localize all variables
> > inside, but would use an external value when reading a
> local
> > variable not yet defined.  I proposed to reuse "module" to
> not
> > create a new keyword, but something else could be used.
> 
> I don't think reusing 'module' this way is a good idea.
> Modules don;t
> grad varaible from outside there scope.

I don't particularly like using the word "module" either, but I
was hoping to find a way of not adding a new keyword since
anywhere using that new keyword currently as a variable or
method name would be a problem.  Another options would be
do/end, but this could get too easily confused with a block. 
module/end seemed to be a pretty close fit because module/end
already localizes variables and executes code immediately. 
Another option would be to have another form of begin/end -
maybe "begin:"/end.  I don't know.  Or give up and have a new
keyword.

> > And on the block side, I proposed a new block format
> ({{...}})
> > which would do the same for variables inside the block.  In
> > ruby 2, the default block will have all variables scoped at
> the
> > same as what contains the block.
> 
> {{ }} is ambigous too as an empty hash in a block.

Similar ambiguity to your [] proposal.  It would depend on
spacing.  "{{" (localized block) would be treated differently
to "{ {" (hash in a block).  This could be done at the lexer -
"{{" would be a token.

It is very hard to propose anything in the block/lambda area
without something being ambiguous because of anonymous hashes.


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com