Re: Fundeps and type equality
Hello Conal, GHC implementation of functional dependencies is incomplete: it will use functional dependencies during type inference (i.e., to determine the values of free type variables), but it will not use them in proofs, which is what is needed in examples like the one you posted. The reason some proving is needed is that the compiler needs to figure out that for each instantiation of the type `ta` and `tb` will be the same (which, of course, follows directly from the FD on the class). As far as I understand, the reason that GHC does not construct such proofs is that it can't express them in its internal proof language (System FC). It seems to me that it should be fairly straight-forward to extend FC to support this sort of proof, but I have not been able to convince folks that this is the case. I could elaborate, if there's interest. In the mean time, the way forward would probably be to express the dependency using type families, which I find tends to be more verbose but, at present, is better supported in GHC. Cheers, -Iavor PS: cc-ing the GHC users' list, as there was some talk of closing the ghc-bugs list, but I am not sure if the transition happened yet. On Tue, Dec 25, 2012 at 6:15 PM, Conal Elliott co...@conal.net wrote: I ran into a simple falure with functional dependencies (in GHC 7.4.1): class Foo a ta | a - ta foo :: (Foo a ta, Foo a tb, Eq ta) = ta - tb - Bool foo = (==) I expected that the `a - ta` functional dependency would suffice to prove that `ta ~ tb`, but Pixie/Bug1.hs:9:7: Could not deduce (ta ~ tb) from the context (Foo a ta, Foo a tb, Eq ta) bound by the type signature for foo :: (Foo a ta, Foo a tb, Eq ta) = ta - tb - Bool at Pixie/Bug1.hs:9:1-10 `ta' is a rigid type variable bound by the type signature for foo :: (Foo a ta, Foo a tb, Eq ta) = ta - tb - Bool at Pixie/Bug1.hs:9:1 `tb' is a rigid type variable bound by the type signature for foo :: (Foo a ta, Foo a tb, Eq ta) = ta - tb - Bool at Pixie/Bug1.hs:9:1 Expected type: ta - tb - Bool Actual type: ta - ta - Bool In the expression: (==) In an equation for `foo': foo = (==) Failed, modules loaded: none. Any insights about what's going wrong here? -- Conal ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2798: Enable rec keyword when RecursiveDo is enabled?
Hello, so with these changes, what is the preferred way to write recursive monadic code that will work on GHC 6.12.1, GHC = 6.12.1, and Hugs? I guess, one could always fall back to just using mfix directly but this seems unfortunate. -Iavor On Sun, Jan 3, 2010 at 5:23 AM, GHC t...@galois.com wrote: #2798: Enable rec keyword when RecursiveDo is enabled? ---+ Reporter: nominolo | Owner: igloo Type: task | Status: closed Priority: high | Milestone: 6.14.1 Component: Compiler | Version: 6.11 Resolution: fixed | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---+ Changes (by igloo): * status: new = closed * failure: = None/Unknown * resolution: = fixed Comment: It was done for 6.12.1 after all. `RecursiveDo` is deprecated in favour of `DoRec`. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2798#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Broken Cabal
Hello, I am not sure if this is the correct place to report this problem, but there is a bug in the Cabal distributed with GHC. I used the simplest possible Setup.hs file as shown in the documentation. All the modules in my library are in a directory Monad, e.g. Monad/State.hs, Monad/Reader.hs, etc. When I type: runhaskell Setup.lhs sdist I get a source tar-ball but when I extract the files I get the following: monadLib-1.2.2/ monadLib-1.2.2/nad/ monadLib-1.2.2/nad/BackT.hs monadLib-1.2.2/nad/ExceptT.hs monadLib-1.2.2/nad/Reader.hs Notice that the Mo part of the directory name is missing. -Iavor ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
'type' declarations
hello, ghc seems to be having trouble with 'type' declarations. while compiling (i guess kind checking is the correct word here) the following program for a very long time, ghc (6.2) runs out of 300Mb of heap. module Test where type S = Maybe type S2 n = S (S n) type S4 n = S2 (S2 n) type S8 n = S4 (S4 n) type S16 n = S8 (S8 n) type S32 n = S16 (S16 n) type N64 n = S32 (S32 n) type N64' = S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( S ( Int if i remove the N64 definition things work. i guess something exponential is happening (substitution?). -iavor ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Unboxed integers
Hello, There is something strange that is going on with unboxed types in GHC (6.2). I think it is a bug, but perhaps I am missing something. If so, I am quite curious as to what is going on. Here is the example: import GHC.Exts First we define a function that will give us the bottom element of the unboxed integers. bot:: () - Int# bot () = bot () Now we can define a function that will check if we have bottom or not, by terminating or not. stops :: Int# - Bool stops _ = True test1 :: Bool test1 = stops (bot ()) As expected (by me), 'test1' does not terminate --- to unbox values we have to be strict in them. So far everything makes sense. However if we simply make 'stops' into a local function, it starts terminating: test2 :: Bool test2 = stops (bot ()) where stops :: Int# - Bool stops _ = True -Iavor ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
GHC panic/loop (mdo)
Hello, the following program makes GHC 6.2.2 loop forever (testLoop) or panic (testPanic). I tried to derive small examples that illustrate the problem. The problem seems to be related to the use of 'mdo', and it looks like it is important that the expressoin 'f x' is repeated. import Control.Monad.Fix main :: IO () main= return () This makes the compiler loop. testLoop _ = mdo x - mapM undefined (f x) let f _ = [] return (f x) This makes the compiler panic. testPanic _ = mdo x - f x let f _ = return () f x Hope this helps Iavor ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
compiler (simplifier) loops
hello,
the following program makes the compiler (version 6.0.1) loop.
the same seems to happen on 5.04.2.
when i run it with -v, it seems that it gets stuck in the simplifier.
newtype T a = Close { open :: T a - a }
fix :: (a - a) - a
fix f = s (Close s)
where s x = f (open x x)
also the flag:
-fmax-simplifier-iterations
is not recognized on 6.0.1
bye
iavor
--
==
| Iavor S. Diatchki, Ph.D. student |
| Department of Computer Science and Engineering |
| School of OGI at OHSU |
| http://www.cse.ogi.edu/~diatchki |
==
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Bug with implicit parameters?
hello,
i seem to have stumbled onto a bug in ghc.
here is my system info:
root in base: uname -a
Linux localhost.localdomain 2.2.17-21mdk #1 Thu Oct 5 13:16:08 CEST 2000 i686
unknown
root in base: gcc -v
Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/specs
gcc version 2.95.3 19991030 (prerelease)
this is the program causing the problem:
root in base: cat hugsBug.hs
module Main where
class (?imp :: Int) = C t
main = putStrLn "Hello"
here is what happens when i try to compile it:
root in base: ghc -fglasgow-exts hugsBug.hs
Prelude.(!!): index too large
here is the same thing with the -v flag:
root in base: ghc -v -fglasgow-exts hugsBug.hs
The Glorious Glasgow Haskell Compilation System, version 4.08.1
Effective command line: -v -fglasgow-exts
Ineffective C pre-processor:
echo '{-# LINE 1 "hugsBug.hs" -}' /tmp/ghc1434.cpp cat hugsBug.hs
/tmp/ghc1434.cpp
0.00user 0.01system 0:00.00elapsed 142%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (116major+18minor)pagefaults 0swaps
ghc:compile:Interface file hugsBug.hi doesn't exist
ghc:recompile:Input file hugsBug.hs newer than hugsBug.o
Haskell compiler:
/usr/lib/ghc-4.08.1/hsc /tmp/ghc1434.cpp -fglasgow-exts
-fignore-interface-pragmas -fomit-interface-pragmas -fsimplify [
-fmax-simplifier-iterations4 ] -fwarn-overlapping-patterns -fwarn-missing-methods
-fwarn-missing-fields -fwarn-deprecations -fwarn-duplicate-exports -fhi-version=408
-static
"-himap=.%.hi:/usr/lib/ghc-4.08.1/imports/lang%.hi:/usr/lib/ghc-4.08.1/imports/lang%.hi:/usr/lib/ghc-4.08.1/imports/std%.hi"
"-himap-sep=:"-v -hifile=/tmp/ghc1434.hi -olang=asm -ofile=/tmp/ghc1434.s
-F=/tmp/ghc1434_stb.c -FH=/tmp/ghc1434_stb.h +RTS -H600 -K100
Glasgow Haskell Compiler, version 4.08, for Haskell 98, compiled by GHC version
4.08
Prelude.(!!): index too large
Command exited with non-zero status 1
0.27user 0.05system 0:00.33elapsed 94%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1348major+1597minor)pagefaults 0swaps
deleting... /tmp/ghc1434.cpp /tmp/ghc1434.hi /tmp/ghc1434.s /tmp/ghc1434_stb.c
/tmp/ghc1434_stb.h
rm -f /tmp/ghc1434*
the problem seems to be the lack of functions in the class.
if i add a member function the file compiles fine.
the problem seems to be somehow related with the implict parameter
constraint as it does not occur if i place a normal class constraint instead.
i am vague on how exactly implict parameters are implemented, but i suspect
the compiler trys to somehow annotate all member functions with the
additional constraint and there is no check to see if there are any memebr
functions. unfortunately i dont have the source for the compiler
so all of the above is just speculation.
bye
iavor
--
+-+---+
|Iavor S. Diatchki| email: [EMAIL PROTECTED] |
|Dept. of Computer Science| web: http://www.cse.ogi.edu/~diatchki |
|Oregon Graduate Institute| tel: 5037481631 |
+-+---+
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
