[mercury-users] boolean expressions from semidet predicates

[Richard A. O'Keefe]

I wrote that C++ seems to do what
"Jonathan Morgan" <jonmmorgan at gmail.com>
wants.
	>     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?
	
There are four times that things could be checked:

    - template DEFINITION time
    - template INSTANTIATION time
    - template USE time (compile time)
    - RUN time

The Ada equivalent is checked at DEFINITION time.

The C++ version is checked at explicit INSTANTIATION or USE time.

This actually has a down-side.  If you have a generic package or subprogram
in Ada, and the compiler likes it, you know that EVERY instantiation will
either be legal or will fail because of a discrepancy between the use of
the generic and its *interface*.  But in C++, if you have a template, it
doesn't matter how happy the compiler was with it, or how many different
types you have already used it with, the *next* instantation may fail to
compile because of something going on deep in the guts of the function.

I must say that C++ templates are one of the more complex parts of the
language.  I really don't think it would be a good idea to copy them.

	> The Clean functional programming language comes pretty close.
	> It makes each individual arithmetic operation into a typeclass,

	I agree that Haskell's types provide a lower flexibility than these.

If you ignore strictness and uniqueness, the Clean type system *IS*
the Haskell type system.  It's not the system that's different, just
the basis.  (OK, the actual numeric classes are different in detail,
but they WORK the same way.)

	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.
	
The presence of defaults has very little to do with the issues of what
types are or how they are checked or inferred.  Clean 1.x didn't allow
defaults either.  Clean 2.x apparently does, at least StdClass.icl has
some defaults in it.  The Mercury type+mode system is very close to the
Clean type+strictness+uniqueness system.

	>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.

But Haskell's typeclass approach DOES have multiple inheritance.
Always has.  For example,
   (standard Prelude)
	class (Eq a, Show a) => Num a where ...
	class (Num a, Ord a) => Real a where ...
	class (Real a, Enum a) => Integral a where ...
   (hugs Sequence)
	class (Functor m, MonadPlus m) => Sequence m where

The point I was making is that the Clean approach, where things like
+ already have their own typeclasses, occurs in a language with basically
the *SAME* type system (except for which actual types and which actual
classes happen to be defined) as Mercury, so that *no* fundamental change
to type checking or type inference is needed.

--------------------------------------------------------------------------
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
--------------------------------------------------------------------------