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

[Bulat Ziganshin]

Hello David,

Saturday, October 24, 2009, 8:50:57 AM, you wrote:

> The expected type is what the context wants (it's *ex*ternal). The
> inferred type is what the expression itself has (it's *in*ternal).

heh, how long we will need to learn decryption rules for this simple
message?


-- 
Best regards,
 Bulatmailto:bulat.zigans...@gmail.com

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

Type checker's expected and inferred types (reformatted)

[C Rodrigues]

> Which message do you prefer? I couldn't tell which it was.

I prefer fun1.  In my understanding, the 'inferred' type is gleaned by looking 
at theexpression itself, while the 'expected' type is implied by the context.   
   
_
Windows 7: It works the way you want. Learn more.
http://www.microsoft.com/Windows/windows-7/default.aspx?ocid=PID24727::T:WLMTAGL:ON:WL:en-US:WWL_WIN_evergreen2:102009___
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)

[David Menendez]

On Fri, Oct 23, 2009 at 9:46 PM, Isaac Dupree
 wrote:
> C Rodrigues wrote:
>>
>> fun1 produces the error message:
>> Couldn't match expected type `Maybe a' against inferred type `IO ()'
>> In the first argument of `(>>=)', namely `bar'
>>
>>
>> fun2 produces the error message:
>> Couldn't match expected type `IO ()' against inferred type `Maybe ()'
>> In a stmt of a 'do' expression: bar
>>
>>
>> It's confusing because 'bar' is inferred to have type Maybe (), even
>> though it's explicitly declared to be an IO ().
>
> Which message do you prefer? I couldn't tell which it was.
>
> For myself, I never understood the difference between "expected" and
> "inferred": it works better for me to just think "there were at least two
> different ways that determined the 'type' of this expression, and the
> results contradicted each other, and here are two of those results.  Now,
> dear user, go and look at your code to intuit *what* those ways of
> determining the type might have been" (or sometimes it's easier just to look
> for mistakes, ignoring the particular details of the error)

The expected type is what the context wants (it's *ex*ternal). The
inferred type is what the expression itself has (it's *in*ternal).

So inferring the type Maybe () for bar seems wrong. I'm guessing it's
a bug in the way do-expressions are handled. Note that this doesn't
happen if the bar is last.

Prelude> :t let fooThen m = foo >> m in fooThen (do undefined; bar)

:1:51:
Couldn't match expected type `Maybe b'
   against inferred type `IO ()'
In the expression: bar
In the first argument of `fooThen', namely
`(do undefined
 bar)'
In the expression:
fooThen
  (do undefined
  bar)

Prelude> :t do foo; bar

:1:8:
Couldn't match expected type `Maybe b'
   against inferred type `IO ()'
In the expression: bar
In the expression:
do foo
   bar
Prelude> :t do foo; bar; foo

:1:8:
Couldn't match expected type `IO ()'
   against inferred type `Maybe ()'
In a stmt of a 'do' expression: bar
In the expression:
do foo
   bar
   foo

-- 
Dave Menendez 

___
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

[Daniel Fischer]

Am Samstag 24 Oktober 2009 03:12:14 schrieb C Rodrigues:
> I came across a type error that misled me for quite a while, because the
> expected and inferred types were backwards (from my point of view).  A
> simplified example is below.  Can someone explain how GHC's type checker
> creates the error message? In this example, fun1 and fun2 are basically the
> same.  The type error is because they try to run an IO () together with a
> Maybe ().
>
> 

import Control.Monad
foo :: Maybe ()
foo = return ()

bar :: IO ()
bar = return ()

fun1 = let fooThen m = foo >> m
 in fooThen (bar >> undefined)


fun2 = let fooThen m = foo >> m
 in fooThen (do {bar; undefined})

>
> With ghc 6.10.4, both functions attribute the error message to `bar'.
> However, the expected and inferred monads are swapped.fun1 produces the
> error message:

> Couldn't match expected type `Maybe a' against inferred type `IO ()'
> In the first argument of `(>>=)', namely `bar'

> fun2 produces the error message:

> Couldn't match expected type `IO ()' against inferred type `Maybe ()'
> In a stmt of a 'do' expression: bar 


> It's confusing because 'bar'
> is inferred to have type Maybe (), even though it's explicitly declared to
> be an IO ().

I don't know the intricate details, but the order in which type inference/type 
checking 
proceeds has something to do with it.

In fun1, apparently first the type of fooThen is inferred to be `Maybe a -> 
Maybe a'.
Then, in the body of the let-expression, fooThen *expects* a `Maybe a'.
Thus the (>>) in fooThen's argument is inferred to have the type 
`Maybe a -> Maybe b -> Maybe b'.
Hence the first argument of (>>) [or (>>=), apparently it has been expanded to 
that]
is *expected* to have type `Maybe a'.
But from bar's definition, its type is *inferred* to be `IO ()'.

Perfectly clear and transparent (not really). Had the type of fooThen's 
argument been 
inferred before fooThen's type, it would've said that it expected fooThen to 
have type `IO 
a -> b', but inferred it to have type `Maybe a -> Maybe a'.

The error for fun2 is baffling. I can't explain how ghci comes to *expect* bar 
to have 
type `IO ()'.

Also intriguing is that if you swap bar and undefined in the do-expression, you 
get the 
error message you'd expect:

Couldn't match expected type `Maybe b'
   against inferred type `IO ()'  
In the expression: bar
In the first argument of `fooThen', namely
`(do undefined
 bar)'
In the expression:
fooThen   
  (do undefined   
  bar)

But if you sandwich bar between two actions which may have type `Maybe a', it's 
back to 
expecting `IO ()':

Couldn't match expected type `IO ()'
   against inferred type `Maybe ()'
In a stmt of a 'do' expression: bar
In the first argument of `fooThen', namely
`(do Just 1
 bar
 Nothing)'
In the expression:
fooThen
  (do Just 1
  bar
  Nothing)

Seems typechecking do-expressions has some strange corners.
___
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)

[Isaac Dupree]

C Rodrigues wrote:

fun1 produces the error message:
Couldn't match expected type `Maybe a' against inferred type `IO ()'
In the first argument of `(>>=)', namely `bar'


fun2 produces the error message:
Couldn't match expected type `IO ()' against inferred type `Maybe ()'
In a stmt of a 'do' expression: bar


It's confusing because 'bar' is inferred to have type Maybe (), even though 
it's explicitly declared to be an IO ().


Which message do you prefer? I couldn't tell which it was.

For myself, I never understood the difference between "expected" and 
"inferred": it works better for me to just think "there were at least 
two different ways that determined the 'type' of this expression, and 
the results contradicted each other, and here are two of those results. 
 Now, dear user, go and look at your code to intuit *what* those ways 
of determining the type might have been" (or sometimes it's easier just 
to look for mistakes, ignoring the particular details of the error)


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

Type checker's expected and inferred types (reformatted)

[C Rodrigues]

(Some formatting was apparently lost en route.  Trying again with extra 
newlines.)
I came across a type error that misled me for quite a while, because the 
expected and inferred types were backwards (from my point of view).  A 
simplified example is below.  Can someone explain how GHC's type checker 
creates the error message?

In this example, fun1 and fun2 are basically the same.  The type error is 
because they try to run an IO () together with a Maybe ().

> import Control.Monad
>
> foo :: Maybe ()
> foo = return ()
>
> bar :: IO ()
> bar = return ()
>
> fun1 = let fooThen m = foo>> m
>        in fooThen (bar>> undefined)
>
> fun2 = let fooThen m = foo>> m
>        in fooThen (do {bar; undefined})


With ghc 6.10.4, both functions attribute the error message to `bar'. However, 
the expected and inferred monads are swapped.


fun1 produces the error message:
Couldn't match expected type `Maybe a' against inferred type `IO ()'
In the first argument of `(>>=)', namely `bar'


fun2 produces the error message:
Couldn't match expected type `IO ()' against inferred type `Maybe ()'
In a stmt of a 'do' expression: bar


It's confusing because 'bar' is inferred to have type Maybe (), even though 
it's explicitly declared to be an IO ().
  
_
Windows 7: Simplify your PC. Learn more.
http://www.microsoft.com/Windows/windows-7/default.aspx?ocid=PID24727::T:WLMTAGL:ON:WL:en-US:WWL_WIN_evergreen1:102009___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Type checker's expected and inferred types

[C Rodrigues]

I came across a type error that misled me for quite a while, because the 
expected and inferred types were backwards (from my point of view).  A 
simplified example is below.  Can someone explain how GHC's type checker 
creates the error message?
In this example, fun1 and fun2 are basically the same.  The type error is 
because they try to run an IO () together with a Maybe ().
> import Control.Monad>> foo :: Maybe ()> foo = return ()>> bar :: IO ()> bar = 
> return ()>> fun1 = let fooThen m = foo >> m>in fooThen (bar >> 
> undefined)>> fun2 = let fooThen m = foo >> m>in fooThen (do {bar; 
> undefined})
With ghc 6.10.4, both functions attribute the error message to `bar'. However, 
the expected and inferred monads are swapped.fun1 produces the error 
message:Couldn't match expected type `Maybe a' against inferred type `IO ()'In 
the first argument of `(>>=)', namely `bar'fun2 produces the error 
message:Couldn't match expected type `IO ()' against inferred type `Maybe ()'In 
a stmt of a 'do' expression: bar
It's confusing because 'bar' is inferred to have type Maybe (), even though 
it's explicitly declared to be an IO ().  
_
New Windows 7: Find the right PC for you. Learn more.
http://www.microsoft.com/windows/pc-scout/default.aspx?CBID=wl&ocid=PID24727::T:WLMTAGL:ON:WL:en-US:WWL_WIN_pcscout:102009___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: haddock problem. Was: ANNOUNCE: GHC 6.12.1 Release Candidate 1

[Andrea Vezzosi]

On Mon, Oct 12, 2009 at 6:43 PM, Christian Maeder
 wrote:
> Hi,
>
> with
> http://darcs.haskell.org/~ghc/dist/6.12.1rc1/ghc-6.12.0.20091010-i386-unknown-linux-n.tar.bz2
> installed (under /local/maeder/) I get the following "internal Haddock
> or GHC error". I have no file
>  /local/maeder/lib/ghc-6.12.0.20091010/html/haddock.css
> but a file
>  /local/maeder/share/doc/ghc/html/html/haddock.css

I've the same problem, it seems that haddock's data-files are not
installed anywhere by ghc's build system, even if they are present in
the tarball under utils/haddock.

/local/maeder/share/doc/ghc/html/html/haddock.css seems to be the .css
for the main documentation index, i don't think it makes sense for
haddock to take the default files from there.

A workaround could be a separate installation of haddock (assuming
it'll look for the files where cabal will install them), but i
couldn't find a ghc-paths updated for 6.12.

> and I run:
>  ./Setup configure -O --prefix=/local/maeder
>  ./Setup build
>  ./Setup haddock
>  ./Setup install
>
> Cheers Christian
>
> P.S. I wonder why "Registering" is done twice
>
> Configuring packedstring-0.1.0.1...
> Preprocessing library packedstring-0.1.0.1...
> Building packedstring-0.1.0.1...
> [1 of 1] Compiling Data.PackedString ( Data/PackedString.hs,
> dist/build/Data/PackedString.o )
>
> Registering packedstring-0.1.0.1...
>
> Running Haddock for packedstring-0.1.0.1...
>
> Preprocessing library packedstring-0.1.0.1...
>
> Warning: The documentation for the following packages are not installed.
> No
> links will be generated to these packages: ffi-1.0, rts-1.0
>
> haddock: internal Haddock or GHC error:
> /local/maeder//lib/ghc-6.12.0.20091010/html/haddock.css: openFile: does
> not exist (No such file or directory)
> Installing library in
>
> /local/maeder/lib/packedstring-0.1.0.1/ghc-6.12.0.20091010
>
> Registering packedstring-0.1.0.1...
>
>
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users