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

[david wallin]

>It is quite possible to have brevity, safety, and efficiency.
>
>I've been looking at the STL in C++ lately; several books (including
>one by Kernighan and Pike) praised it, so I decided to try their
>examples, thinking that C++ compilers might have improved their
>STL handling dramatically since my (1996? 1997?) benchmarks where
>Scheme was outperforming C++.  Well, they haven't.  I'm getting
>a factor of 5 or worse for C++/STL raced against simple clean C.
>The efficiency of the STL is largely a myth.
>
>I'm getting *better* ratios for Haskell vs C (using recent versions
>of ghc and hbc), and of course extremely good ratios for Clean vs C.

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


>What has that to do with Mercury?
>Mercury and Clean have very similar type systems, and Haskell's is not
>so very different.  Clean and Haskell code can be very concise, and of
>course you don't have to write down any types even though they are
>strictly typed.
>
>Actually, you do have to write down the types of exported functions in
>Clean, twice (once in the interface and again in the implementation).
>But there's a neat hack:  write the code without exporting any functions,
>run it through the compiler with the "-lat" (List All Types) option, and
>paste the output back in.

My suggestion was something like:

Make all information used for optimization purposes optional by 
passing a flag to the compiler.

You reject this idea and tells me that you happily write declarations 
to avoid spending time in the debugger (further down the page). 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 ?


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


>Haskellish syntax really gets more done with less typing than anything
>I've used except APL.  Adroit use of operators helps.

What's APL ?


>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 :-) ?

Most of the declarations are there to help the compiler. The compiler 
should still be able to do it's job, not as efficient probably but 
when you just want to test your idea, maybe speed isn't that 
important ?


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


--david.



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