Re: Type checker's expected and inferred types (reformatted)

2009-10-24 Thread Daniel Fischer
Am Samstag 24 Oktober 2009 21:21:51 schrieb Albert Y. C. Lai:
> For the record, and to speak up as part of a possible silent majority,
>
> I completely understand the type error messages.

Mostly, I do, too. But I can't get why IO () is *expected* and Maybe () is 
*inferred* for 
bar in fun2.
Can you explain?

> I find enough information in them. I like them.

Generally, it's the same for me, though some are better than others.
Even if one doesn't completely understand them, it's rare that one can't get 
enough out of 
them to start fixing the code.

>
> I find it unnecessary to "decrypt" the two words "expected" and
> "inferred". They have their own definitions and they stand for
> themselves; "external" and "internal" are helpful mnemonics, useful
> approximation, but not decryption.
>
> I support work on ghc to prioritize professional use over pedagogical
> use, that is, if a proposed pedagogical improvement conflicts with
> professional use concerns, or even if simply no one has time to
> implement, I support sacrificing the pedagogical improvement.

Seconded.

> To mitigate the sacrifice, we users write tutorials for each other.


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: Type checker's expected and inferred types (reformatted)

2009-10-24 Thread Albert Y. C. Lai

For the record, and to speak up as part of a possible silent majority,

I completely understand the type error messages. I find enough 
information in them. I like them.


I find it unnecessary to "decrypt" the two words "expected" and 
"inferred". They have their own definitions and they stand for 
themselves; "external" and "internal" are helpful mnemonics, useful 
approximation, but not decryption.


I support work on ghc to prioritize professional use over pedagogical 
use, that is, if a proposed pedagogical improvement conflicts with 
professional use concerns, or even if simply no one has time to 
implement, I support sacrificing the pedagogical improvement. To 
mitigate the sacrifice, we users write tutorials for each other.

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users