[mercury-users] boolean expressions from semidet predicates

[Jonathan Morgan]

On 5/16/06, Peter Schachte <schachte at csse.unimelb.edu.au> wrote:
> I've always thought C was kind of weird in using % for modulo and ^
> for xor.  The latter symbol would be much more natural for
> exponentiation, but that's not a built-in operation, so it can't be an
> operator.  And using 'mod' for the former operation is ruled out
> because it's alphabetic, and alphabetic functions can't be built-ins,
> and can't be operators.  Of course, they *could*, but C had decided
> that all operators should be non-alphabetic and should not be
> user-definable, and no alphabetic symbols should be operators or
> builtins (well, except for sizeof).  Persisting with this unnatural
> dichotomy in a language designed for abstract datatypes, as Java does,
> makes some programs pretty ugly.  Allowing overloading, as C++ and
> Mercury do, makes for more natural looking programs.  But deciding
> that certain types are build-in and have access to operator syntax,
> and no other types do, seems pretty ugly to me.  The nicest approach,
> which Mercury moves a long way toward, is to have no builtin types,
> and all operations implemented as libraries that any user could have
> written.  So if I want to support fixed point numbers, or rational
> numbers, or strings with constant-time concatenation, I can do so
> without having to use a syntax incompatible with the standard types.
> The main difficulty in fully providing this flexibility is handling
> manifest constants.

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.

Mercury version:
:- module operator_test.
:- interface.
:- implementation.

:- import_module float.
:- import_module int.

f(A,B) = A+B.

Haskell version:
f b c = b+c

> Where Mercury is less pleasant is that it decides once and for all (or
> until the next Mercury release) which symbols can be used as
> operators, with what fixity, associativity, and precedence, and no
> others can.  I'd really like to be able to write programs the way I
> write papers with latex:  choose the nicest looking symbols and nicest
> syntax to express my ideas.

This looks like going back to the op/3 wars - but I'm inclined to agree.

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