Def [](v) xx; return yy; end # returned value is ignored !?

ruby-talk
21

I have made iterator package, which does the same,
plus a few other goodies (continuation-iterator), see
http://raa.ruby-lang.org/list.rhtml?name=iterator

Only difference I see, is that you use a String, where I use a reference.
Any advantages in using a String over a reference ?

irb(main):001:0> require ‘iterator’
=> true
irb(main):002:0> a = [1,2,3]
=> [1, 2, 3]
irb(main):003:0> ptr = a.create_iterator
=> #<Iterator::Collection:0x8190324 @position=0, @data=[1, 2, 3]>
irb(main):004:0> ptr.next(2)
=> #<Iterator::Collection:0x8190324 @position=2, @data=[1, 2, 3]>
irb(main):005:0> ptr.current = 4
=> 4
irb(main):006:0> p a
[1, 2, 4]
=> nil

···

Jean-Hugues ROBERT jean_hugues_robert@yahoo.com wrote:

Ruby is cool, a lvalue can be a method call.
So when I say “lvalue” I mean Ruby’s ones, not the subset that some
other languages provide.

I believe my version of Pointer works with any Ruby valid lvalue:
a = [1,2,3]
ptr = Pointer.new{ “a[2]”}
ptr = 4
p a # => [1,2,4]
See it at end of page http://www.c2.com/cgi/wiki?SinisterSchemeSampleInRuby

–
Simon Strandgaard

22

Hi,

It may be interesting to be able to access variables indirectly
using binding() (outside eval).
for example:

a = 2
binding().local_get(:a)
=> a == 2

You can !
eval( :a, binding()) ?

I would rather get rid of the eval, because eval
has to recompile the statement, and I have the feeling it
is not really part of the language (it is more like
the language itself). From the point of a byte-code
interpreter, the eval statement doesn’t generate a
bytecode, but will call a method that will do so.

binding().local_set!(:a, 5)
=> a == 5

eval( “a = 5”) or
tmp = arbitrary_expr; eval( “a=tmp”, binding())

The behaviour would be different if a is not set.
Eval would raise an error, while local_get(:a)
would just return nil.

···

On Sat, 01 May 2004 21:07:57 +0900, Jean-Hugues ROBERT wrote:

23

Hi,

binding.local(:a) = 23 #=> 23
a #=> 23
binding.local(:a) += 19 #=> 42
a #=> 42

I wonder how you could make this work. binding.local(:a)
would have to return something that could be used as a
lvalue. I could be a reference, but the reason to have
these methods would be to avoid them.
Another way to do this:

binding.local(:a).value = 23
binding.local(:a).value += 19

binding.local(sym) would then return something like
a Variable class. It will still be possible to change
the value of a variable, but not without participation
of the calling scope.

also:

binding.eval{ self } #=> main

Also here I would remove the eval. Maybe binding.get_self or
binding.current_object?

… would be nice. I dislike having to eval strings when I need to do
some work within a certain binding; and I suppose that code blocks will
compile nicer, especially when we get a VM.

Yes, I agree. Maybe we could pack it up in a RCR?

Kristof

···

On Sun, 02 May 2004 03:08:36 +0900, Mark Hubbart wrote:

24

Hi,

binding.local(:a) = 23 #=> 23
a #=> 23
binding.local(:a) += 19 #=> 42
a #=> 42

I wonder how you could make this work. binding.local(:a)
would have to return something that could be used as a
lvalue. I could be a reference, but the reason to have
these methods would be to avoid them.
Another way to do this:

binding.local(:a).value = 23
binding.local(:a).value += 19

binding.local(sym) would then return something like
a Variable class. It will still be possible to change
the value of a variable, but not without participation
of the calling scope.

I see. I momentarily forgot that while you can use methods as lvalues,
you have to choose between lvalue and method call; you can’t assign to
it if you use the parens. I’m scrambling now for a replacement that I
like…

Perhaps:

binding[:a] = 23
binding[:a] += 19

Here’s some rather simple code that will do it:

class Binding
def
eval(sym.to_s, self)
end
def =(sym, val)
code = “#{sym} = ObjectSpace._id2ref #{val.id}”
eval(code, self)
end
end

I agree that in most cases this should be avoided. However, there are
some cases where bindings are the only way of getting things done. irb,
for example, makes extensive use of programming practices that would
otherwise be looked upon as horrific. :slight_smile: Serious violation of scoping
rules.

