[mercury-users] Why is --infer-all not the deafult?

[Ralph Becket]

Peter Schachte, Thursday, 15 July 2004:
> On Tue, Jul 13, 2004 at 12:01:00PM +0100, David Overton wrote:
> > On Tue, Jul 13, 2004 at 11:51:51AM -0700, Maurizio Colucci wrote:
> > > IMHO type declarations make the code heavier to read, while giving
> > > little (or no) insight regarding the meaning of the code ---
> > > because the meaning of a variable is the way it is used, not its
> > > type.
> > 
> > I disagree strongly.  I find that type declarations often provide a very
> > valuable insight into the meaning of the code.

I agree with David.  One of the main reasons I moved to Mercury was the
combination of a strong, expressive type system along with a compiler
that encouraged the use of declarations.  The minor extra typing
involved is more than paid for in the quality and precision of compiler
error messages and the greater ease with which you can understand other
people's code.

> Unfortunately,
> the cost of using higher level abstractions like this is a lot of
> casting throughout your code between set as sorted list and list, and
> between timestamp and int (using no-tag constructors).

Not necessarily true: I often use equivalence types for these purposes,
for example:

:- type filename == string.
:- type timestamp == int.
:- type point == pair(coordinate).
:- type coordinate == float.

There's no need for wrapping/unwrapping of these values.  The new type
names give the reader more information about what a particular argument
is supposed to represent (although you don't get the same level of type
safety as you would using a wrapper type.)

> All that said, you don't lose much of the benefit of type checking by
> omitting declarations and using --infer-all.  It's unfortunate that we
> assume that all you get to see when you read a program is the
> characters written by the original author.  Assembly language
> programmers don't assume that:  assemblers produce listings with lots
> of extra information.  The Mercury compiler could similarly produce a
> listing containing all the inferred types, modes, and determinisms of
> their code.  The problem is really our tool set, not using
> --infer-all.

Using --infer-all on 

:- import_module list.

r([]      ) = [].
r([X | Xs]) = r(Xs) ++ [X].

m(_, []      ) = [].
m(F, [X | Xs]) = [F(X) | m(F, Xs)].

the compiler reports

foo.m:006: Inferred :- func r((list.list(T))) = (list.list(T)).
foo.m:009: Inferred :- func m(((func V_2) = T), (list.list(V_2))) = (list.list(T)).

I'm sure you could write a tool that took these inferred declarations
and inserted them into your code in the appropriate places.  But for
reasons I gave in my opening paragraph, I'm personally far happier
giving explicit declarations using meaningful names (and reading code
by other people with the same sentiments.)

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