[mercury-users] boolean expressions from semidet predicates

[Jonathan Morgan]

On 5/17/06, Peter Hawkins <hawkinsp at cs.stanford.edu> wrote:
> Jonathan Morgan wrote:
>
> > On 5/16/06, Peter Schachte <schachte at csse.unimelb.edu.au> wrote:
> > What I don't like about languages like C++ and Mercury, when compared
> > to a language like Haskell, is that there is no good way (that I know
> > of) to define a function to work with all types that define a given
> > operator (or set of operators, like those defining equality, ordering
> > and numberic operations, etc.).  C++ is worse, because it uses a
> > single operator (+) to mean at least two different things (addition
> > and string concatenation).
> >
> > If in Mercury I write the following and use type-inference I get
> > complaints about type ambiguity between int and float, but if I remove
> > either of them then it will specialise the definition to act either
> > over ints, or over floats.  However, if I define the equivalent
> > Haskell version (with implicit importing of the Prelude), type
> > inference gives me f :: Num a => a -> a -> a.  While such a system
> > requires the programmer to always use the same basic operators to mean
> > the same thing (unlike the practise in C++) it does give constrained
> > genericity for my function.
>
> You _can_ do the same thing in Mercury using the typeclass system
> (modulo the "deriving" automatic thing haskell does for you). Nothing
> prevents the creation of a Num typeclass which has the appropriate
> operations and with int and float as members --- it's just not the way
> things are done at the moment. I assume we don't do this because
> typeclasses aren't optimized very well at the moment and this would
> require lots of type class dictionaries to be passed around.

I know that it is technically possible to do this, but this still
leaves two problems.  One is that it still doesn't work with
type-inference (this may not be such a bad thing).  The other, more
serious, one is that it is non-standard, so you are requiring all
users of this "generic" number class to make the necessary
declarations so that their number type, which already provides all the
necessary operators, satisfies your definition of a number (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).

I would have thought that type-specialisation could get rid of much or
all of the type-class overhead, but I recognise that there has to be a
tradeoff between efficiency and the niceness of a language.

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