Hi,

On Tue, 27 Apr 2004 23:39:24 +0900, Yukihiro Matsumoto wrote:

> |        func3((1, 2), 4)
> |        => [1, 4]
> |        #or maybe signal error?  not sure about this one
> 
> Making (1,2) as values is not a good idea.  

Yes, I agree that nesting values would be overcomplicating things,
and is probably too hard to implement.

> Perhaps we should prepare
> "array to values" converter (opposite of your "values" method).
> 

Isn't * an array to values converter?
(like in method(1, *[2, 3, 4]))?

> |        func2(*values(multi), 4)
> |        => [1, 2, 3, 4]
> 
> I'm still against argument splat in the middle of actual argument
> list.  It's not consistent with formal argument list, where splat is
> only allowed at the end.
> 

Sorry, I overlooked this one.

> |There may be other features of multiple assignment that could be taken
> |from argument passing, for example hash parameters(?). Other may not
> |be appropriate (i.e. blocks).
> |
> |example:
> |
> |def func6
> |  return 4, b: 5, c:6
> |end
> |
> |a, b:, **keys = func6
> |=> a == 4; b == 5; keys == {:c=>6}
> 
> I just don't feel right about this.  Maybe arguments and return values
> are different beasts in my brain, even though continuation tells us
> their similarity.
> 

Yes, it is perhaps more proof of concept than really practical.
(Being obliged to choose your variable naming wouldn't surely be 
a good idea).  Some other constructs may be more practical.
When Arrays are not the same as multiple values, the following
will not work:
a = [[1, 2], [3, 4]]
a.each { |a, b| #something useful here ...
}
that's why my idea was to have to following construct:
a.each { |*[a, b]| #something useful ...
}
and similarly:
*[a, b] = a[1]

> |*  Comparing multiple values
> |*  Unify operator
> 
> I have to confess I couldn't understand those two proposals, how they
> behave, and how they are useful.
> 
> 							matz.

The idea of comparing multiple values would be a kind of
syntactic sugar.
Instead of writing
  x == 1 && y == 2
you could write
  x, y == 1, 2
(which looks much clearer in my eyes).
In concrete it would evaluate all the expressions, and then 
compare them one by one.  The first on the left will be compared with
the first on the right, the second with the second, and so on.
When all return true, evaluate to true.

When comparing with ===, one could compare with multiple
values:
  if (1, 3, 4..5) === x
     <...>
  end
that would work like it does in case statements:
  case x 
  when 1, 3, 4..5
    <...>
  end

About the unify operator, I am not so sure myself it is
really usefull.  I just put it here for discussion.

Thanks,
Kristof