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
| 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
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
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
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
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
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
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
>
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.
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
10 matches
Mail list logo