RE: Allow ambiguous types (with warning) by default

2015-12-08 Thread David Feuer
Sure, I'll open the ticket. It may well turn out that there's a less invasive way to accomplish my ultimate goal (more useful error messages for ambiguous types) without allowing the cascade you're worried about. In foo :: Num a => F a -> G a Something more like the following would be much

RE: Allow ambiguous types (with warning) by default

2015-12-07 Thread Simon Peyton Jones
| OK, fine. Is there a way to make it an error, but keep checking the | rest of the module? My goal is *get both messages if possible*, within | a module. I'm not tied to any particular mechanism of doing so. Yes it'd be possible. A bit fiddly, but certainly possible. Of course, doing so can

Re: Allow ambiguous types (with warning) by default

2015-12-06 Thread Carter Schonwald
That gets into making the whole parser / renamer / type checker a bit more incremental, and while that would be awesome, and an excellent example of that user experience can be seen in the lean theorem prover, its certainly trickier to see how to realize it in Haskell because the order in the

Re: Allow ambiguous types (with warning) by default

2015-12-05 Thread Edward Kmett
So you are saying you want users to write a ton of code that happens to have signatures that can never be called and only catch it when they go to try to actually use it in a concrete situation much later? I don't really show how this would be a better default. When and if users see the problem

Re: Allow ambiguous types (with warning) by default

2015-12-05 Thread David Feuer
No, I want it to *warn* by default. If I write foo :: something that will fail the ambiguity check bar = something that uses foo in a (necessarily) ambiguous way the current default leads me to do this: 1. Attempt to compile. Get an ambiguity error on foo whose exact cause is hard for me to

Re: Allow ambiguous types (with warning) by default

2015-12-05 Thread Edward Kmett
If you aren't the one writing the code that can't be called you may never see the warning. It'll be tucked away in a cabal or stack build log somewhere. -Edward On Sun, Dec 6, 2015 at 12:06 AM, David Feuer wrote: > No, I want it to *warn* by default. If I write > > foo

Re: Allow ambiguous types (with warning) by default

2015-12-05 Thread David Feuer
OK, fine. Is there a way to make it an error, but keep checking the rest of the module? My goal is *get both messages if possible*, within a module. I'm not tied to any particular mechanism of doing so. On Sun, Dec 6, 2015 at 12:13 AM, Edward Kmett wrote: > If you aren't the

Re: Allow ambiguous types (with warning) by default

2015-12-05 Thread David Kraeutmann
I'm strongly against this, for a multitude of reasons. There's already a mechanism for doing what you want -- type defaulting. See also https://ghc.haskell.org/trac/ghc/ticket/8171 . On 12/5/2015 11:38 PM, David Feuer wrote: > The ambiguity check produces errors that are quite surprising to the >

Re: Allow ambiguous types (with warning) by default

2015-12-05 Thread Sumit Sahrawat, Maths & Computing, IIT (BHU)
We could have a LANGUAGE pragma that makes the language easier for beginners. Provided it would not change anything major, otherwise it will be hard to decide how much to simplify the language. We can restrict it to only enabling some other extensions, one of which could be AllowAmbiguousTypes.

Re: Allow ambiguous types (with warning) by default

2015-12-05 Thread David Kraeutmann
I don't think it'll make the language easier for beginners. It'd just be hidden type defaulting with much more severe consequences (since it's uncontrolled). Never mind that this will cause instance selection to be nondeterministic and very weird in general (the type of an expression will