From: Domenico De Felice <defelicedomenico@...>
Date: 2005-11-05T17:12:09+09:00
Subject: Re: Some comments on new 1.9 features

MenTaLguY wrote:
> On Sat, 2005-11-05 at 08:17 +0900, Trans wrote:
> > > Sure, they look cool, but they'd be a living nightmare in reality...
> >
> > Would they? Wouldn't 'share' just point the closure's var to the local
> > one? And 'local' would do just the opposite, (albeit it have to create
> > the local var in that case). That seems simple enough. Or am I missing
> > something?
>
> Well, keep going.  How would this work with e.g. nested closures?
>
> Also, in terms of implementation, how would you set up the variable
> pads?
>

Maybe it could work in this way

a = 1
b = 2
c = 3

l = lambda {
   local a = 10
   share b = 20
   local c = 30
   d = 40
   e = 50

   # In all the 4 statements above, it would be allocated memory for
the variable
   # even if they were marked as being shared.
   # each variable is marked as being local, share, or unspecified
by-directive scope

   share c  # now c is marked as shared
   share d  # same for d
}

a #=> 1
b #=> 20
c #=> 30
d #=> 40
e #=> undefined

At the end of the block, the variables marked as locals would be
ignored and deallocated.
For the shared ones, if the outside variable exists, their value would
be copied there and the memory deallocated, otherwise they would be
moved in the outside context.
If the variable scope has not been specified by directive, for
backwards reasons it should behave as today programs expect: if the
outside variable with that name exists, the value would be copied
there, otherwise it would be deallocated.

This shouldn't give many problems with nested closures. However
misusing this feature would make the program difficult to understand..

--
Domenico