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

Hi --

On Wed, 12 Jan 2005, itsme213 wrote:

> "David A. Black" <dblack@wobblini.net> wrote
>>> The proposal is for
>>>    [x,y] = obj
>>> to do exactly x=obj[0]; y=obj[1].
>>
>> What's gained by that, though?
>
> In a method signature
>    def  m  [start,end]
> is more informative than
>    def  m obj
> or
>    def m start_end
>
> The first tells me I have to pass in something from which start can be
> extracted with [0], and end with [1].

I continue not to believe that this can be determined at run time,
without essentially doing everything that you'd have to do anyway.
For example:

    class C
      def initialize
        @proxy = []
      end

      def method_missing(*args)
        handle(*args)
      end

      private
      def handle(*args)
        @proxy.send(*args)
      end
    end

From the duck-typing perspective, a C object is 100% capable of
responding to []= and [].  But from any other perspective -- i.e.,
other than simply asking the object to do it -- it isn't.  And this is
just one small example....  This is the kind of thing that leads me to
believe that type assertions of pretty much any kind are fundamentally
out of place in the Ruby landscape.

> And if available in method signatures,
> it should be available other places where variables get bound, like
> assignment, for-loops, ...

Maybe, though I don't think it's self-evident that all
variables-getting-bound semantics have to be the same as each other.
There might be other things to factor in; for example, in method
signatures there the special case of &block.

> I know that Ruby's just_in_time duck typing safety check is sound. But I
> also believe access to duck-typing information can be used for many several
> purposes besides just to check on every call.

Again, I would describe this as type information, not duck-type
information.  The thing you're discussing is type; "duck" is
superfluous, and actually somewhat misleading.  See my "class C"
example above: it's a perfect setup for duck typing, but there's no
associated "information".

>>> 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
>
> Hmm. I see the warning of class-based type info, but nothing against
> respond_to?-style type info. Did I miss something?

It's not that it's for or against; it's just not based on "focusing on
respond_to?".  Again, see my "class C" example; respond_to? is
completely irrelevant.

>> See my #can? method in the last post.
>>
>>    module Kernel
>>      def can?(*methods)
>>        methods.all? {|m| respond_to?(m) }
>>      end
>>    end
>>
>>    class C
>>      def blah(x)
>>        raise ArgumentError unless x.can?(:a,:b,:c)
>>      end
>>    end
>
> Sure, but:
> - What tells any runtime reflective access, or a compiler, to treat this as
> part of the signature of #blah?
> - I'd like to name and compose can?-based types in a way that is, again,
> available to runtime reflective access or a compiler.

#can? *is* runtime reflection.  As for compilers, I don't see a way to
express type that's both Ruby-friendly (i.e., applicable to more than
a subset of perfectly plausible Ruby scenarios) and compiler-friendly.
But I'm not a compiler expert :-)


David

-- 
David A. Black
dblack@wobblini.net