George Russell writes:
> The recent version, 3.77, of gmake seems to be a bit too clever
> (or maybe too stupid) for GHC's device of not updating a .hi file
> which is identical to the last one generated. It appears to me
> as if gmake is saving on a call to fstat by assuming that .hi
> has be
> The whole thing boils down to:
>
> \begin{code}
> module Main (main) where
> main :: IO ()
> main = if 1*2 == 0 then putStrLn "GHC(GCC 2.95) can't multiply, eh?"
>else putStrLn "not reached"
> \end{code}
>
> Strange, isn't it?
I've tracked this down as far as PrelNum.hs in
I have been looking at the GHC 4.04 sources a little lately and in the
module FastString (in ghc/compiler/utils), the instance for Eq is defined as
follows:
instance Eq FastString where
a == b = case cmpFS a b of { LT -> False; EQ -> true; GT -> False }
...
and cmpFS will return EQ if
> For a test, I want to compile the whole ghc including all
> libraries to .hc
> files. For one version, I'll use gcc-2.95, for the other
> egcs-1.1.2 (aka
> egcs-2.91.66). However, I don't fully understand the Make
> configuration of ghc,
> so is there a way to tell make and ghc to keep interm
Michael Weber <[EMAIL PROTECTED]> wrote
[snip]
> forkChild :: IO () -> IO (MVar ())
> forkChild p = do
> mvar <- newEmptyMVar
> forkIO (p >> putMVar mvar ())
> return mvar
This does not of course synthesise a non-daemonic forkIO from a daemonic one, because
it requires the parent threa
It's the monomorphism restriction (MR) again.
The MR says that you can only use threefreshnames at one type.
When you put the defn in Main.hs, it can "see" that threefreshnames
is used at type LabelVar, so that's the type GHC chooses. When
threefreshnames is defined in Row, it can't see any uses
Hello,
In Row.hs, `threefreshnames' suffers from a type error due to the monomorphic
restriction. So, I give an explicit type declaration to prevent the type error.
Both ghc4.04 and hugs98 make it to infer types.
Accidentally, I move the declaration of `threefreshnames' to Main.hs.
Then, ghc
