[mercury-users] boolean expressions from semidet predicates

[Jonathan Morgan]

On 5/19/06, Richard A. O'Keefe <ok at cs.otago.ac.nz> wrote:
> "Jonathan Morgan" <jonmmorgan at gmail.com> wrote:
>         (however,
>         no language that I know of provides the ability to make a function
>         available for all types over which a particular operator is defined,
>         without first requiring them to make that type an instance of some
>         typeclass or interface).

It would seem that I didn't look in the right places.  But it still
doesn't change the fact that Mercury hasn't got these things by
default.

> C++.
>
>     template <typename T>
>     T f(T x, T y) {
>         return (x - y) * (x + y);
>     }
>
> This function is usable for any type T that provides +, -, and * .

I've never used C++ with templates.  Would the compiler check whether
the type provided these operations at compile-time, or at run-time?

I would like Mercury to have something like this, where only types
that supported the operators used could be used to call the function,
and I would also like to have it type-checked and specialised at
compile-time, so that there is no loss of performance caused by the
flexibility.  However, I don't think that it is either very possible
or likely to happen.  In most cases I don't think that it causes that
much of a problem.  Where it causes more of a problem is using
comparison and equality to provide generic structures over generic
types, and Mercury seems to have both of these built into the
language, unlike comparable functional languages, that require
type-classes like Eq and Ord.

> The Clean functional programming language comes pretty close.
> It makes each individual arithmetic operation into a typeclass,
> named after the operation, so you can write
>
>     f :: t -> t -> t     | + , - , * t
>     f x y = (x - y) * (x + y)
>
> In StdClass.dcl we find
>
>     class PlusMin a  | + , - , zero a
>     class MultDiv a  | * , / , one  a
>     class Arith   a  | PlusMin , MultDiv , abs , sign , - a
>
> showing that more Haskell-like typeclasses can be built up by inheritance
> from single-operation typeclasses.
>
> This is actually a DARNED good idea, because in Haskell you are stuck
> with the operation bundles they already decided on, and if you have something
> that doesn't quite fit (a situation I've been in) there is nothing you can do.
> In Clean you can put together the bundle you need.

I agree that Haskell's types provide a lower flexibility than these.
However, suspect that a Mercury type-class system along the lines of
Haskell would have even less flexibility, as Mercury doesn't have the
ability to have default implementations of methods, which allows
Haskell users more choice over the methods that they define.

>From the efficiency point of view, I imagine that multiple inheritance
of operator classes, as in Clean, would cost even more than Haskell's
typeclass approach, though it is conceptually nicer.  I haven't looked
at Clean at all, though I have meant to for a long time.  In practise,
typeclasses beyond the basic operations should be provided by the
developer rather than the standard library anyway, so the typeclasses
are merely a standard library issue.  However, I think the use of
constrained polymorphism over operators could well go beyond the
standard library and into the language itself as a compile-time,
type-safe and type-specialised feature, which it doesn't in most or
all languages.

Jon

--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------