RE: NoMonomorphismRestriction
| . 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. | typechecker behaviors to think about. I guess it's still possible to | use explicit type-signatures to make let-bindings polymorphic, Yes, just so | in a way | that is difficult or impossible for lambda or case? (I guess for lambda, | it would require making the lambda into a rank-2 function, though I'm | not sure how to do that syntactically.) Easy: \(x :: forall a. a-a) - blah Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: NoMonomorphismRestriction
On Fri, Aug 7, 2009 at 1:04 PM, Simon Peyton-Jonessimo...@microsoft.com wrote: | . 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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: NoMonomorphismRestriction
On 6 Aug 2009, at 12:18, Simon Peyton-Jones wrote: The paper makes the (somewhat radical) case for not generalising local bindings at all; which would at a stroke remove most of the issues of the MR. (We'd still need to think about the top level.) Only the other day I was writing some code that used a case analysis to build a value I hoped would be polymorphic, and it kept refusing to type-check. Doing the case analysis on a different part of the value, then cutting and pasting the branch code multiple times did however seem to work. Suddenly I remembered about the difference in generalisation between let- and lambda- bindings, and could solve the problem by changing the case to a let! Instantly I could delete the error-prone cut-n-paste copies, and be more assured of the consistency of my code. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: NoMonomorphismRestriction
The paper makes the (somewhat radical) case for not generalising local bindings at all; which would at a stroke remove most of the issues of the MR. (We'd still need to think about the top level.) We'd love to know what any of you think of the idea. I read the paper (except section 5 which is very technical). I like that it makes (let x = ... in ...) behave the same as (\x - ...) (...) . 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 quite understand the issues[*], but I suspect that not-generalizing would at least make *me* less confused when fixing error messages because there are fewer different typechecker behaviors to think about. I guess it's still possible to use explicit type-signatures to make let-bindings polymorphic, in a way that is difficult or impossible for lambda or case? (I guess for lambda, it would require making the lambda into a rank-2 function, though I'm not sure how to do that syntactically.) [*] e.g., the gmapT / rank-2 example confuses me; would it work if (...blah...) were passed directly to gmapT without the let? Also, does it happen to solve the 2^n worst-case typechecking? -Isaac ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
