From: "David A. Black" <dblack@...>
Date: 2005-01-12T01:15:03+09:00
Subject: Re: Duck Typing as Pattern Matching

Hi --

On Tue, 11 Jan 2005, itsme213 wrote:

>
> "David A. Black" <dblack@wobblini.net> wrote
>>>    [x,y] = obj
>>> is the same as
>>>    x = obj[0]
>>>    y = obj[1]
>>> So I ask obj to 'do' its [0], [1] right where I want it. Variables are
> bound
>>> to results.
>>
>> Hmmm...
>>
>>    irb(main):004:0> obj = [1,2]
>>    => [1, 2]
>>    irb(main):005:0> [x,y] = obj
>>    SyntaxError: compile error
>>
>> Or did you mean: x,y = obj ?
>
> Nope. I chose syntax is currently illegal (dropping extra :: etc), to
> propose it for type + pattern for 2.0.
>
>> I don't think I'd characterize it as obj
>> "doing its [0], [1]".  You're not sending messages to obj -- not even
>> the message #[].
>
> The proposal is for
>    [x,y] = obj
> to do exactly x=obj[0]; y=obj[1].

What's gained by that, though?  It gives you a basis for an analogy
for the other stuff, but I don't see the advantage of the whole
direction, and the analogy doesn't really have persuasive weight.  It
sounds like you want:

   (join, x) = array

to mean

   x = array.join

which I think would be awfully hard to decipher.

> Isn't some type declaration facility a distinct 2.0 possibility?

Yes, though I'm hoping Matz's conservatism about change will rule it
out :-)  I've seen some interesting and thoughtful discussions of this
topic, but the vast majority of times that people have advocated type
checks/assertions/declarations, in my judgement it's been because
they're unconvinced of the soundness of the conditions that Ruby
imposes on programming.  My reaction has always been that (a) Ruby
will continue to impose those conditions; you can't do much more than
pretend they're not there, and (b) those conditions are in fact sound
already.

Mainly I root for people to keep exploring and exploring and exploring
the dynamism of Ruby, and I am convinced that *anything* that people
can latch onto that makes them feel they've defeated that dynamism
will, in fact, be latched onto in exactly that spirit.  I think that's
what would happen, and I would count it a loss.

>>> I see. Some usages of it are intentionally closer to explicit type
>>> declarations. Maybe 'duck type declarations'?
>>
>> I believe that duck typing and type declaration are two different
>> things -- i.e., that the concept of duck typing is at heart an
>> alternative to the concept of type declaration.
>
> Perhaps. I think duck-typing is about focusing on respond_to and steering
> clear of class-based tests (unless they are truly part of what a method
> requires, arguments of style aside). Duck-typing, like any strong typing,
> can be static (associated with variables and expressions) or dynamic
> (associated only with objects), or in-between (dynamically select between,
> or even generate, multiple threads of type-specialized code).

I think it's a somewhat simpler and less sweeping (though rather
profound) concept; see http://www.rubygarden.org/ruby?DuckTyping

>>> def f ( x, y )
>>>    (m1(), m2()) x
>>>    # or T x,  if T was named type defined as m1(), m2()
>>> In this case Ruby should associate the type-declared x with the
> parameter x,
>>> rather than a new local variable. Would you agree?
>>
>> In context, yes, but I'm not sold on this syntax either.
>
> Alternatives welcome, but they should allow for selected use to be
> unambiguously about type declaration.

See my #can? method in the last post.


David

-- 
David A. Black
dblack@wobblini.net