From: itsme213 <itsme213@...>
Date: 2005-01-11T13:46:20+09:00
Subject: Re: Duck Typing as Pattern Matching


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

> Also I think you're playing on the
> similarity of the literal array constructor [] and the method #[],
> which I think has to be discounted as something of a coincidence :-)

Actually that is exactly what pattern matching does in functional languages.
It uses term constructors (such as []) on the left hand of an assignment,
effectively 'deconstructing' the rhs (i.e. using accessors to get into). And
it is what regex's do, in a round-about way.

> You can devise some very obscure notation in which things happen and
> the results are saved in variables :-)

I'm not happy with the notation for method matching, but correspondence with
pattern matching is sound.

> It could be an interesting experiment (and it's been attempted), but I
> don't know that such a thick description of an object at a given
> moment in its life-cycle would have much practical value.

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

Modulo the usual duck-arguments of the hazards of slipping into class-based
checking, signature-based type information is useful both for programmers
and for reflective applications (which typically do not want to examine
method-bodies).

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

> If you call this an object's
> "duck type", it suggests that there's some other "type" that an object
> can have -- which, frequently if not inexorably, leads back to
> the type == class thing.

I would not suggest requiring any tie in to class-based checks.

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

Cheers.