FEATURE REQUEST: 'my' local variables 
Author Message
 FEATURE REQUEST: 'my' local variables

Quote:

>|>  loop {<a, b, c|d, e, f>
>|>    ...
>|>  }
>|
>|Hmmmm. At a glance, that looks pretty confusing.
>|I'm so used to | x | that it's jarring having < a
>|| b > instead. Slight changes to the symbols used
>|might make it better.

>So, which symbols are better for them?

I was afraid you would ask. I'm hoping to avoid
re-using the <> operators, if possible. And I
would like to keep | | as surrounding operators,
rather than now having just one in the middle.
Perhaps one of the following would work. I think
I like any of them better than the original
proposal, but I don't know which ones would fit
the existing parser better, or be most Ruby-ish.

loop { | a,b,c || d,e,f |

loop { | a,b,c | local :d, :e, :f

loop { | a,b,c, ::d, ::e, ::f |

loop { | a,b,c | ::d, ::e, ::f

loop { | a,b,c | (d,e,f)

loop { | a,b,c (d,e,f) |

loop { | a,b,c | def_locals(d,e,f)

loop { | a,b,c, <d>,<e>,<f> |

loop { | a,b,c | <d,e,f>

Kevin



Thu, 28 Aug 2003 01:29:02 GMT  
 FEATURE REQUEST: 'my' local variables

Quote:


> >|>  loop {<a, b, c|d, e, f>
> >|>    ...
> >|>  }
> >|
> >|Hmmmm. At a glance, that looks pretty confusing.
> >|I'm so used to | x | that it's jarring having < a
> >|| b > instead. Slight changes to the symbols used
> >|might make it better.

> >So, which symbols are better for them?

> I was afraid you would ask. I'm hoping to avoid
> re-using the <> operators, if possible. And I
> would like to keep | | as surrounding operators,
> rather than now having just one in the middle.

I agree with this sentiment.

However, I think there is another issue which
these new block locals don't solve.

** warning: long discourse ahead **

a = 5
d = 9
:
loop{|a,b,c|<d,e,f> .... }
# need new value of d here

See, I'd possibly like to use 'd' without having to
worry whether it already exists, and still have it
available after the block.

To that, I should normally do:
a = 5
d = 9
:
d=0  # but intereferes with 'unknown' d=9
loop{|a,b,c,d|<e,f> .... }
# new 'd' is available, old 'd' is clobbered

Ah, now I still have the 'problem' of dealing
with having to know prior locals.

One possible solution that comes to mind is having the
ability to retroactively access block-local variables.

a = 5
d = 9
:
loop{|a,b,c|<d,e,f> .... d = 3; .... }
# 'd' is still 9
# need some way to access the block-local 'd'
# possibilities:
# 1) d~  (to mean from most recent block)
# 2) Local::d  (also to mean from most recent local block)
# 3) <local-block-name>::d  (from named local block)

#(3) above would imply naming local blocks:
loop{|a,b,c|<d,e,f> .... d=3; .... }~myloop
Local::myloop::d is now available with value of 3
(new problem will be in ensuring we aren't clobbering
the name of some previous block, hehe)

This might also lead to the concept of having accessors
for block-local variables. (read-only)

loop{|a,b,c| <attr :d, e,f> .... d=3; ....} etc.

But I think the way Ruby is implemented, the block-local
variables disappear after the block is over. I think
it uses 'dyna' variables and the stack.

So Ruby would probably have to be modified to somehow
save them inside some kind of scope...maybe even make
them a special kind of instance.
(regular blocks are currently not objects like they are
in Smalltalk)

I think G. Decoux could comment here...

The typical considerations of doing this would be performance
and backwards compatibility.

For that, matz might have something to say.

But as I hinted at above, using named blocks will beg
the same 'problem' of having to know previous names so
as to not clobber previous ones.
(Perhaps make ruby keep track and issue error when local
blocks are renamed, or else maybe only allow the most
recent local block to be accessed...)

** warning: additional long discourse ahead **

But even if these block locals and named local blocks
are implemented, it will not necessarily solve the 'problem'
regarding not having to know about variables, because don't
nested blocks, procs, continuations, threads, etc. have the
ability to introduce local variables you may not know
about, with or without the use of eval()?

In that case, you then would also have to be protected
from all future variables that might clobber your block
local ones from within that same block, because they
may not be using block-local vars themselves.

This past and future scoping 'problem' seems too complex
and will not be easy to fix. Fixing has less to
do with changing source code and more to do with
interface design - i.e. assuming anything we decide
could be implemented easily, it will still be very
hard to decide what should be done.

Maybe this is where some kind of "Scope by Contract"
can be used, analagous to the "Design by Contract"
concept. It would let you ensure that your local vars
are not clobbering other unknown ones, and that other
unknown ones don't clobber yours. But I do not know
how that should work, either.

Maybe it isn't a Ruby-related 'problem' at all.
Even in the business world, whenever you try claim something
as uniquely yours, you have to do a trademark/patent search ;-).

For now, I think the answer is to try to know about all
the past and nested local vars, and/or implement your
own system for ensuring nothing overlaps.

Guy N. Hurst

--
HurstLinks Web Development    http://www.hurstlinks.com/
Norfolk, VA  23510            (757)623-9688 FAX 623-0433
PHP/MySQL - Ruby/Perl - HTML/Javascript



Thu, 28 Aug 2003 03:29:59 GMT  
 FEATURE REQUEST: 'my' local variables

G> I think G. Decoux could comment here...

 I think, but probably I'm wrong, that it's too complex to implement.

 You can have local variable in block if you implement it as dynamic
variables. It's easy to do, I think, but ruby will be a little slower in
this case.

Guy Decoux



Thu, 28 Aug 2003 17:26:28 GMT  
 FEATURE REQUEST: 'my' local variables

Quote:

> ...

> ...
> >So, which symbols are better for them?

Matz's suggestion is quite acceptable (there's not much that one can't
"get used to" if its meaning is well-defined, even if it doesn't look
like what was in use before).  But one thing I like about this
particular countersuggestion of Kevin's, if I understand it properly,
...

Quote:
> loop { | a,b,c, ::d, ::e, ::f |

... is that it feels flexible, doesn't impose order in the sense of two
lists.  e.g., you could do something like ...

 | a, b, ::c, d |

... to respect whatever parameter order is suggested by other
circumstances,  while being able to specify individual scope rules.

 -- Mark



Thu, 28 Aug 2003 02:23:41 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. FEATURE REQUEST: 'my' local variables

2. Feature request: 'apply' command

3. 'local' to trap undeclared variables

4. local variables don't cause side effects

5. Global, local variables in SubVI's

6. Q: `loop' and local variables

7. un-'upvar'ing/un-'global'ing variables

8. local variable and local variable in block behave differently

9. Icons missing in 'Local' mode

10. ``vars'' declarations local to a procedure

11. Feature or Bug (F90 advance='no')

12. 'select all' feature in TK

 

 
Powered by phpBB® Forum Software