Re: Why no Proc##[]=() ? Why no Proc##replace() ?

Warning: I believe this thread of msgs is rather academic. Because I
initiated it I thought it might be useful to tell you that. if you don't
enjoy academic stuff, save your time and skip this msg :-)

class Proc
   def []=(*a)
     self[*a]
   end
end

Some consequences:

At 00:53 04/05/2004 +0900, you wrote:
>On Monday 03 May 2004 7:54 am, Jean-Hugues ROBERT wrote:
> > Sometimes, a Proc is sometimes like an anonymous method, right ?
> > If assignment does not make sense for proc p,
> > then is does not make sense for method m.
> > then m.[]=( 1, x) does not make any more sense than p.[]=( 1, x)
> > Then m[1] = x does not make sense either
> > Then it is an embarrassing situation because a[1] = x does not make
> > sense... So, it has to make sense for method, and it should make sense for
> > proc too. Am I missing something ?
>
>Right. If m is a Method object, then m[1] = x doesn't make sense either.

OK. To summarize: I feel it makes sense that: class Method; def []=(*a) 
self[*a] end end
And you feel like it does not make sense (if I understand correctly).

Lets try (using Proc instead of Method, we both agree I think that a Proc
can act as an anonymous method).

# Make it so that a Proc can be a valid lvalue:
class Proc; def []=(*a) self[*a] end end

def trace_array( an_array, msg )
   proc { |*args|
     if args.length() == 1 then
        p "#{msg}: Read access at pos #{args[0]}"
        an_array[args[0]]
     elsif args.length() == 2 then
        p "#{msg}: Write access at pos #{args[0}"
        an_array[args[0]] = args[1]
     else
        p "#{msg}: Weird access."
        an_array[*args[0...-1]] = args[-1]
     end
   }
end

def buggy_meth()
   a = [1,2,3]
   a = trace_array( a, "a in buggy_meth()") if $Debug
   ... use a ...
end

In this example you can substitute a Proc where an Array was expected.
The Proc is invoked both for read and write accesses to the Array.
It outputs a msg and then performs the required operation on the Array.

This is a simple debugging tool made possible thanks to an additional
level of indirection.

With a Lvalue class that I am going to propose soon in a RCR, one
could do something similar on all lvalues, not just the [] ones:

def trace_lvalue( a_lvalue, msg )
   proc { |*args|
     if args.length() == 0 then
       p "#{msg}: Read access"
       a_lvalue
     else
       p "#{msg}: Write access"
       a_lvalue = args[0]
     end
   end
end

def buggy_meth()
   a = false
   a = trace_lvalue( ref a, "a flag in buggy_meth()") if $Debug
   ... Use a ...
end

In this example, you can substitute a Proc wherever a lvalue was
expected. The Proc is invoked both for read and write accesses to
the lvalue.

This is probably meta-programing, but I feel like I often need help
when I am chasing bugs (I make a lot of them ;-))

>m[1] = x only makes sense to me if m is an Array or a Hash or a String or
>something where it makes sense to talk about the Nth element of m. Proc and
>Method objects are not such types, in my opinion.

Fair enough.

> > That is true, it feels like treating assignment as an operation on object.
> > But it not true that Ruby treats assignment as an operation on variables,
> > it does so only for scalar object. For non scalars, arrays, hash, etc,
> > assignment is by method call (.[]=() on the non scalar object).
>
>We look at this in different ways. Let me try to explain my point of view more
>clearly.
>
>   o.a = b
>
>is to me a nicer way of saying
>
>   o.set_a(b)
>
>Which is what you'd do in Java. In Java, you can have lvalues of the form o.a
>if a is a public variable o. This is _never_ the case in Ruby, because there
>are only private instance variables.  However, Matz recognizes that it looks
>nicer if you can make attribute accessors look like public instance variables,
>so he wisely allowed for the syntax sugar to do so.
>
>If a is an Array, then:
>
>   a[i] = j
>
>means:
>
>   a.add_at_index(i, j)
>
>And similarly for Hashes and Strings. However, the semantic for [] on Proc
>and Method objects is:
>
>   a[i]  <==> a.call(i)
>
>However, I cannot think of any meaningful name for:
>
>   a[i] = j
>Which in your example turns into:
>
>   a.call(i, j)
>
>Even stranger might be:
>
>   a[i, j, k] = l, m, n  #=> becomes a.call(i, j, k, [l, m, n])

Its actually # => becomes a.call( i, j, k, l).

>In other words, for Proc and Method, [] is taken to mean "execute encapsulated
>code."  However, "execute encapsulated code equals" doesn't make sense to me,
>at least in the context of Ruby.

In Java you implement accessors using .getX() and .setX().
class MyClass
   def getX() @x end
   def setX() @x = v end
end
In Ruby the "standard" is to use x() and x=().
class MyClass
   def x() @x end
   def x=( v) @x = v end
end
It is so frequent that you have a convenience method that does it for you
class MyClass
   attr_accessor :x # defines both x() and x=()
end
Another "style" of accessors is o.x() & o.x(y):
class MyClass
   def x(*a) (a.length() == 0) ? @x : (@x = a[0]) # x() is both a getter 
and a setter
end

We both agree I think that o.x = y is a nicer syntax then o.x( y).
Only I think that p[] = y is a nicer syntax then p[y] if proc were an accessor.

Another one:
If ptr = Pointer.new(...) then p[] = x is nicer syntax (to me) than p.set( 
x) because
to me it reads "the content of p is assigned the value of x".

Not to mention: x = y versus x.set( y).

Back to block: b[] = x, to me, reads as "the content of b is assigned the 
value of x".
What that means exactly depends on the semantic of the block b.

Back to assignment:
class SomeClass
   def self.factory( *args )
     if xxx
       proc { |*a| ... }
     elsif yyy
       method( :something)
     elsif zzz
       ConcreteClassA.new( *args)
     else
       OtherConcreteClass.new( *args)
     end
   end
end
something = SomeClass.factory( xxx)
p something[0]
something[0] = 1

As a user of class SomeClass, I don't need to care about how accessors are 
implemented.
This is both encapsulation and polymorphing.

My conclusion is:
When x[ii] means "content of x" and x[ii]= y means "content of x is 
assigned the value of y",
it makes sense that x can be anything, a Method or a Block included, 
because I should
not care about that, it is up to the implementation to decide.
As a consequence it makes sense to define Proc##[]= as much as Proc##[] and
def []=(*a) self[*a] end makes sense as a default implementation.

OTOH the whole issue may be academic, because as a user, one can already:
class ProcPointer < Proc
   def []=(*a)
     self[*a]
   end
end
Which I believe is cleaner than
class Proc
   def []=(*a)
      self[*a]
   end
end
because the later one can be easily overlooked and as a result decreases the
readability of the code.
Yet, if the later one was included in Ruby, I believe the Proc class would
be more versatile.

> > This is not symetric. Ruby could always treat assignment as an operation
> > on an object. This requires: a Lvalue class and the ability to redefine
> > the assignment operator. As a result a variable could easily be an instance
> > of Lvalue and we would get closer to the motto "Everything is an object in
> > Ruby". I am currently prototyping such a Lvalue class.
>
>I don't really see how this would work.  It would require a fundamental change
>in the way variables work in Ruby.  For example, what happens when you do:
>
>   c = Foo.new
>
>If c is an Lvalue class, then the variable that c refers to becomes a new Foo
>object.  Otherwise, c becomes a new instance of Foo.  However, this means
>that all Ruby variables would have to be by-value instead of by-reference as
>they are now.

If c is_a? Lvalue then the lvalue object that c refers to (& which can be 
any lvalue,
a variable included), becomes a new Foo (which means that it now refers to 
a Foo:
c now refers to the same something but that something now refers to the new 
Foo).

However, this does not mean that all Ruby variables would have to be different
from what they are today (whatever the name you use to describe what they are
today). Only variables that holds a reference to a Lvalue object would have
to be treated differently than the "normal" variables. That's because the Ruby
interpretor would have to invoke some .getter() or .setter() method of the
Lvalue instead of using the variable's content directly (or, to rephrase more
formally, xxx instead of directly using the reference to some object that the
variable holds).

>   For example, if you did:
>
>   c = b
>
>Currently c and b refer to the same object.  In order to make your changes
>work, this would not be possible. I think this is a step backwards. It makes
>programmers think about what kind of memory they want to use (heap or
>stack, by-value or by-reference?). Not to mention that by-reference would
>be by far more used, considering Ruby has essentially _no_ by value variables
>at present and it does just fine.

I am not proposing such a radical change at all. I would rather go forward
than backward :-) What I am proposing is an additional tool, by the way of an
additional level of indirection. When the programmer need that tool it has
to be explicit and she/he would create a Lvalue object using some explicit
syntax:
b = "toto"
c = ref b # *explicit*
c = "titi"
p b # => "titi"
c is like an alias for b.

>This is all not to mention the fact that Ruby variables are untyped, so they
>need to be able to refer to amounts of memory to handle arbitrarily large
>objects.  The above scheme would require something similar to #become in
>Smalltalk.  The difference would be that for most objects, assignment would
>default to #become, rather than it being an uncommonly used method.

#become is a nice tool. But its use and abuse is programmer's responsability.

The implementation of Lvalue that I am propotyping does not use #become
(#become BTW is not yet fully available I believe, but that is not the reason).

b = "toto"
p b.object_id() # 123
c = ref b
c = "titi"
p b.object_id() # 456
If I were to use #become, b.object_id() would stay the same. It's not the
case and must not be.

As a matter of fact, I am very unsure that a Lvalue class could be implemented
at all using #become.

> > If there was a Lvalue class, and if p was to return a lvalue, then I guess
> > p.call = a, b, c
> > would be equivalent to
> > lvalue = a, b, c
> > which is equivalent to
> > lvalue = a.
> > I would then expect the lvalue to be assigned a. Either by calling
> > lvalue.=(a) or directly by the interpretor.
> >
> > But there is no Lvalue class today. The closer is a user defined Pointer
> > class: p = lambda { ... return an instance of Pointer }
> > p.call()[]= a, b, c
> > eqv p.call().[]=(a)
> >
> > As you can see, with a Pointer, you have to dereference yourself using [],
> > whereas with a Lvalue you would not.
>
>Based on what I said above, I think it's by far better to require someone to
>use a pointer class to make non-local variable assignments.  The actual need
>for them doesn't come up particularly often, and the consequences of making
>assignment object-based are, if you ask me, bad.

Then you don't mind that much that "In Ruby everything is an object, but 
variables and
... and ...".
I would prefer "In Ruby everything is an object". Introspection is a great
tool, the more, the better.

But goods and bads is all relative and its OK that our opinions
differs... My "match, assign & Lvalue" RCR should better be
*very* convincing !

> > I made 2 mistakes, self is not the Proc object, x gets scoped out.
> > r.replace { x } would work, but then r = proc { x } is more obvious.
> > I don't know how to get the current Proc object from the proc's body.
> > Any clue ?
>
>Well, in general, you'll have
>
>   r = lambda { ... }
>
>The block captures the scope in which it resides, so you can use r in the
>block to refer to the Proc itself.  That's the only way, as far as I know.

Yes, apparently it is the only way. Using it in a safe way requires some care:
begin
   r = lambda { ... use r here ... }
end
That way you are immune to further change to r, at least if r did not
exist before. A safer way:
begin
   my_own_very_specific_r_never_used_before = lambda { ... }
end

Yours,

Jean-Hugues



-------------------------------------------------------------------------
Web:  http://hdl.handle.net/1030.37/1.1
Phone: [phone]