6.8 unable to derive with higher-kinded variable (6.6 could)
GHC 6.8 seems unable to derive (some?) instances for data types with
higher-kinded variables. GHC 6.6 manages these just fine. See below.
What's the story?
thanks
-m
:~/haskell$ cat D.hs
data T w = T (w Bool) deriving (Show)
data ID x = ID x deriving (Show)
main = print (T (ID False))
:~/haskell$ ghci -ignore-dot-files -fallow-undecidable-instances D.hs
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.6.1, for Haskell
98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\/\/ /_/\/|_| Type :? for help.
Loading package base ... linking ... done.
[1 of 1] Compiling Main ( D.hs, interpreted )
Ok, modules loaded: Main.
*Main main
T (ID False)
*Main :q
Leaving GHCi.
:~/haskell$ ${GHC_682_BIN}/ghci -ignore-dot-files -fallow-undecidable-instances
D.hs
GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help
Loading package base ... linking ... done.
[1 of 1] Compiling Main ( D.hs, interpreted )
D.hs:1:0:
No instance for (Show (w Bool))
arising from the 'deriving' clause of a data type declaration
at D.hs:1:0-48
Possible fix: add an instance declaration for (Show (w Bool))
When deriving the instance for (Show (T w))
Failed, modules loaded: none.
Prelude
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Curious behaviour of irrefutable pattern.
Bernie Pope [EMAIL PROTECTED] writes: ... Mike, what do you mean by willy nilly convert my error calls to bottom? Simon Peyton-Jones [EMAIL PROTECTED] writes: In general, GHC (like every other compiler that does strictness analysis) feels free to change non-termination into a call to 'error' and vice versa. One could change that, but a lot of programs would become less efficient as a result. I was concerned by the vice versa conversion--from an error call to non-termination. If more than one bottoms (say, a non-termination and an error call) are present in my program, I'm fine with getting any one of them. If I have only an error call, though, I do want to see an error message. An infinite loop would be unhelpful. So, I would consider it an unfriendly willy nilly convertion for GHC to generate code for: import System.Environment ( getArgs ) main = getArgs = putStrLn . head that failed to terminate when I passed no command-line arguments. -m ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Curious behaviour of irrefutable pattern.
In general, GHC (like every other compiler that does strictness analysis) feels free to change non-termination into a call to 'error' and vice versa. Under what circumstances does the (error - non-termination) transformation happen? I'd be unhappy if (head ) put me into an infinite loop instead of giving me an error message. Do you mean if I have both an infinite loop and an error call, then I might get only the loop? thanks -m ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Curious behaviour of irrefutable pattern.
| Do you mean if I have both an infinite loop and an error call, then I | might get only the loop? Absolutely. That's fine and what I expected. I take it, then, that the answer to the question of under what circumstances does the (error - non-termination) transformation happen? is that GHC can choose among different bottoms that are present in the program. It can't, however, willy-nilly convert my error calls to bottom. (Or something more precise along the same lines.) Or no? thanks -m ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Overlapping instances and multi-parameter classes
Given the following:
import Data.Maybe ( fromMaybe )
data None
none = error none evaluated :: None
these class and instance declarations:
classToMaybe2 ba where toMaybe2 :: a - Maybe b
instance ToMaybe2 a None where toMaybe2 = const Nothing
instance ToMaybe2 aa where toMaybe2 = Just
compile fine (given -fallow-undecidable-instances and
-fallow-overlapping-instances). And the following code:
mbPutStrLn:: ToMaybe2 String a = a - IO ()
mbPutStrLn= putStrLn . fromMaybe None. . toMaybe2
main = mbPutStrLn none mbPutStrLn Hello, world!
works as I'd expect. However, if the parameters to the class
are reversed:
{- uncomment to see error message
classToMaybe1 ab where toMaybe1 :: a - Maybe b
instance ToMaybe1 None a where toMaybe1 = const Nothing
instance ToMaybe1 aa where toMaybe1 = Just
-}
I get the following error message (from GHC{,i} 6.2):
Overlapping instance declarations:
OverlapOrder.lhs:27: ToMaybe1 None a
OverlapOrder.lhs:28: ToMaybe1 a a
Why is this?
thanks,
mike
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc and signal processing
Hmmm. With -O2 on GHC 6.2, I get 0.177s, 0.217s, and 0.348s for your three Haskell examples and 0.187s (with gcc -O2) for your C example. The output of -ddump-simpl for the looks perfect for the second Haskell example. My GHC seems to be doing a bang-up job here. What's wrong with yours? (For the third example GHC's code could be improved by additional inlining or hoisting of a constant array outside of the loop.) mike ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHCi and Unboxed tuples
I just finished tracking down the source of the following error from GHCi: ghc-6.2: panic! (the `impossible' happened, GHC version 6.2): Bytecode generator can't handle unboxed tuples. Possibly due to foreign import/export decls in source. Workaround: compile this module to a .o file, then restart session. Some clue to the source of the problem would be quite helpful. (I expect just about anything to at least be sometime useful -- even if it's the low-level input to bytecode generator.) It turns out the source of the problem is a definition in an imported .hi file. Would it be possible for GHCi to prune the inlined definitions containing unboxed tuples and use the non-inlined ones? (Are the non-inline definitions are in the object file? nm suggests they are.) The best fix, of course, would be to make the bytecode generator handle unboxed tuples. thanks, mike ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc warnings messed up in 6.01
Simon seems to have agreed that The Right Thing is to treat bindings with names beginning with an underscore as if they are used w.r.t. to the bindings they use (they're already treated as used w.r.t. warnings for themselves.) With this enhancement (and the other warning fixes apparently already in HEAD), you should be able to change ds to _ds and get no warnings. BTW (here's the real point of my message :-)), is this enchancement planned? For when? Thanks. mike has anyone else noticed that the warnings generated by ghc appear to have become quite incorrect in many cases? in particular, the 'defined but not used' warning is generated spuriously a lot. almost as if it is being checked after dead code elimination and desugaring of some sort.. here is an example which touches all the reproducable bugs I have found. module Main(main) where import List(nub) import Monad() as = repeat 'a' bs = repeat 'b' ds = nub as cs = [(a,b) | a - as | b - bs] main = print $ take 10 cs ;ghc -W -fglasgow-exts Foo.hs Foo.hs:1: Warning: Module `List' is imported, but nothing from it is used (except perhaps instances visible in `List') Foo.hs:1: Warning: Module `Monad' is imported, but nothing from it is used (except perhaps instances visible in `Monad') Foo.hs:7: Warning: Defined but not used: ds Foo.hs:9: Warning: Defined but not used: b Foo.hs:9: Warning: Defined but not used: a notice: 1) it claims nothing is used by List, when 'nub' definatly is being used. (technically true, since ds is not used, but this warning is more confusing than anything. my first inclination is to delete the import line, causing the program to fail to compile, the only fix seems to be to track down the root by hand) 2) it claims Monad is unused, when I specifically imported it with () meaning I don't want any names from it. (i.e., I just want instances) 3) defined but not used 'ds': yay! the only valid warning. 4,5) variables bound in parallel list comprehensions always seem to generate warnings. AFAIK, none of these were problems in earlier versions of ghc, they are quite anoying as they obscure valid warnings. my guess is some desugarings and warning passes were accidentally switched around.. problem 1 is particularly bad, since a single unused toplevel could cascade to generating a ton of warnings, all of which must be sorted through to find the actual cause. the others are just anoying as there doesn't seem to be a workaround short of disabling warnings. John -- --- John Meacham - California Institute of Technology, Alum. - [EMAIL PROTECTED] --- ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Request: suppress specific warnings at specific places
I wrote: GHC's excellent warnings are very helpful. They would be somewhat more so if it were possible to suppress a warning about a specific bit of code Then Simon Marlow [EMAIL PROTECTED] wrote: (of course, the workaround is to put the offending code into a module of its own, and use OPTIONS to turn off the appropriate warnings). This doesn't seem to work (easily) for me. I want -Wall applied to all my source, so give it on the command line. Because the OPTIONS options get prepended, the -Wall seems to win out. :(. I could add -Wall at the top of all my source files, but that's unappealing. If GHC provided a way to have a command-line options appear before the OPTION options in the final list, that would work. mike ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Request: suppress specific warnings at specific places
If the switches take affect at the line granularity there would seem
to be a straightforward implementation that's orthogonal to most
everything else: store the excluded regions in separate data structure
and check that data structure before printing a message.
mike
GHC's excellent warnings are very helpful. They would be somewhat
more so if it were possible to suppress a warning about a specific bit
of code. One possible syntax (to which I gave no commitment) would be
{-# WOFF non-exhaustive pattern matches #-}
offending code
{-# WON non-exhaustive pattern matches #-}
. Another would be
{-# WOFF 523 #-}
offending code
{-# WON 523 #-}
where 523 is a warning number emitted with the warning message.
This would be particularly useful with the recently granted wish for
-Werror.
This would be nice, but it would be tricky to implement: declarations
have to be tagged with a list of exceptions to the prevailing warning
settings. I doubt we'll do this any time soon, but patches are welcome
as usual...
(of course, the workaround is to put the offending code into a module of
its own, and use OPTIONS to turn off the appropriate warnings).
Cheers,
SImon
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Request: suppress specific warnings at specific places
GHC's excellent warnings are very helpful. They would be somewhat
more so if it were possible to suppress a warning about a specific bit
of code. One possible syntax (to which I gave no commitment) would be
{-# WOFF non-exhaustive pattern matches #-}
offending code
{-# WON non-exhaustive pattern matches #-}
. Another would be
{-# WOFF 523 #-}
offending code
{-# WON 523 #-}
where 523 is a warning number emitted with the warning message.
This would be particularly useful with the recently granted wish for
-Werror.
mike
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Passing values taking implicit parameters
I'd like write a function taking values with implicit parameters. I can't get this to
work in a
straightforward way in GHC 5.02 (with -fno-monomorphism-restriction.) In particular,
if I try:
wF :: ((?x :: Int) = a) - Int - a -- compiles but tf won't work
wF s z = s with ?x = z
f :: (?x :: Int) = Int
f = (?x + 3)
-- tf :: Int -- If uncommented GHC fails because can't
deduce context (?x::Int)
-- tf :: (?x :: Int) = Int -- Type GHC assigns to tf
tf = wF f 8 -- Trying to evaluate gives: Unbound implicit
parameter (?x :: Int)
Trying to evaluate tf gives: Unbound implicit parameter (?x :: Int)
On the other hand, if the passed value has another class in its context, things work
as expected:
wF' :: Integral a = (forall a . (Integral a, ?x :: Int) = a) - Int - a
wF' s z = s with ?x = z
f' :: (Integral a, ?x :: Int) = a
f' = fromIntegral (?x + 3)
tf' = wF' f' 8-- GHCi gives me 11, as expected
At the cost of having to wrap each value with an extra call (to dummy here), I seem
to be able to get the
desired effect for general types with this code:
class DummyCl c where dummy :: a - c a
newtype Dummy a = Dummy { unDummy :: a }
instance DummyCl Dummywhere dummy = Dummy
wF'' :: (forall c . (DummyCl c, ?x :: Int) = c a) - Int - a
wF'' s z = unDummy (s with ?x = z)
-- f'' :: (DummyCl c, ?x :: Int) = c Int -- Type signature unnecessary
f'' = dummy f
tf'' = wF'' f'' 100 -- evaluates
fHO = dummy (?x +)
tfHO = (wF'' fHO 31) 22 -- evaluates
tf''' = wF'' (dummy f) 1000 -- gets: Unbound implicit parameter
(?x :: Int)
tf4 = wF'' (dummy (?x + 7)) 300 -- evaluates
tfHO' = (wF'' (dummy (show . (?x +))) 50) 63 -- evaluates
So my questions are: Is there a straightforward way to pass values taking implicit
parameters in GHC? And, if
not, is there a better workaround than my dummy code above?
thanks,
mike
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Why a context reduction stack overflow?
Compilation, with ghc 5.02, of the following program: data Zero = Zero deriving Show data Succ a = Succ aderiving Show -- Compilations succeeds with the following line uncommented. -- t :: Succ Zero -- = t = Zero `p` (Succ Zero) class P a b c | a b - c where p :: a - b - c instanceP Zero a a where p Zero a = a instance P a b c = P b a c where p ba = p a b main = putStrLn $ Hello. succeeds with the indicated line uncommented. With it commented-out, the compilation fails with: Flip.hs:6: Context reduction stack overflow; size = 21 Use -fcontext-stack20 to increase stack size to (e.g.) 20 `P (Succ Zero) Zero c' arising from use of `p' at Flip.hs:6 `P Zero (Succ Zero) c' arising from use of `p' at Flip.hs:6 `P (Succ Zero) Zero c' arising from use of `p' at Flip.hs:6 `P Zero (Succ Zero) c' arising from use of `p' at Flip.hs:6 ... `P (Succ Zero) Zero c' arising from use of `p' at Flip.hs:6 `P Zero (Succ Zero) c' arising from use of `p' at Flip.hs:6 `p at [Zero Succ Zero c]' arising from use of `p' at Flip.hs:6 When generalising the type(s) for t . Why? thanks, mike gunter ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc image size
You may not like this argument but its kind are essential to the strategic part of engineering. Since you bring it up, let's consider whether it's worthwhile to optimize code for time. I'm less familiar with the costs of labour but around here (Silicon Valley) labor costs are well in excess of a cent per second. When last I checked, good generalist engineering consultants were charging more than $150/hour (specialists cost more.) (And remember that, like for disk space, their costs are higher than their price.) The rates may have come down somewhat lately but I'm quite sure costs are still well in excess of one cent per second. Moreover, lots of programs take many, many seconds to run and get run many times. So, optimization for time can save you a lot of expensive people time over the long haul. It's worth putting some effort there. One can make a case for reducing executable size in certain contexts. For instance, it's not unreasonable to work to make code loaded by web browsers smaller -- those executables have to be repeatedly moved over slow links while people are waiting. In my environment, though, I don't see much benefit in smaller GHC executables. Are there contexts where it matters more? GHC's resources (the implementation team, the constructive criticism of users, etc.) are limited. I'd hate to see them spent on unimportant things. mike Mike Gunter [EMAIL PROTECTED] writes: Why is executable size a barrier? 1.64 megabytes (that's the size of the executable I built with GHC most recently) of disk space costs less than half a cent. I don't like this argument. Can I go to a computer store, pay a cent, and get a hard disk with space 1.64 megabytes or more? Until then, I can't believe that 1.64 megabytes of disk space costs less than half a cent. When a compiler does not perform as good as other compilers (e.g., in terms of generated code size), it is important to ask: Why does it happen? Is there anything we can do to improve it? Being critical is the first step towards progress. (Of course these questions should be asked in a constructive rather than whining way.) Why would anyone optimize code for time --- a second of electricity and labour cost less than a cent... ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Trying to make Hood work with GHC
Below are the diffs I used to get from the 4.08 version to one that
compiles and seems to work with 5.00.
mike
diff -c -a -r1.1 Observe.lhs
*** Observe.lhs 10 Jan 2001 16:21:12 - 1.1
--- Observe.lhs 25 Jul 2001 16:44:09 -
***
*** 107,113
\begin{code}
import Exception ( catchAll
! , Exception(..)
, throw
, catchAllIO
)
--- 107,113
\begin{code}
import Exception ( catchAll
! , Exception(..), IOException
, throw
, catchAllIO
)
***
*** 269,275
generate an IOError with a bottom in it, your just asking for trouble.
\begin{code}
! instance Observable IOError where { observer = observeBase }
\end{code}
Functions.
--- 269,275
generate an IOError with a bottom in it, your just asking for trouble.
\begin{code}
! instance Observable IOException where { observer = observeBase }
\end{code}
Functions.
Alain Cremieux [EMAIL PROTECTED] writes:
Hi,
I'm currently trying to have Hood work with GHC, but I have some
problems
- I have succeeded in using the hugs version of Hood
- I have dowloaded the GHC version (slightly different) but the
compilation of the 'Observe' modules fails (the module is supposed to
work with GHC 4.08 and I have GHC 5.00.2) :
...
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: process file table full?
One might think it would be best to trigger a garbage collection before giving up and raising the exception. Or no? mike "Simon Marlow" [EMAIL PROTECTED] writes: Yesterday I asked for the posssible reasons of Fail: resource exhausted Action: openFile Reason: process file table full connect-985988146.log Writing that particular file wasn't the cause, but just a symptom. It seems that I forgot to close filehandles obtained from Socket.accept. I somehow thought they were garbage collecteted, but apparently the weren't. They should be garbage collected and closed automatically. But it may be some time between the handle becoming garbage and it finally being closed, so if you're accepting connections at a fast rate, it's always a good idea to close the handle explicitly when you finish with it. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
