Mismatched contexts

Hello,

I observed the following behavior on GHC-6.0.1 and CVS HEAD.
With -fglasgow-exts the following program

data Functions =
    Functions { f1, f2 :: Integral a => a -> a }

functions :: Functions
functions =
    Functions { f1 = (\x -> x),
		f2 = f2b
	      }

f2a, f2b :: Integral a => a -> a

f2a = f1 functions
f2b x = x

is accepted by GHC, but if I change
  f2 = f2b
to
  f2 = f2a
in the definition of `functions', GHC says

    Mismatched contexts
    When matching the contexts of the signatures for
      functions :: Functions
      f2a :: forall a. (Integral a) => a -> a
    The signature contexts in a mutually recursive group

ghc fails "hello world" on ppc

$ uname -a
Linux fly 2.4.19-quiet #10 Tue Jan 12 17:02:50 PST 1904 ppc GNU/Linux
$ cat > test.hs                 
main =
    do
    putStr "hello\n"
    putStr "world\n"
$ ghc --make test.hs && ./a.out       
Chasing modules from: test.hs
Compiling Main             ( test.hs, ./test.o )
Linking ...
world
world

On my i386 machine it works correctly: 

$ ghc --make test.hs && ./a.out
Chasing modules from: test.hs
Compiling Main             ( test.hs, ./test.o )
Linking ...
hello
world

Various permutations of the original program produce the same result
on the ppc:
----------------------------------------------------------------
import System.IO
main =
    do
    hSetBuffering stdout NoBuffering

Mismatched contexts

Armin Größlinger writes:
 :
 | GHC says
 | 
 |     Mismatched contexts
 |     When matching the contexts of the signatures for
 |       functions :: Functions
 |       f2a :: forall a. (Integral a) => a -> a
 |     The signature contexts in a mutually recursive group
 |       should all be identical
 |     When generalising the type(s) for functions, f2a
 :
 | I don't understand why the contexts must be identical in mutually
 | recursive definitions.
 :

Hi.

I don't know why that particular example was rejected, but if you're
after some general discussion of contexts in mutually recursive
groups, see section 11.6.3 of Typing Haskell in Haskell
(http://www.cse.ogi.edu/~mpj/thih/).

Regards,
Tom

Problems with Template Haskell

Template Haskell seems to be type-checking some quasi-quotes, even when they
are not going to be used.  This is of course a terrible nuisance, since it
means it can't be used to work around interface incompatibilities between
libraries for different versions of GHC (such as the recent change in
RegexString.matchRegexAll's type).  Maybe I will have to go back to using
cpp ...

For example, the attached file fails to compile.

# ghc TestSplice.hs -c -fglasgow-exts
 >
 > TestSplice.hs:7:
 >     Couldn't match `f a' against `Bool'
 >       Expected type: f a
 >       Inferred type: Bool
 >     In the second argument of `fmap', namely `True'
 >     In the definition of `TestSplice.p': TestSplice.p = fmap id True

This occurs for both ghc 6.0.1 and the recent snapshot  6.3.20031201

Another problem is that Template Haskell objects to undefined variables in
unused splices.  Thus if I replace "p = fmap id True" in the
attached file by "foo = bar", I get "TestSplice2.hs:7: Variable not in scope: `bar'"

module TestSplice where

