On Tue, Jun 14, 2005 at 04:25:17PM +0200, Chip Salzenberg wrote:
: On Tue, Jun 14, 2005 at 03:43:42PM +0200, "TSa (Thomas SandlaÃ?)" wrote:
: >  The syntax might just be:
: >  
: >     &is_equal:(Integer $a, Integer where { $_ == $a } :)
: >  
: 
: It's a new type object every time, so every time you run that code you
: get a new type object to describe $b, and therefore the type object of
: the expression will never match up with the one used in the function
: definition.

Constrained subtypes are not types.  The actual type is

    &is_equal:(Integer, Integer)

: Are you suggesting that type equivalence tests include introspection
: into the semantics of the closure?  If so, what is "close enough"?  If
: not, how can Parrot ever know that
: 
:     Integer where { $_ == $a }
: 
: is the same as
: 
:     Integer where { $^foo == $a }
: 
: but different from
: 
:     Integer where { $_ != $a }
: 
: ?  Down that path lay madness.[*]

Agreed, which is why constrained subtypes may only be used where they
make sense operationally.  Unfortunately, MMD dispatch is one of those
places where we'd like to use constrained subtypes as a tie-breaker
for multies that would otherwise be considered ambiguous.  As far as the
actual MMD engine is concerned, it could just arrange such methods
in any order, and call the first one, on the assumption that there is
some implicit code at the beginning of each that throws your magical
"not me" exception, which is really just "next METHOD" in disguise,
I suspect.  If you write your constraints ambiguously, then you get
ambiguous dispatch order within the cohort.  The engine should be under
no obligation to order the entries in most specific to most general,
except insofar as a signature without a constraint is considered more
general than one with a constraint, and sorts to the end of the cohort.

: [*] There is another theory which states this has already occurred.

There's more than one method to our madness.

Larry