develooper Front page | perl.perl6.language | Postings from July 2005

Re: Messing with the type heirarchy

Thread Previous | Thread Next
July 27, 2005 07:32
Re: Messing with the type heirarchy
Message ID:

Ingo Blechschmidt wrote:
> I've probably misunderstood you, but...:
>     role Complex does Object {...}
>     Num does Complex;
>     # That should work and DWYM, right?

My 0.02: Complex should provide e.g. a + that, when
called with two Nums, doesn't bother the return
value to carry on a useless imaginary part. And
Complex should consistently return undef when compared
to other Nums or Complexes. And the Compare role
shouldn't treat undef == false but as any(true|false).
Otherwise funny things can happen  (as was observered
correctly in another thread about != applied to any
Juntions). In code:

    if $c < 3 { die if $c.does(Complex) }

This is the Perl6 representation of the following
sentence: "If Any::$c is less then Int::3 then
die if this $c does behave like a Complex." I hope
$Larry likes it. BTW, is their a plain english output
module planned, that would produce the above automatically?

Don't question (Light ::= Particle|Wave) with a double
slit! At least not if you want a deterministic answer
where it actually passed.

<tie rant>
Imagine a Casino that hands out ties to players
who don't have one even though the Casino is
a tied area. If a Num playing in the Casino likes
the imaginary standard tie it can keep it. But
among Nums this imaginary tie is no differentiator.
Actually other Num methods will say: "A tie? I see
no tie. Must be an imaginary one." In simple
environments the tie might not even be applicable
imaginarily. Thus it's stripped off or entrance is
denied. Under all cicumstances the Num may decide
how to deal with this tieing.

fun: d(en)ie(d) == die in the end :)
</tie rant>

The only question is how much effort all this is for
(1) the implementor of Complex
(2) the implementor of Num
(3) the user of either one in isolation
(4) when they come together

In particular the user in (4) should be able to
state his expectations in a form that is checkable
by the VM. Which basically means that (1) and (2)
have to state their assumptions to the VM in the
same form/syntax.
$TSa.greeting := "HaloO"; # mind the echo!

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About