> 3. NonStrictPoSet, which is the class of all partially ordered
> set-like things, but without the requirement that a <= b and b <= a
> implies a Equal b.

Those are preorders.  An antisymmetric preorder is a non-strict poset.

Also it's difficult to capture all of those various order types in
Haskell's class system.  A type can have many orders and many underlying
equivalence relations in the case of partial and total orders, and there
are different ways to combine them.  For example equality is a partial
order, modular equivalence is a preorder, etc.  Those denote bags and
groups more than sequences or trees.

Perhaps it's time to add a type class-like system to Haskell, but for
explicitly passed arguments:

    record Relation a where
        related :: a -> a -> Bool

        unrelated :: a -> a -> Bool
        unrelated x y = not (related x y)

    func1 :: Relation A -> A -> A -> A
    func1 _ x y = ... related x y ...

    func2 :: Relation A -> Relation A -> A -> A -> A
    func2 r1 r2 x y = ... r1.related x y ... r2.unrelated x y ...

In a lot of cases this is much more appropriate than a type class, and
it would turn many things that are currently types into regular
functions, thus making them a lot more composable:

    down :: Ord a -> Ord a
    down o =
        Ord { compare x y = o.compare y x }
        -- The remaining Ord functions are defaulted.

Perhaps all we need is to generalise default definitions to data types
and add module-like dot syntax for records (mainly to preserve infix
operators).  Formally speaking there is also little that prevents us
>From having associated types in those records that can be used on the
type level.

For actual record types (i.e. single-constructor types) we could even
have specialisation and get a nice performance boost that way, if we ask
for it:

    {-# SPECIALISE down someOrder :: Ord SomeType #-}

This would be extremely useful.


> 4. Things like above, but with the requirement of a Zero, with the
> requirement of a One, and the requirement fo both a Zero and a One.

Zero and one as in minBound and maxBound or rather as in Monoid and a
hypothetical Semiring?  In the latter case I believe they don't really
belong into an additional class, unless you have some ordering-related
laws for the zeroes and ones.  If not, you can always simply use an
Ord+Semiring constraint.

There may be some motivation to make Bounded a subclass of Ord though.


Greets,
Ertugrul

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe