[mercury-users] Pred defns

[Fergus Henderson]

On 02-Apr-1998, Ralph Becket <rwab1 at cam.sri.com> wrote:
> I'm getting more and more uncomfortable about all this.  It seems to
> me our goals are not happy in bed together:

This is almost always the case in programming language design!
Programming language design always involves balancing many
different and often conflicting aims.

> .. our goals are not happy in bed together:
>
> 	Improve Code Clarity
> 	- make use of multiple accumultators easier by making the
> 	  threading implicit in the source code;
> 	- make code easier to read by making input/output accumulator
> 	  arguments implicit in some way.
> 
> 	Retain Clear Denotational Semantics of Source Code
> 	- err, add more syntax in the form of various quantifiers
> 
> and that last point, it seems to me, is replacing one grind (too many
> explicit arguments) with another.

On that point, I agree that adding quantifiers would not be a good solution.
I was not proposing that, I was just using them to explain why upper
case accumulator names don't work.  My preference would be to use
lower case accumulator names.

> I'm going to go out on a limb here and may get (justifiably) shot down
> in flames, but... why don't we bite the bullet and accept that bits of
> source code written in this style will not be syntactically identical
> with its FOL denotation?

This is a good question.

My answer is to say that ensuring "Clean Denotational Semantics of Source Code"
is one of the foremost goals of Mercury.  This is one of the few things
that really distinguishes Mercury from hundreds of other languages out there.
One of the key features of Mercury is that it takes the ideal of PROgramming in
LOGic and makes it a reality -- your program is indeed a set of statements in
logic, and the implementation is guaranteed to be sound with respect to that logic.

As soon as you depart from this direct programming-in-logic and instead use
programming-in-something-that-can-be-translated-into-logic you have stepped
off the One True Path onto a slippery slope.  Just a little way down the slope,
guided by Paul Voda's paper "a logical reconstruction of a one-solution operator",
you will find Trilogy's `once' operator; Prolog's cut is not far below.
Somewhere down at the bottom of the gully lies C++ ;-)

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.