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

[Fergus Henderson]

On 16-Jul-2004, Peter Schachte <schachte at cs.mu.OZ.AU> wrote:
> On Thu, Jul 15, 2004 at 12:00:45PM +1000, Ralph Becket wrote:
> 
> > :- type filename == string.
> > :- type timestamp == int.
> > 
> > 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.)
> 
> The loss of type safety here is troubling.  Eg, given a predicate
> 
> 	:- pred write_string_to_file(string, filename, io, io).
> 
> a call
> 
> 	write_string_to_file(Filename, Text, !IO)
> 
> would be accepted.
> 
> But worse still is that equivalence types don't actually provide the
> abstraction they would seem to.  For example, the function call
> 
> 	concat(Filename, ".m")
> 
> would also be allowed.  This means you can't later redefine the
> filename type to be, for example,
> 
> 	:- type filename ---> filename(directory, basename, extension).

You _can_ redefine the "filename" type afterwards.
If you do so, you might need to change other parts of our code.
But the type checker will helpfully point out those parts.

> This makes equivalence types much less attractive from a software
> engineering point of view.

You're right that ADTs are in many ways preferable to equivalence types.
However, you don't always realize the right abstractions when writing the
code the first time.  Equivalence types are a nice half-way house between
just using an existing type and defining a new ADT.

Also, it _is_ possible to over-engineer things.  Sometimes the right answer
is to "ship it already!", not to spend another hour or two refactoring or
adding a new ADT.

-- 
Fergus Henderson                    |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------