From: itsme213 <itsme213@...>
Date: 2005-01-14T07:21:25+09:00
Subject: Re: Duck Typing as Pattern Matching

"trans. (T. Onoma)" <transami@runbox.com> wrote

> Yes. A bit different on two accounts. 1) The "upon" clause is just a
regular
> boolean returning block, like #if, not divided and limited to matching
like
> #case is. And 2) it would be instrumental to how #method_missing works,
thus
> in some manner queryable, so that #respond_to? and potentially other
methods
> could make use of it. That's the idea any way. There may very well be a
> better way to achieve the same goal.

Ah, so your 2 blocks were:
    - matcher: does handler match method_missing symbol?
    - handler: handle the missing method

Nice. Yes, matcher blocks would be very general, and were to be part of my
(not fully posted) duck-typing as pattern-matching proposal. The general
block case would correspond to predicate types. And the types would be used
like:

def route (x /*type_pattern*/ )

/*...*/ (earlier in the thread I used "::") would be a literal constructor,
like [] or {}, constructing a TypeExpression object. The primary operation
of a TypeExpression would be a boolean match operation. Perhaps #=== could
be used for this. Type Expressions can also be named and composed e.g. with
&&, ||.

Looking back over the thread, I don't know if the variable-binding part of
the idea should be totally separated out. I think there is real value in
making signatures revealing about not just what methods will be called on
the args, but also *why* or *when* they will be called, simply by revealing
further variable names. After all, a caller of method M(x) really might want
to know what methods x must support, and even how those methods are used
within M(). This is different from most common approaches to typing.

Suppose /*type_pattern_with_vars*/ is some syntax that defines what methods
are expected from an object of this type, but also includes some variable
names that reveal information about how those methods are going to be used
used:

Then, in:
def heat (x /*type_pattern_with_vars*/ )
.... type_pattern_with_vars could convey, via not-yet-determined syntax, the
following information:
- arg x must support #min, #max
- x.min() is used as the *lo* var in #heat
- x.max() is used as the *hi* var in #heat
- x.cool() is used as the *onHot* var in #heat
- x.explode() is used as the *tooHot* var in #heat

That would make the signature very informative. And it is all still based on
duck-ish respond_to? semantics rather than on classes. It would *not*
duplicate any work since the implementer of route() would *not* have to do
any the following:
    lo = x.min()
    hi = x.max()
    onHot = x.method(:cool)
    tooHot = x.method(:explode)
in route()'s body, as these variable bindings would be done by Ruby itself
just before the body of #heat. In fact, if the variable 'x' was ommitted,
then these other variables would be the *only* handles on the argument
available within #heat() i.e. a caller would know for sure that x.cool()
could *only* be called via *onHot*. All I could do within the body of heat()
would be things like:
def heat
    temp = ... some stuff
    if (temp > lo && temp < hi) onHot.call()
    if (temp > hi) tooHot.call()

The var names themselves need not be part of any type check that may (or may
not) be done, but they would be a big part of the signature that method
clients should know about. And that is available to run-time reflective
access.

Like any typing information, it would be entirely optional. If this could be
done without dulplicate typing (i.e. the compiler does variable bindings as
above so the programmer does not have to re-do them), and if it's syntax
could be kept clean, what do you'll think of it?