The dreaded M-R

Benjamin Franksen benjamin.franksen at
Fri Jan 27 13:04:43 EST 2006

On Friday 27 January 2006 10:51, Simon Marlow wrote:
> How about an even simpler solution:
>   *All* pattern and variable bindings are monomorphic unless a type
>   signature is given.

My personal opinion is that it should be exactly the other way around:

All normal bindings (i.e. using '=') should be as polymorphic and 
general as possible. An alternative symbol (':=') should be available, 
but strictly as a means to optimize binding of monomorphic ground 
values (that are then /guaranteed/ to be computed only once). I think 
that the language should /never/ force the programmer to consider 
performance issues from the outset. I see ':=' as something similar to 
SPECIALIZE or INLINE pragmas -- such things should never be mandatory 
to get a program to work. Thus, I think, for all programs that are 
accepted by the compiler, replacing all ':=' by '=' should result in a 
program that gets accepted as well, it should be semantically 
equivalent (apart from possibly being slower or consuming more memory).

Furthermore, in Haskell there are /thousands/ of other possibilities to 
ruin the efficiency of your program, most of them a lot less obvious 
and in fact very hard to optimize away. For instance, compared to all 
those subtle too-much-laziness performance problems, this one could be 
easily diagnosed by profiling and also easily fixed by introducing the 
occasional ':='. Also, the compiler could help by issuing warnings (but 
only if prompted to do so by some compiler flag).

On the other hand, forcing the programmer to write signatures in order 
to get the most general type of a bound variable -- when this would be 
avoidable in principle -- is a very bad idea, IMO. Type inference is an 
extremely valuable feature when prototyping and experimenting. It is 
also of great help for people who want to explore some of more advanced 
aspects of Haskell's type system. Asking ghci or hugs to give me the 
inferred type of a complicated function definition has often given me 
the decisive insight about how to write a correct version.

Just my (hopefully not too uninformed) 2 cents.


More information about the Haskell-prime mailing list