Some comments on new 1.9 features

Matz has repeatedly said Ruby will not have indent significant blocks.
So can we pudder back to the original example?

  10.times: |x|
    x
  ;;

But now someone has said ';;' is a just a joke feature by matz? Is that
true?

T.

Quoting Domenico De Felice <defelicedomenico@gmail.com>:

Trans wrote:
[CUT]
> They would'nt *have* to be just at the top. You could even do
it
> conditionally, although usage is subtle:
>
[CUT]
> lam1 = lambda { |a, b|
> a = 2
> b = 4
> if x
> share b
> end
> }
[CUT]

Yeah.. share and local directives could be used like any other
command.. this usage is nice. It wouldn't be possible using the
special character (at least not without doing weird things).
However variables scoping, when statically defined, will still be
less intuitive than using special char.

Has anyone considered the semantics of share/local and how they
would have to be implemented?

Sure, they look cool, but they'd be a living nightmare in reality...

-mental

IIRC, ';;' was stolen from Qu language[1], which Matz also mentioned
with homonym 'qoo', the famous beverage/character.
I don't know why Matz mentioned those simultaneously, but
I can guess as it's just funny, aren't you? :wink:

[1]: http://centrin.net.id/~marc/example.html

···

On 11/5/05, Trans <transfire@gmail.com> wrote:

Matz has repeatedly said Ruby will not have indent significant blocks.
So can we pudder back to the original example?

  10.times: |x|
    x
  ;;

But now someone has said ';;' is a just a joke feature by matz? Is that
true?

T.

--
http://nohmad.sub-port.net

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?

T.

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?

-mental

···

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?

MenTaLguY 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..

···

On Sat, 2005-11-05 at 08:17 +0900, Trans wrote:

--
Domenico

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?

I am not knowledgable enough about the matter to continue. So the
feasibility beyond that is the call of some one with more experience
here, like yourself. If you think it's impossible (or virtually so)
then I have to take your word on it.

T.