$(
   if False

RE: Problems with Template Haskell

I'd be interested to know what others think.

A big story for Template Haskell is that many type errors are found when
you *define* the macro (= template function) rather than when you *call*
the macro.  In TestSplice2 you had 
x = $(if False
          then
            [d|
            foo = bar
            |]
        else
          [d|
            d = 2
           |]
       )

This is rather artificial example; typically the condition will be
computed.  If TH didn't complain about the absence of 'bar', you might
well get an error when you splice x, maybe months later.

Still, in your cpp-like application, I guess your story is that the
condition might evaluate to True only if the system configuration was
such that bar was in scope.  If the condition evaluates to False, then
bar really might not be available.

OK, in TH (version 2 -- CVS HEAD) you want dynamic binding. You can say

	$(if ... then [|d foo = $(dyn "bar") |] .. )

Now you won't get any type complaint, and "bar" will get looked up at

Re: Problems with Template Haskell

Simon Peyton-Jones wrote (snipped):

> Still, in your cpp-like application, I guess your story is that the
> condition might evaluate to True only if the system configuration was
> such that bar was in scope.  If the condition evaluates to False, then
> bar really might not be available.
> 
> OK, in TH (version 2 -- CVS HEAD) you want dynamic binding. You can say
> 
> 	$(if ... then [|d foo = $(dyn "bar") |] .. )
> 
> Now you won't get any type complaint, and "bar" will get looked up at
> the splice site of x. 

This is a bit cumbersome.  Could there be some way of wrapping the whole
quasi-quotation to stop it from being looked at in any way, except what
is strictly necessary for converting it to a Q Dec or Q Exp, unless and
until it is actually spliced?  In fact, I for one would prefer that to be
the default ...

I appreciate that there are workarounds like $(dyn ...), and I've also
come up with the solution of declaring

    idVar = [| id |]

and then using $idVar in quasi-quotations, as a way of obfuscating the
type so GHC doesn't complain.  This is what is known as fighting the compiler ...

> Does that help?

internal error: evacuate: strange closure type 33544

Hi guys,

I have no idea what this is:

8:45am dixiechicks:DUC04/ ../SVMseq/SVMseqLearn -m 1800 --string-maxn=3 -h 
0 data.dis.svm data.dis.model-linear
Reading training examples.................13612 examples read (highest 
feature=13)
Initializing...SVMseqLearn: internal error: evacuate: strange closure type 
33544
    Please report this as a bug to glasgow-haskell-bugs <at> haskell.org,
    or http://www.sourceforge.net/projects/ghc/
695.190u 4.160s 11:39.41 99.9%  0+0k 0+0io 250pf+0w
8:56am dixiechicks:DUC04/ 

unfortunately, this is the first time i've seen this error and, as you can 
see, the program was running for a *long* time before it cropped up.  if 
you want, i can send you the source/data files it was running on, but i 
don't know that you'd be able to glean much information from that...

 - hal

--

-- 
 Hal Daume III                                   | hdaume <at> isi.edu
 "Arrest this man, he talks in maths."           | www.isi.edu/~hdaume

Re: internal error: evacuate: strange closure type 33544

I recompiled after a minor change (which is in code that hasn't been 
reached at the point this error occurs) and am now getting:

9:39am dixiechicks:DUC04/ ../SVMseq/SVMseqLearn -m 1800 --string-maxn=3 -h 
0 data.dis.svm data.dis.model-linear
Reading training examples.....Segmentation fault (core dumped)

9:40am dixiechicks:DUC04/ ../SVMseq/SVMseqLearn -m 1800 --string-maxn=3 -h 
0 data.dis.svm data.dis.model-linear
Reading training examples...SVMseqLearn: internal error: scavenge: 
unimplemented/strange closure type 23675  <at>  0x406960b0
    Please report this as a bug to glasgow-haskell-bugs <at> haskell.org,
    or http://www.sourceforge.net/projects/ghc/

9:40am dixiechicks:DUC04/ ../SVMseq/SVMseqLearn -m 1800 --string-maxn=3 -h 
0 data.dis.svm data.dis.model-linear
Reading training examples...Segmentation fault (core dumped)

9:40am dixiechicks:DUC04/ ../SVMseq/SVMseqLearn -m 1800 --string-maxn=3 -h 
0 data.dis.svm data.dis.model-linear
Reading training examples...Segmentation fault (core dumped)

9:40am dixiechicks:DUC04/ ../SVMseq/SVMseqLearn -m 1800 --string-maxn=3 -h 
0 data.dis.svm data.dis.model-linear
Reading training examples...SVMseqLearn: internal error: scavenge: 
unimplemented/strange closure type 1001  <at>  0x406640d0
    Please report this as a bug to glasgow-haskell-bugs <at> haskell.org,
    or http://www.sourceforge.net/projects/ghc/

On Fri, 5 Dec 2003, Hal Daume III wrote:

RE: internal error: evacuate: strange closure type 33544

Did you do a complete recompile from scratch, or is this the result of
ghc --make after modifications?  (there's a known bug in --make which
can cause this).

Are you using any custom GC options (eg. in the GHCRTS env. variable)?

If it's a recompile from scratch, can you package it up so we can
investigate?

Cheers,
	Simon

> -----Original Message-----
> From: glasgow-haskell-bugs-bounces <at> haskell.org 
> [mailto:glasgow-haskell-bugs-bounces <at> haskell.org] On Behalf 
> Of Hal Daume III
> Sent: 05 December 2003 17:40
> To: glasgow-haskell-bugs <at> haskell.org
> Subject: Re: internal error: evacuate: strange closure type 33544
> 
> I recompiled after a minor change (which is in code that hasn't been 
> reached at the point this error occurs) and am now getting:
> 
> 9:39am dixiechicks:DUC04/ ../SVMseq/SVMseqLearn -m 1800 
> --string-maxn=3 -h 
> 0 data.dis.svm data.dis.model-linear
> Reading training examples.....Segmentation fault (core dumped)
> 
> 9:40am dixiechicks:DUC04/ ../SVMseq/SVMseqLearn -m 1800 
> --string-maxn=3 -h 

RE: internal error: evacuate: strange closure type 33544

I believe it was a --make after modifications (but not to the 'Main' 
module).  Probably related to the earlier bug then -- a recompile from 
scratch seems to have fixed it.

On Mon, 8 Dec 2003, Simon Marlow wrote:

> Did you do a complete recompile from scratch, or is this the result of
> ghc --make after modifications?  (there's a known bug in --make which
> can cause this).
> 
> Are you using any custom GC options (eg. in the GHCRTS env. variable)?
> 
> If it's a recompile from scratch, can you package it up so we can
> investigate?
> 
> Cheers,
> 	Simon
> 
> > -----Original Message-----
> > From: glasgow-haskell-bugs-bounces <at> haskell.org 
> > [mailto:glasgow-haskell-bugs-bounces <at> haskell.org] On Behalf 
> > Of Hal Daume III
> > Sent: 05 December 2003 17:40
> > To: glasgow-haskell-bugs <at> haskell.org
> > Subject: Re: internal error: evacuate: strange closure type 33544
> > 
> > I recompiled after a minor change (which is in code that hasn't been 
> > reached at the point this error occurs) and am now getting:
> > 
> > 9:39am dixiechicks:DUC04/ ../SVMseq/SVMseqLearn -m 1800