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

[Richard A. O'Keefe]

I wrote that C++/STL efficiency is a myth, and that I have been
getting better ratios for Haskell/C than for C++/C.

david wallin <david at wallin.cx> asked:

	What compiler did you use ? I'm not really into the C++ thing and 
	have no plans to either, but I heard somewhere that C++ in general 
	and STL in particular is receiving alot of attention in the 
	forthcoming GCC v3.0. (But its a bit beside the point.)
	
It'd *need* to.  g++ 2.95.2 on an Alpha and
Compaq C++ V6.2-024 for Digital UNIX V4.0F  (Rev. 1229)
The handling of the 'string' type is quite stunningly bad;
on one benchmark (from the Kernighan and Pike book, which claimed that
C++ did well on it) the Compaq-compiled code was 100 times slower than
the C code, while the G++-compiled code was only 50 times slower.
That kind of performance makes C++ look like the prototyping language
and Java the language you rewrite into for efficiency.  It certainly
makes crunching lists the Prolog/Mercury way look the epitome of efficiency.
	
	My suggestion was something like:
	
	Make all information used for optimization purposes optional by 
	passing a flag to the compiler.
	
There is very little information in a Mercury file that is *only* used
for optimisation purposes.  Not being familiar with the compiler, I can't
off-hand think of any.

	You reject this idea

No I don't.  I completely and totally accept the idea of not adding
optimisation hints until it is time to optimise.

	and tells me that you happily write declarations 
	to avoid spending time in the debugger (further down the page).

No, what I wrote was to the effect that I am happy to spend time writing
declarations if/when it saves debugging time.

	At the same time you mention this neat hack where you copy and
	paste information from the compiler back into the source as a
	way to _avoid_ exactly this ?
	
You didn't really read what I wrote carefully enough.
Haskell compilers will let you write an entire program with never a
function type declaration in sight, whether a function is exported or not.
My mention of pasting was very specifically in the context of Clean, and I
gave the reason:  Clean *forces* you to write a function's type explicitly,
and in two places, if you want to export it, even though it can perfectly
well infer the type.  In that case, it makes perfect sense to get the
compiler to write the code instead.

Naturally, one *reads* the types when one does this.  I thought that was
so obvious I didn't need to state it.  Quite often, one does need to add
some strictness and some uniqueness information to those inferred types,
and sometimes one makes them a bit more specific.  Using the compiler to
do the grunt work of writing the declarations is only a way of saving
labour, not a way of avoiding thought.
	
	>There are two problems in Mercury.  One is modes.  Given the distinction
	>betweeen "in" and "di", which is important for *design*, no compiler is
	>ever going to infer everything you might want.  The other is the syntax.
	
	I tend to like the syntax that languages like Mercury, Prolog
	and Erlang have.
	
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.
	
	>Haskellish syntax really gets more done with less typing than anything
	>I've used except APL.  Adroit use of operators helps.
	
	What's APL ?

Iverson's "A Programming Language".  It uses its own character set, with
dozens of operators.  Data values are arrays, whose elements may be characters,
numbers, or mixed, including references to other arrays.  Operators mostly
work on entire arrays.  There are higher order operators, e.g. matrix
multiplication is A +.x B, where (sum).(product) composes a multiplication
operator (to combine matching elements pairwise) and an addition operator
(to total the combined pairs); any compatible pair of infix operators may be
combined that way.  It can be extremely terse.

	>But the real strength of a prototyping language is not what the code
	>you do write looks like, but how much code you don't have to write at all.
	>An *intelligent* lazy programmer doesn't mind writing 200 lines of type
	>and 500 lines of mode declarations if it will enable her to avoid writing
	>10 000 lines of code.  (A really clever programmer, like me, will happily
	
	7 lines of declarations can save 100 lines of code, is that on the 
	average ? Care to give an example :-) ?
	
Where did you get those numbers from?  I never said anything about
declarations saving lines of code.  What I talked about was **libraries**
saving lines of code.  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.

	Most of the declarations are there to help the compiler.

Well, no.  Without the declarations, Mercury wouldn't be slower, it
just wouldn't get off the ground *at all*.

	The compiler should still be able to do it's [sic] job, not as
	efficient probably but when you just want to test your idea,
	maybe speed isn't that important?
	
The Mercury compiler's job is to compile Mercury.  The Mercury language
was designed from the very beginning to have the declarations you don't
care for as an integral part of the language.  If you want a language
that is rather like Mercury, but _doesn't_ go in for lots of declarations,
use NU Prolog (if anyone is still maintaining it), or get a personal copy
of SICStus Prolog (USD 120, if I'm reading the web page correctly), or use
GNU Prolog (was Calypso), or CIAO, or some other modern Prolog-like system.
	
	>spend an hour writing declarations if that will save two hours of debugging.)
	>Any effort spent improving Mercury's suitability as a prototyping language
	>should go on extending the coverage of the library, not tinkering with
	>syntax.
	
	Maybe, but I still believe it would be easier to attract more 
	programmers if the learning curve gets flattened out.

The bulk of Mercury code is clauses, predicate type declarations, and
mode declarations.  Mode declarations have been around for a long time
in Prolog-like languages.  They are even present in Fortran.  (The INTENT
declaration.)  Basic :- mode p(in,in,out,out) declarations are not all that
hard to master.  Predicate type declarations are harder, but until you
can at least *read* them you cannot use Mercury at all, just as you cannot
use ML or OCaml or Haskell or Clean without understanding the type system.

Of currently used programming languages, I'd say Smalltalk has the easiest
syntax to learn.  (Scheme is simple too, but Common Lisp has far too many
special forms to be called simple.)  I don't see Smalltalk attracting as
many programmers as it deserves.  And of course, once you get through the
language learning phase in Smalltalk, you enter on a couple of years of
library learning time...

Frankly, I think all the people who say "Language X would attract so many
more programmers if you'd just make the changes I want" are wrong.  Look
at Perl and Java.  Syntactic weirdos both.  The things that seem to make
for programming language success these days include
 - availability on popular platforms (read "Windows", alas)
 - extensive libraries (CPAN, tons of stuff for Java e.g. www.alphaworks.ibm.com)
 - books
 - perceived utility to adopters
It doesn't matter how much you simplify Mercury, if people don't think that
it will buy them anything they want, they won't come.  If they *do* think it
will do something good for them, they'll pick it up faster than you can say
"if the Euro has lost 20% of its value against the US dollar, what makes
anyone think the similar fall in the NZ dollar says something unique about
NZ?"
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------