-- Original message --
From: "Jonathan Lang" <[EMAIL PROTECTED]>
> Mark Biggar wrote:
> > Jonathan Lang wrote:
> > > They can be:
> > >
> > > $A > $B if $A.x > $B.x | $A.y > $B.y;
> > > $A < $B if $A.x < $B.x | $A.y < $B.y;
> >
> > That dosn't work.
>
> Agreed
Mark Biggar wrote:
Jonathan Lang wrote:
> They can be:
>
> $A > $B if $A.x > $B.x | $A.y > $B.y;
> $A < $B if $A.x < $B.x | $A.y < $B.y;
That dosn't work.
Agreed. The above was written in haste, and contained a couple of
fatal syntax errors that I didn't intend. Try this:
multi infix
-- Original message --
From: "Jonathan Lang" <[EMAIL PROTECTED]>
> TSa wrote:
> > Jonathan Lang wrote:
> > > If at all possible, I would expect Complex to compose Num, thus
> > > letting a Complex be used anywhere that a Num is requested.
> >
> > This will not work.
Nicholas Clark wrote:
Jonathan Lang wrote:
> They can be:
>
> $A > $B if $A.x > $B.x | $A.y > $B.y;
> $A < $B if $A.x < $B.x | $A.y < $B.y;
>
> This also allows you to unambiguously order any arbitrary set of
> complex numbers.
If I'm reading that correctly then there are values of $A and $B f
On Wed, Oct 18, 2006 at 06:55:16AM -0700, Jonathan Lang wrote:
> TSa wrote:
> >Jonathan Lang wrote:
> >> If at all possible, I would expect Complex to compose Num, thus
> >> letting a Complex be used anywhere that a Num is requested.
> >
> >This will not work. The Num type is ordered the Complex ty
TSa wrote:
Jonathan Lang wrote:
> If at all possible, I would expect Complex to compose Num, thus
> letting a Complex be used anywhere that a Num is requested.
This will not work. The Num type is ordered the Complex type isn't.
The operators <, <=, > and >= are not available in Complex.
They c
HaloO,
Jonathan Lang wrote:
If at all possible, I would expect Complex to compose Num, thus
letting a Complex be used anywhere that a Num is requested.
This will not work. The Num type is ordered the Complex type isn't.
The operators <, <=, > and >= are not available in Complex. Though
I can i
TSa wrote:
Pinning the return type to Num is bad e.g. if you want multi targets
like :(Complex,Complex-->Complex). Should that also numerify complex
values when stored in a Num container? If yes, how?
If at all possible, I would expect Complex to compose Num, thus
letting a Complex be used anyw
HaloO,
TSa wrote:
I know that the return type of / could be Num in "reality" but that
spoils the example. Sorry if the above is a bad example.
Pinning the return type to Num is bad e.g. if you want multi targets
like :(Complex,Complex-->Complex). Should that also numerify complex
values when s
HaloO,
Larry Wall wrote:
On Fri, Oct 13, 2006 at 04:56:05PM -0700, Jonathan Lang wrote:
: Trey Harris wrote:
: >All three objects happen to be Baz's, yes. But the client code doesn't
: >see them that way; the first snippet wants a Foo, the second wants a Bar.
: >They should get what they expect
On Sat, Oct 14, 2006 at 07:56:24AM -0700, Jonathan Lang wrote:
: Right. That _almost_ takes care of the issue; the only part left
: untouched is what happens if you have two methods that can only be
: disambiguated by the invocant's role, and you aren't told what the
: role is. For instance:
:
:
Larry Wall wrote:
Jonathan Lang wrote:
: Trey Harris wrote:
: >All three objects happen to be Baz's, yes. But the client code doesn't
: >see them that way; the first snippet wants a Foo, the second wants a Bar.
: >They should get what they expect, or Baz can't be said to "do" either.
:
: In prin
On Fri, Oct 13, 2006 at 04:56:05PM -0700, Jonathan Lang wrote:
: Trey Harris wrote:
: >All three objects happen to be Baz's, yes. But the client code doesn't
: >see them that way; the first snippet wants a Foo, the second wants a Bar.
: >They should get what they expect, or Baz can't be said to "d
Trey Harris wrote:
In a message dated Fri, 13 Oct 2006, Jonathan Lang writes:
> Since Baz does both Foo and Bar, you cannot use type-checking to
> resolve this dilemma.
Why not? Why shouldn't this work:
my Foo $obj1 = getBaz(); # object is a Baz
$obj1.baz(); # Foo::baz is c
In a message dated Fri, 13 Oct 2006, Jonathan Lang writes:
Since Baz does both Foo and Bar, you cannot use type-checking to
resolve this dilemma.
Why not? Why shouldn't this work:
my Foo $obj1 = getBaz(); # object is a Baz
$obj1.baz(); # Foo::baz is called
my Bar $obj2 =
Jack is tasked to write a role "Foo". He does his job right, and
produces a role that perfectly produces the set of behaviours that
it's supposed to. Among other things, he defines a method
"&Foo::baz:()". He also writes a routine, "&foo:( Foo )", which calls
&Foo::baz.
Jill is tasked to write
16 matches
Mail list logo
