[mercury-users] boolean expressions from semidet predicates

[Jonathan Morgan]

On 5/19/06, Richard A. O'Keefe <ok at cs.otago.ac.nz> wrote:
> 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.

And C++ is one of the more complex languages around to start with.

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

I can see that I've expressed myself badly.  Read "the Haskell
type-class system", which does provide a lower flexibility than the
Clean type-class system in the standard library.

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

Yes, it's a standard library issue.

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

The point I am making is that a typeclass system with defaults allows
implementors to define two methods in terms of each other, leaving the
user to choose which of the two operations they define.  Sometimes
they will want to define both, if they can implement them more
efficiently.  This cannot be done with Mercury's typeclass-system, and
I don't see that it would hurt the type-system to include them.

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

Again, badly expressed.  Read "multiple levels of inheritance" - Clean
seems to first have typeclasses for operators, and then inherit from
these typeclasses to provide a Num class.  I don't know whether that
would lower performance, but my guess is that it would.

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

Which I agreed with: that it could be implemented as a standard
library feature.  Currently, Mercury doesn't, probably for efficiency.
 However, I think that a much nicer (if impractical) system would be
to have such typing as a compiler level feature with
type-specialisation (maybe not by default as that could hurt code size
too much).  I don't think that this could reasonably be done while
keeping all the advantages of separate compilation, and I don't think
that it's worth it in most cases, as users can define typeclasses if
they want to.

However, I still want to know if type-specialisation would be able to
remove much of the overhead of type-classes, or whether they will
still be expensive to implement.

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