On 19/04/2008, Henning Hasemann <hhasemann@web.de> wrote:
> > Yes, that's true. But remember, partially ordered types cannot be used
>  > as AA keys (at least, not if the AA is implemented as a binary tree
>  > with total ordering), so we've got a problem right there. How do we
>  > tell AAs "Yes, we've implemented opCmp(), but you're not allowed to
>  > use it because it's partial"?
>
> By using a syntax different to opCmp ;)

You mean, like I suggested earlier in this thread? ;)

   class P
   {
       bool partialLess(P p) {...}
       bool partialGreater(P p) {...}
   }

Janice Caron wrote:
> On 19/04/2008, Henning Hasemann <hhasemann@web.de> wrote:
>>> Yes, that's true. But remember, partially ordered types cannot be used
>>  > as AA keys (at least, not if the AA is implemented as a binary tree
>>  > with total ordering), so we've got a problem right there. How do we
>>  > tell AAs "Yes, we've implemented opCmp(), but you're not allowed to
>>  > use it because it's partial"?
>>
>> By using a syntax different to opCmp ;)
> 
> You mean, like I suggested earlier in this thread? ;)
> 
>    class P
>    {
>        bool partialLess(P p) {...}
>        bool partialGreater(P p) {...}
>    }


prepend those methods with "op" and the compiler would only generate the
 operators you specified under your partially ordered class. if you only
define opPartialLess than you can do (a < b) and (a > b) would be an error.
I'm not sure if that makes sense or not, but for partially ordered sets,
is it possible (mathematically speaking) to have only one of the
operators defined?

--Yigal

>  is it possible (mathematically speaking) to have only one of the
>  operators defined?

Only if you allowed opPartialLess to return three values (true, false,
and can't compare).

For a /fully/ ordered set, you only need boolean <, because you can derive everything else. i.e.

    (a > b) == (b < a)
    (a == b) == (!(a < b || b < a))
    etc.

but what makes an ordering partial is that there may exist some
elements, x and y say, for which x and y cannot be ordered. For such
elements, neither (x < y) nor (x > y) have meaning, and both are
considered to evaluate to false (because boolean expressions must be
either true or false).

So you'd either need both opPartialLess() and opPartialGreater() being
boolean, or you'd need a single opPartialCmp() which could return an
enum { LESS, EQUAL, GREATER, UNORDERED }.

Does that make sense?

Janice Caron wrote:
>>  is it possible (mathematically speaking) to have only one of the
>>  operators defined?
> 
> Only if you allowed opPartialLess to return three values (true, false,
> and can't compare).
> 
> For a /fully/ ordered set, you only need boolean <, because you can derive everything else. i.e.
> 
>     (a > b) == (b < a)
>     (a == b) == (!(a < b || b < a))
>     etc.
> 
> but what makes an ordering partial is that there may exist some
> elements, x and y say, for which x and y cannot be ordered. For such
> elements, neither (x < y) nor (x > y) have meaning, and both are
> considered to evaluate to false (because boolean expressions must be
> either true or false).
> 
> So you'd either need both opPartialLess() and opPartialGreater() being
> boolean, or you'd need a single opPartialCmp() which could return an
> enum { LESS, EQUAL, GREATER, UNORDERED }.
> 
> Does that make sense?

Thanks for the explanation :)
I'd prefer in that case either two boolean operators (the first
suggestion) or an opCmp that would throw an exception... (I a purist and
don't like enum return types that indicate errors...)

in any case I think all those strange !<> type comparisons should be removed from D. they are not intuitive (at least for me).

--Yigal