also:

binding.eval{ self } #=> main

Also here I would remove the eval. Maybe binding.get_self or
binding.current_object?

I guess there could be methods added for that. But I think the eval
thing should be there for more general purpose stuff. It would be
easier to remember one eval method than five fetching methods.

Also, it would be better to call it something other than ‘eval’ I
suppose. #binding_eval?

By allowing a simple way of eval’ing code within a binding like that,
you end up with a very flexible way of working with bindings.

… would be nice. I dislike having to eval strings when I need to do
some work within a certain binding; and I suppose that code blocks
will
compile nicer, especially when we get a VM.

Yes, I agree. Maybe we could pack it up in a RCR?

I think that would be a good idea; Object#instance_eval takes code
blocks; why not Kernel#eval? If Kernel#eval supported code blocks, it
would be trivial to define Binding#binding_eval.

···

On May 2, 2004, at 3:09 AM, Kristof Bastiaensen wrote:

On Sun, 02 May 2004 03:08:36 +0900, Mark Hubbart wrote:

Kristof

25

Hi,

I see. I momentarily forgot that while you can use methods as lvalues,
you have to choose between lvalue and method call; you can’t assign to
it if you use the parens. I’m scrambling now for a replacement that I
like…

Perhaps:

binding[:a] = 23
binding[:a] += 19

Yes, that looks better than my version with value.

also:

binding.eval{ self } #=> main

Also here I would remove the eval. Maybe binding.get_self or
binding.current_object?

I guess there could be methods added for that. But I think the eval
thing should be there for more general purpose stuff. It would be
easier to remember one eval method than five fetching methods.

Also, it would be better to call it something other than ‘eval’ I
suppose. #binding_eval?

By allowing a simple way of eval’ing code within a binding like that,
you end up with a very flexible way of working with bindings.

Yes, Binding#eval with a block could be very useful.
(Sorry, I think I didn’t look at your code good enough).
I would prefer Binding#eval with a block over Kernel#eval,
because it would make the meaning more clear.
Kernel#eval could be made even an alias for Binding#eval. I can see only
one problem: compilation of local-variables. Inside the eval block, any
local variables that you don’t assign to will be treated as a method-call,
and this could be annoying, because they may exist in the binding.

Kristof

···

On Sun, 02 May 2004 20:56:47 +0900, Mark Hubbart wrote:

26

I don’t understand why local variables would be treated as a method
call… They aren’t treated that way when you eval a string, correct?
is there something about the compiler that would treat the locals
differently in a block?

–Mark

···

On May 2, 2004, at 11:54 AM, Kristof Bastiaensen wrote:

binding.eval{ self } #=> main

Also here I would remove the eval. Maybe binding.get_self or
binding.current_object?

I guess there could be methods added for that. But I think the eval
thing should be there for more general purpose stuff. It would be
easier to remember one eval method than five fetching methods.

Also, it would be better to call it something other than ‘eval’ I
suppose. #binding_eval?

By allowing a simple way of eval’ing code within a binding like that,
you end up with a very flexible way of working with bindings.

Yes, Binding#eval with a block could be very useful.
(Sorry, I think I didn’t look at your code good enough).
I would prefer Binding#eval with a block over Kernel#eval,
because it would make the meaning more clear.
Kernel#eval could be made even an alias for Binding#eval. I can see
only
one problem: compilation of local-variables. Inside the eval block, any
local variables that you don’t assign to will be treated as a
method-call,
and this could be annoying, because they may exist in the binding.

27

I can see only
one problem: compilation of local-variables. Inside the eval block, any
local variables that you don’t assign to will be treated as a
method-call,
and this could be annoying, because they may exist in the binding.

I don’t understand why local variables would be treated as a method
call… They aren’t treated that way when you eval a string, correct?

Correct.

is there something about the compiler that would treat the locals
differently in a block?

–Mark

I may be wrong about this, but I think this is how it would be:
Eval compiles it’s expression at runtime. At that time it
already knows which variables are locals, and which are method-calls.
However blocks are compiled at the same time as the rest of the
program, so at that moment Ruby cannot know if an identifier is
a local variable or a method inside the given binding.

Kristof

···

On Mon, 03 May 2004 04:41:58 +0900, Mark Hubbart wrote: