From: Jean-Hugues ROBERT <jean_hugues_robert@...>
Date: 2004-04-28T13:35:02+09:00
Subject: Re: Semantics of Multiple Values (updated RCR)

At 06:54 28/04/2004 +0900, you wrote:
>Hi,
>On Wed, 28 Apr 2004 04:51:59 +0900, Jean-Hugues ROBERT wrote:
> > "unify" and "assign" work even better if a new type of
> > value is introduced (in addition to the one introduced already,
> > the one that is a & reference to a variable).
> >
> > The new type is "FreeClass", much like TrueClass. That is
> > a Singleton too.
> >
> > Q. What is it for ?
> > A. a = FreeClass.instance() is the way to "free" the "bound"
> > variable named "a". Shorthand: a = free
>
>This type already exists: NilClass, with as only
>instance nil.  In fact nil is always used for unbound variables.
>Whenever a variable isn't bound, it evaluates to nil, for all
>variables (global, object) except local.  Local variables are
>the only ones that can raise an error, the reason for this is
>that local variables and methods or interchangeable.  Whenever
>Ruby sees a local variable that didn't have an assignment before,
>it treats it as a method call.  When at runtime it executes the
>method, and cannot find it, it will give an error.

nil ? Not quite. nil is a valid value for a bound variable.
unify nil, 1 # fails

>I would suggest using := as a unification operator.  Ruby could
>then always see that what is before the operator are variables.
>It would treat nil as the unbound.

Makes sense (but a binary unify operator is more like =~= than
:=, because it works both ways, a := b eqv b := a).

syntax unify x, z makes sense too because one can also unify x, y, z

BTW: what is *after* the operator is also variables (sometimes).
Having the variables on the left side is just a trick to put the
emphasis on the fact that statement is more like assignment than
comparison.

>I am still not really convinced of the practical use of this
>operator.  I can see one usage, as initialization:

inits ? that's right, specially considering that Ruby current
initialization semantic is already a subset of unify.

>a := 0 #meaning a = 0 if (a == nil).

No. Should be:
a := 0 # meaning a = 0 if a does not exists already.
I would prefer a =~= 0 however, or unify a, 0

>perhaps the following
>
>def search_data
>   some_operation
>   return succeed, value1, value2
>end
>
>a, b = nil
>if true, a, b := search_data
>   <use a, b>
>end

another example:
if true, "a", b =~= seach_data then
   <use b>
end

>#but you may as well use
>succes, a, b = search_data

That is an example where one can see that something very
similar to a more generalized unify already exists in Ruby.
i.e. success, a, b = seach_data eqv unify [success, a, b], seach_data
I am proposing to enhance slightly what already exists.

>if(succes)
>   <use a, b>
>end

Yes, but:
success, a, b = seach_data
if success and a == "a"
   <use b>
end
is becoming verbose compared to:
if true, "a", b =~= seach_data
   <use b>
end

>There may be other real world practical uses, but I cannot think
>of any.
>Any suggestions?

Plenty. Where ever there is a combination of comparison and
assignment, unify (and/or =~=) will be less verbose.


Back to nil & free:
If you want to avoid a FreeClass, at least you need a way to free
bound variables. I suppose that a there is already enough in Ruby
today to:
   1) Check if a variable already exists
   2) "delete" it

I also suppose it is possible to prototype unify/assign today in
Ruby. I may do it. However, a user level implementation is not
going to look very nice (not mentioning performances). That is
why some support at the syntax level would help. Additionnaly,
a user level unify will not integrate well with the existing
stuff about multiple assignments and parameters passing.

def test()
   # unify [a,b], [1,2]
   unify [ ref{:a}, ref{:b} ], [1,2]
   a = Free
   unify ref{:a}, ref{:b}
end

# def mymethod( a, (b, c) ) # but using user level unify
def mymethod( *args )
   unify [ref{:a},[ref{:b},ref{:c}]], args
   ...
end

Have a look at http://onestepback.org/index.cgi/Tech/Ruby/RubyBindings.rdoc
for a definition of a Reference class and a ref{var_name} factory method.

Yours,

Jean-Hugues


-------------------------------------------------------------------------
Web:  http://hdl.handle.net/1030.37/1.1
Phone: +33 (0) 4 92 27 74 17