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

Thomas Conway conway at cs.mu.OZ.AU
Thu Oct 26 14:31:07 AEDT 2000

On Thu, Oct 26, 2000 at 02:19:41PM EST, david wallin wrote:
> My suggestion was something like:
> Make all information used for optimization purposes optional by 
> passing a flag to the compiler.

The only information that the programmer can supply that is only
for optimization purposes, most programmers will never consider in
any case - inlining pragmas and suchlike - the compiler happily
does the right thing most of the time without any such help.

The type, mode and determinism declarations are not optimization
information. It is true the compiler can in some cases infer them,
but they are there because they enable the compiler to check the
program for correctness. That the compiler can use them to help
it generate efficient code is independent. The alternative is to
have the compiler not prove type/mode correctness on the program.
If you want Prolog, you know where to get it.

> 7 lines of declarations can save 100 lines of code, is that on the 
> average ? Care to give an example :-) ?

I think I would be right in saying that Richard's point is that
the code that you write in Mercury may be more high level than the
code you would have written in some other language, so the tradeoff
is not between Mercury code and Mercury declarations, but between
Mercury code + Mercury declarations vs say, some [X] X code + X declarations.

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

The declarations are there to help the programmer! This works in 2 ways.

First, as you write the declarations, you have to figure out what the
types/modes of the arguments should be. This forces you to do some design
work. If you've already done the design, then writing the declarations is
trivial. If you haven't done the design yet, then figuring out what the
declarations should look like helps you formulate your design. Whether you
make it explicit (the extreme being formal/algebraic design methods), or
you just have a vague idea in your head, you have a design, so making you
write some aspects of it down helps crystalize it - often revealing flaws
in the process. I've written a lot of Mercury code now, and I couldn't
begin to count the number of times I've revised my designs as I write the
declarations for the types and predicates.

Second, now that you've written some design information down, the compiler
can tell you where your code is not consistent with the design information.
Apart from trivial errors, the most common thing you find when the compiler
does this kind of checking is that you've forgotten to handle a certain
confluence of circumstances (eg the application is in THIS state and the
user clicks THAT button). This then feeds back into the design process.

Of course, there are lots of ways that the declarations are a big help
with software maintanence, but that's not the topic under discussion here.

 Thomas Conway              Mercurian )O+  
 <conway at cs.mu.oz.au>       Every sword has two edges.
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