The dreaded M-R
Benjamin Franksen
benjamin.franksen at bessy.de
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.
Ben
More information about the Haskell-prime
mailing list