Re: [Haskell-cafe] Re: Error message reform (was: Strange type error with associated type synonyms)
On Thu, 28 May 2009, Claus Reinke wrote: Just, please, keep in mind that there is no one-size-fits-all: improving a message for one group of users might well make it less useful for another group. I once thought, that error messages must be configurable by libraries, too. This would be perfect for EDSLs that shall be used by non-Haskellers. But I have no idea how to design that. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Error message reform (was: Strange type error with associated type synonyms)
On Fri, May 29, 2009 at 2:17 AM, Simon Michael si...@joyful.com wrote: Achim Schneider wrote: expected/encountered Expected/actual ? Familiar to users of test frameworks. That does sound better than expected/inferred to me. -- Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Error message reform (was: Strange type error with associated type synonyms)
One user's view of error message history, perhaps helpful to reformers:-) Once upon a time, Hugs tended to have better error messages than GHC. They still weren't perfect, mostly when begginners where confronted with messages referring to advanced concepts - eg, Simon Thompson had a list of translations of the kind if Hugs reports this, it most likely means that, especially targetted to beginners in his courses, ie users who where unlikely to want things like 'Num (a-b)' instances, or find non-existing semicolons. (the advice to focus on the error location usually means that either the error message is misleading or too difficult for the user to interpret - it is a standard fallback in all programming language implementations, but no more than that; if we rely on it too often, the messages aren't doing their job) Even for more advanced users, it was helpful to get messages from several implementations (at least Hugs and GHC) for tricky cases, just to get different views from which to piece together a picture. This, sadly, is not as well supported these days as it used to be, but getting multiple opinions on type errors is still useful advice (if your code can be handled by multiple implementations, or if a single implementation can offer multiple views, eg, beginner/advanced or top-down/bottom-up or ..). Then Simon PJ invested a lot of energy into improving GHC's error messages, so the balance changed. Error message complaints didn't stop, though, and the error messages were improved further, with more text, and suggestions for possible fixes, etc. The suggestions are sometimes misleading, and I've felt there has been too much weight on narrative text, to the exclusion of actual type information (it is a programming language, after all, so why don't the error messages give type signatures for context instead of trying to talk me through it in natural language, without further references to types!-), but discussions like the present show that Simon has been on the right track with that, for many users. Still, I would really like a just the facts, please mode for GHC, with less text and more type signatures (especially for the contexts of type mismatches). Error messages simply not including the information I need has become my main issue with GHC messages, and seems to be a common thread over many tickets and threads apparently discussing phrasing (eg, expected/inferred: who expects and why, and what is the inference based on?). Somewhere in between, much research has focussed on type errors, and how to report them in general, and implementations like Helium have set out to target beginners with simpler error messages. (*) As for fixes, concrete suggestions are most likely to be adopted, but sometimes it just isn't clear how to improve the situation, and sometimes, there is no single best solution (which has spawned countless interesting papers on type-error reporting;-). It you want to help, file tickets for messages you find unhelpful, and make suggestions for possible improvements. Unfortunately, there doesn't seem to be an error message component in GHC's trac, so querying for relevant tickets is not straightforward. Simon keeps a partial list of error message related tickets here (keeping track of trac tickets - meta-trac?-): http://hackage.haskell.org/trac/ghc/wiki/Status/SLPJ-Tickets Just, please, keep in mind that there is no one-size-fits-all: improving a message for one group of users might well make it less useful for another group. Claus (*) A beginner mode for Haskell systems has often been suggested, even before Helium. Instead, error messages, and even language design decisions have been constrained by trying to serve everyone with a single mode. I'd have thought that Helium, and Dr Scheme, have sufficiently demonstrated the value of having separate levels of a language and the corresponding error messages. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Error message reform (was: Strange type error with associated type synonyms)
John Dorsey hask...@colquitt.org wrote: As another native English speaker, I found expected/inferred very intuitive when I was new to GHC, and to Haskell. I even think that expected/inferred helped me form my intuition about Haskell's type inference. First off, me too, and I'm not a native speaker. OTOH, while expected is not ambiguous, inferred is: After all, both types are inferred. I opt for expected/encountered -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Error message reform (was: Strange type error with associated type synonyms)
Achim Schneider wrote: expected/encountered Expected/actual ? Familiar to users of test frameworks. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Error message reform (was: Strange type error with associated type synonyms)
Hello Max, Thursday, May 28, 2009, 1:30:28 AM, you wrote: I prefer this wording: The inferred type of `True' is `Bool', while the type of the first argument of `f' should be `Int'. In the expression: f True yes, it's also self-explanatory I prefer all three to Hugs's ERROR - Type error in application *** Expression : f True *** Term : True *** Type : Bool *** Does not match : Int for me, it was better than ghc errmsg. main thing is that i don't feel automatically what is expected and what is inferred. here Hugs says that True is Bool and the remaining is Int, so i feel the situation overall, this expected/inferred words are probably go directly from compiler algorithms. it looks natural for compiler developer - saying that some term has different types evaluated by two different compiler parts. but for me as a user it's natural to think in terms of function having parameter of some type and term having another type, so i need to fix the call giving it the right parameter: The type of the first argument of `f' should be `Int', while the inferred type of `True' is `Bool'. In the expression: f True -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Error message reform (was: Strange type error with associated type synonyms)
On Thu, 2009-05-28 at 01:45 +0400, Bulat Ziganshin wrote: for me, it was better than ghc errmsg. main thing is that i don't feel automatically what is expected and what is inferred. here Hugs says that True is Bool and the remaining is Int, so i feel the situation I absolutely agree about expected/inferred. I always forget which is which, because I can figure both could apply to each. Say, in this simple example: Prelude let f = (+5) Prelude f abc interactive:1:2: Couldn't match expected type `Integer' against inferred type `[Char]' In the first argument of `f', namely `abc' In the expression: f abc In the definition of `it': it = f abc Does expected mean that, based on the type signature, it should be an Integer, or based on the argument that I provided, it should be a String? The same goes for the inferred type: it knows what the type of the literal argument (String), so I would assume the inferred type was the type in the function's signature. Unfortunately, my reasoning in both cases can go the wrong way . . . Better language may be much more helpful, although I'm not sure what may be easier to interpret. Jeff Wheeler ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Error message reform (was: Strange type error with associated type synonyms)
On Thu, May 28, 2009 at 12:03 AM, Jeff Wheeler j...@nokrev.com wrote: I absolutely agree about expected/inferred. I always forget which is which, because I can figure both could apply to each. That's actually true for me too. When you say it like that, I remember times when I've had the same confusion. Better language may be much more helpful, although I'm not sure what may be easier to interpret. I think one big improvement (demonstrated in Bulat's proposal) is to put the two types near where those types come from. GHC gives you the two types, and then the context in which they arose. Hugs gives the context and then two types, but doesn't say which type is which. So we say: you have here `True', it is a `Bool'. But the first argument of `f' should be an `Int'. Thus it's clearly indicated where the two types came from. My preference is still to include the words expected and inferred which indicate (to me) that *either* could be wrong. And they don't seem to me to be compiler writers' jargon. They're both ordinary (if not everyday) English words. But definitely we should use language which more clearly indicates which is which. I'll pay more attention to error messages in the future. GHC devs: would patches for error message language be considered? --Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Re: Error message reform (was: Strange type error with associated type synonyms)
Hello Jeff, Thursday, May 28, 2009, 2:03:30 AM, you wrote: I absolutely agree about expected/inferred. I always forget which is which, because I can figure both could apply to each. thank you, it's what i meant! compiler infers types of both caller and its argument and then expect to see types inferred. these two words are actually describe two stages of process, not two opposite processes! -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Re: Error message reform (was: Strange type error with associated type synonyms)
Hello Max, Thursday, May 28, 2009, 2:14:19 AM, you wrote: I absolutely agree about expected/inferred. I always forget which is which, because I can figure both could apply to each. That's actually true for me too. When you say it like that, I remember times when I've had the same confusion. it's why i asked beginners. it seems that we all go through times when ghc errmsgs looks cryptic but then we start to live with it and forget the first period actually, i don't have much problems with errrmsgs now, but trying to grok how i interpret them i've found that i mainly use *position* part of message, it's enough for me most times :) -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] Re: Error message reform (was: Strange type error with associated type synonyms)
On Wed, May 27, 2009 at 3:24 PM, Bulat Ziganshin bulat.zigans...@gmail.com wrote: Hello Max, Thursday, May 28, 2009, 2:14:19 AM, you wrote: I absolutely agree about expected/inferred. I always forget which is which, because I can figure both could apply to each. That's actually true for me too. When you say it like that, I remember times when I've had the same confusion. it's why i asked beginners. it seems that we all go through times when ghc errmsgs looks cryptic but then we start to live with it and forget the first period actually, i don't have much problems with errrmsgs now, but trying to grok how i interpret them i've found that i mainly use *position* part of message, it's enough for me most times :) -- Best regards, Bulat mailto:bulat.zigans...@gmail.com Hi, I like the expected/inferred vocabulary. Maybe it comes from being a native English speaker, but to me, it says this is what we expected to get, but instead (through type inference), we got this type for this term. Of course, I've also been reading GHC error messages for a while, so I've gotten used to understanding what they mean. When I was new, I had more of a problem...but I'm not sure you can really eliminate that. Everything takes practice. :) Alex ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] Re: Error message reform (was: Strange type error with associated type synonyms)
I like the expected/inferred vocabulary. Maybe it comes from being a native English speaker, but to me, it says this is what we expected to get, but instead (through type inference), we got this type for this term. As another native English speaker, I found expected/inferred very intuitive when I was new to GHC, and to Haskell. I even think that expected/inferred helped me form my intuition about Haskell's type inference. There was one hang-up; it wasn't at all clear which referred to the term, and which referred to the context. (Really both types are inferred.) This stopped bothering me when I decided it didn't matter which was which, and I could generally find the problem pretty quickly just knowing the location and the types involved. Of course, I can see how the messages are probably much less useful to non-native speakers, and that's quite important. Something along the lines of inferred type droozle for term, but expected type snidgit in context. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] Re: Error message reform (was: Strange type error with associated type synonyms)
On Wed, 2009-05-27 at 23:59 -0400, John Dorsey wrote: There was one hang-up; it wasn't at all clear which referred to the term, and which referred to the context. (Really both types are inferred.) This stopped bothering me when I decided it didn't matter which was which, and I could generally find the problem pretty quickly just knowing the location and the types involved. Of course, I can see how the messages are probably much less useful to non-native speakers, and that's quite important. Something along the lines of inferred type droozle for term, but expected type snidgit in context. As a native English speaker myself, I've also found it awkward because both types are inferred, I suppose. The alternate format you've suggested would make it much more clear, in my opinion, and I strongly feel that the current version should be replaced with yours. Jeff Wheeler ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
