A point about user-defined coercion mechanisms

[Damian Conway]

Regarding the issue of whether to allow "to" coercions or "from" coercions, or
both, and the issue of whether the "to" or the "from" coercion should take
precedence if they're both defined...the answer seems simple to me.

We should allow neither "to" nor "from" coercions.

Coercions are not behaviours of a given class. They are interactions *between*
two classes. As such, they are properly implemented as multimethods. So
instead of:

class Foo {
from Bar {...}
}
class Bar {
to Foo {...}
}

my Foo $x = Bar.new; # Bar to Foo or Foo from Bar?

we have:

class Foo {...}
class Bar {...}

multi COERCE (Bar $from) returns Foo {...}

my Foo $x = Bar.new; # means: my Foo $x = COERCE(Bar.new);

or, if Larry doesn't allow return types as part of the multiple dispatch
resolution mechanism, we'd need:

multi COERCE (Bar $from, Foo $to) returns Foo {...}

my Foo $x = Bar.new; # means: my Foo $x = COERCE(Bar.new, Foo);

(which is a good reason for Larry to allow return types as part of the
multiple dispatch resolution mechanism, IMHO ;-).

Damian

[Stéphane Payrard]

On Mon, Apr 21, 2003 at 11:52:57AM +1000, Damian Conway wrote:
> Regarding the issue of whether to allow "to" coercions or "from" coercions,
> or both, and the issue of whether the "to" or the "from" coercion should
> take precedence if they're both defined...the answer seems simple to me.
>
> We should allow neither "to" nor "from" coercions.
>
> Coercions are not behaviours of a given class. They are interactions
> *between* two classes.

Keep in mind that Perl6 have a three layered type system if I
understand things correctly.

Types are not necessarily classes.

I think all this thead does not take in account that perl6 has a
three layered types system; layers that I respectively call raw, boxed
and warped (roughly defined below). Is there an official nomenclature for
them? It would help.

Raw types are C<int>, C<num> ... boxed typed are provided by PMC. In
fact, even if they usually are jitted, raw types are implemented in
term of boxed types so they should behave the same way as far as
conversion/coercicion is involved. Keep in mind that we may want to
directly access PMC implemented for other languages from Perl6. What
will be the Perl6 syntax BTW? C<PMC is pmcname $varname> for a scalar
PMC? Warped types are whatever languages specific types build on top
of PMC; probably to implement whatever OO semantic.

The current thread talks about raw types, boxed types and perl6 warped
types as if they were the same thing. I undersdand we may want
consistency but I am not sure it is always possible/desirable if we
take in account PMC for foreign languages and performance
consideration.

I know that p6l and p6i are not the same list but Perl6 language will
have some underlying implementation that we should take in account.

Damian and Dan, can you shade light on that? What is the correct
nomenclature for what I call raw, boxed and warped?

I like these words because they not yet have OO meaning (except for
boxed in .Net) so people are non confused by implicit expectations.
But warped does not mean warp speed. Warped types have to cost more
than raw types.

--
stef

[Michael Lazzaro]

On Sunday, April 20, 2003, at 06:52 PM, Damian Conway wrote:
> Coercions are not behaviours of a given class. They are interactions
> *between* two classes. As such, they are properly implemented as
> multimethods. So instead of:
>
> class Foo {
> from Bar {...}
> }
> class Bar {
> to Foo {...}
> }
>
>
> my Foo $x = Bar.new; # Bar to Foo or Foo from Bar?
>
> we have:
>
> class Foo {...}
> class Bar {...}
>
> multi COERCE (Bar $from) returns Foo {...}
>
> my Foo $x = Bar.new; # means: my Foo $x = COERCE(Bar.new);

Agreed, that would be fine. My preference for "from" and "to" are
merely syntactic sugar, but the effects would be identical.

> (which is a good reason for Larry to allow return types as part of the
> multiple dispatch resolution mechanism, IMHO ;-).

Yes, amen, please.

MikeL

[Paul]

--- Michael Lazzaro <mlaz...@cognitivity.com> wrote:
> > (which is a good reason for Larry to allow return types as part of
> > the multiple dispatch resolution mechanism, IMHO ;-).
>
> Yes, amen, please.
> MikeL

Sic quoque dico.

Or, in case my Latin sux today: "Ditto!"

__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com