On Wed, May 27, 2009 at 11:05 PM, Bulat Ziganshin
i mean just changing the words to make obvious what type was got in what way. and check it on beginners who don't yet read your explanations, for example teachers may test it on their students
my English is limited... for example, it may be like this:
read x
Error: type of x is Integer while type of read argument should be String
For me, this word order is an improvement, but it doesn't help to leave out the words "expected" and "inferred". To me, those words add explanation. Of course they don't help if you don't know what they mean. I think they add something because they explains where the types "came from". When I get type errors, I often think "why do you say True has type Bool" (of course in most cases it is not so transparent). Although the compiler doesn't say *why* it inferred that type, at least it says it did infer it. 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 I prefer all three to Hugs's ERROR - Type error in application *** Expression : f True *** Term : True *** Type : Bool *** Does not match : Int --Max