From: itsme213 <itsme213@...>
Date: 2005-01-13T02:31:16+09:00
Subject: Re: Duck Typing as Pattern Matching

"David A. Black" <dblack@wobblini.net> wrote

> > 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.

Curiously, that is my point too. If you can some of the things that "you'd
have to do anyway" in a way that makes more transparent a signature (without
having to repeat it outside that signature), then that's A Good Thing.
Patterns like [x,y] are an example of this.

Some other type declarations may not be, unless they do "things you'd have
to do anyway". Hence my attempts to include variable bindings (which you'd
have to do anyway) into the type declarations.

> 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.

I don't understand your point. I assume that (basic) duck-typing is about
"does x respond to y", and does not include any further semantics of the
behavior of "y".

> Maybe, though I don't think it's self-evident that all
> variables-getting-bound semantics have to be the same as each other.

Now that you have stated it, it is. The binding is done by Ruby, not by
user-methods. e.g. just as it is illegal today to have two arguments with
the same name in a method def, it could be illegal to have the same variable
appear twice within a pattern on the "lhs" of a binding.

> There might be other things to factor in; for example, in method
> signatures there the special case of &block.

Which I believe is a special case of pattern-based binding. As is *splat,
and **keywords.

> Again, I would describe this as type information, not duck-type
> information.

Unless the "type information" does the things that you'd "have to do
anyway", correct?

> 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.

I think we are talking past each other on something here. Your class C seems
to check respond_to? via the can? wrapper.

I'm happy with something like your 'can?' if:
- it becomes the standard Ruby to do it
- it provides a basic set of compositions e.g. t1 && t2 || t3
- it allows for things to be named (constants would probably suffice)

I'd like it to include variable bindings as well, if possible.

> #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 :-)

Nor am I. Further, I'm not a Ruby expert either :-)
(But I am an active Ruby programmer and do know a bit about objects).