[mercury-users] Mercury as a 1st class prototyping language ?

Richard A. O'Keefe ok at atlas.otago.ac.nz
Mon Oct 30 12:33:26 AEDT 2000


	Great, so would I, but I would like to be able to do it when I 
	actually see that it's necessary and not (necessarily) before.
	
The optimist says "I almost always get things right, so I don't need tools
to avoid debugging until I notice the egg dripping off my face."
The realist says "A good rule of thumb for good quality but unchecked
typing is 1 mistake every 25 lines [this is really true] so I need all the
help I can get almost all the time."
	
	>Oh, I've loved Prolog syntax for years.  That doesn't prevent me acknowleding
	>the truth:  it's quite a bit bulkier than Haskell-like syntax.
	
	Would you say that Haskell syntax has the same/better/worse 
	readability (to a human eye) compared to Prolog syntax ?
	
Ah, you don't catch me that way!  Syntax doesn't have readability, source
code does.  Even with that qualification, one has to assume that the reader
has equal proficiency or experience with both before one can start to make
such comparisons.  And even _then_ adequate commenting may well be more
important.  Let's take just one tiny example to prove my point.  This is
real code I wrote about 2 weeks ago.

up_down(P, ptr(C,L,R,A)) :-
    (   var(P) ->
        A = ptr(_,_,_,_),
        P = A
    ;   A = P,
        P = ptr(Tree,_,_,_),
        tree_children(Tree, Children),
        revapp_(Children, [], L, C, R)
    ).

It's short (9 lines, 71 tokens, counting "f(" as one token, which Prolog
parsers should), but when you really think about it, it is so strange
that it needs a couple of paragraphs of explanation.  The corresponding
Haskell code is

up (Ptr _ _ _ (Just a)) = a

down_sibstar p@(Ptr n _ _ _) =
  back_to_back_map (\f l r -> Ptr f l r (Just a)) (tree_children n)

Shorter (3 lines, 44 tokens) and not in the least strange to a Haskell
programmer.  The data structure description and the comments for
back_to_back_map (elsewhere in the same file) are really all the explanation
needed.

This doesn't really show off the convenience of Haskell.
(When you listen to a highly skilled Haskell programmer, they are all the
time talking about "creating a combinator to do this" or "defining a monad
to express that" which packages up a fair bit of complexity and then
completely hides it.

Mercury has most of the *semantic* resources to be as expressive for
logic programming as Haskell is for functional, and I haven't the faintest
idea how to do it, though I'd like to see it done.
	
	>That is, if by writing a few declarations you are
	>enabled to use a language whose implementation already contains most of the
	>stuff you need, then it's rational to write those declarations.
	
	This, I'm afraid, is the best reason there is to stick with Java, a 
	language I really would like to get away from.

Indeed, it is an excellent reason to stick with Java.
Except that there is a 20-year-old language which already offered practically
everything Java did (multiplatform system with oodles of goodies already there,
portable byte code, with Just In Time compiler, OOP, GUI, networks, data base
connectivity) by 10 years ago.  In my experience, that 20-year-old language
is considerably more concise than Java (without sacrificing readability).
It has the merit of being consistently OOP throughout.  There is a
completely free and vigorously maintained version now, and has been for
several years.  I refer, of course, to Smalltalk.

	What attracted me to Mercury was mainly two things:
	
	i) Typeclasses seems to keep the best features of OOP: Polymorphism 
	and Interfaces/Protocols.
	
Agreed.

	ii) The Erlang like syntax. As you so eloquently put it : Java is a 
	syntactic weirdo.

Perhaps we can agree that Prolog/Erlang/Mercury, Smalltalk, and Haskell/Clean
all have their simplicities.

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



More information about the users mailing list