John Launchbury:
> I agree that the MR is a pain. [...]
> Now we find that some type declarations
> contain more class info than type!!
And some type(+class) declarations are longer than the definition!
This sounds a trite point, but it gets very annoying when one is
"rapid-prototyping" (aka hacking, aka not wanting to think too
hard about what type is really is), and one finds a correct function
definition won't compile without a type sig, which itself then becomes
wrong later, when one "prototypes" elsewhere -- even if the defintion
was till completely correct.
> I think the MR and the default mechanism are both hacks that were
> introduced to serve a purpose. Few people love them, but I also
> suspect that few people think they serve no useful purpose at
> all.
As far as I can see, it's alleged to serve a number of purposes...
o Avoiding "call by name" like behaviour on unwittingly
overloaded CAFs;
o Avoiding some cases where (some extra) ambiguity may arise
without the MR;
o Getting the best possible types in instances where
there's an MR 'monomorphisation', followed by a top-level
generalisation step.
Sorry if I'm a bit vague on the latter two; it's been a while since
I've seen a thoroughgoing Apologia for the MR.
At any rate, the first is surely best taken care of as a matter of
compiler pragmatics. A compiler can clearly do at least as well by
treating it as a 'stiff warning message' type offence, but more
importantly, this would allow a compiler to do _better_, where it
can detect that there's not really such a problem, or that it can
be finessed by multiple specialised instances, or whatever.
The second I don't feel too concerned about: adding ambiguity to a
language that doesn't suffer from it would make me worry, but this
is far from the case, here...
The last is the one I'm the least clear on. Is this at least helped
by adding scoped type sigs, or something of that sort? Can someone
racapitulate on this point, or ideally even give the low-down on
the 'state of the art' for alternative solutions to this one?
> What we need is a general solution to managing classes and
> ambiguity, and then hopefully we can dispense with the hacks.
That would indeed be nice.
Slan libh,
Alex.
