On Fri, Aug 7, 2009 at 1:04 PM, Simon Peyton-Jones
| . Understanding how to respond to type inference and error messages is | hard enough without having additional differences in innocent-looking | code. Do you think my hope is reasonable that not-generalizing could | lead to better error messages?
I don't think it's obvious one way or the other. We'll have to see.
The Bluespec experience with local bindings (complicated by our "imperative desugaring", but my opinion is that's mostly an irrelevant complication) is that automatically generalized local bindings create all sorts of user-level havoc: poor error messages for one, programs that surprisingly typecheck or have other surprising behaviors and so on. And I wouldn't blame these issues on Bluespec's desire to hide the type system details from our users - when some sort of polymorphism-related problem is discovered it is common for people at Bluespec itself to be confused and have trouble isolating the underlying issue. Based on that experience, I'd expect that removing the automatic generalization of local bindings would lead to many positive user-level side-effects that are independent of any implementation simplifications that result. In fact, when I first heard the suggestion (via Joe Stoy) I started looking for an excuse to end (or at least limit) Bluespec's generalization of local bindings, since I think the backwards compatibility issues that result will be more than worth it in the long run. - Ravi