From Christian.Maeder at dfki.de Tue Apr 1 05:10:01 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Apr 1 05:06:01 2008 Subject: patch-applied messages In-Reply-To: <47F0BFD6.5070804@dfki.de> References: <20080326020302.GA26263@haskell.galois.com> <47F0BFD6.5070804@dfki.de> Message-ID: <47F1FBE9.3060402@dfki.de> Christian Maeder wrote: > could the actual change-diff of patches also be posted via > the list cvs-ghc@haskell.org I just see that patches sent to cabal-devel@haskell.org have a link to the actual patch. I.e. View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080329194426-adfee-0e5c64288be06f7f0d81af18fcec9eee83ef00d5.gz Could such links also be added to cvs-ghc@haskell.org messages? Thanks Christian From simonpj at microsoft.com Tue Apr 1 07:21:29 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Apr 1 07:17:31 2008 Subject: simple CSE? In-Reply-To: References: Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32ABA04772B@EA-EXMSG-C334.europe.corp.microsoft.com> Not reliably, no. GHC's current CSE is rather opportunistic: we take the opportunity if it's presented in the form let x = e in let y = e in .... A proper CSE pass would be a nice, containable, project. Simon From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Conal Elliott Sent: 29 March 2008 01:53 To: glasgow-haskell-users@haskell.org Subject: simple CSE? I'd like to know if it's possible to get GHC to perform some simple CSE for function-level programming. Here's a simple example: liftA2 (*) sin sin :: Double -> Double which inlines and simplifies to \ t -> sin t * sin t A more realistic, equivalent, example: let b = sin <$> id in liftA2 (*) b b Can GHC be nudged into computing 'sin t' once rather than twice? Thanks, - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080401/85308839/attachment.htm From cperfumo at gmail.com Tue Apr 1 11:03:19 2008 From: cperfumo at gmail.com (Cristian Perfumo) Date: Tue Apr 1 10:59:23 2008 Subject: ANN: prof2dot, a graphical profiling tool In-Reply-To: <6BE969B5-113C-4DAC-89AC-B215AAE60E88@comcast.net> References: <6BE969B5-113C-4DAC-89AC-B215AAE60E88@comcast.net> Message-ID: I was wondering if it handles per-thread information when you have more than one thread involved. (Actually the question is not related to the graphical tool, but the announcement triggered it). Best. Cristian 2008/3/8 Gregory Wright : > > > I am pleased to announce the first release of prof2dot, a graphical > profiling tool > for use with GHC. > > While GHC has in the past worked with graphical profiling tools, they > have been heavyweight and/or proprietary. Prof2dot is a simple tool for > converting profiling information into a graphical format, released under a > BSD3 > license. It is simple because it offloads all of the work of rendering > the graph > onto Graphviz. So you need to install the Graphviz tools in order to use > it. > > The program is a filter that takes the profiling output generated by > running > a GHC-compiled program with the "+RTS -px -RTS" option and turns it into > a dot file. (The "dot" format is a textual representation of a directed > or undirected graph.) > The dot file can rendered in any format supported by Graphviz's > dot program, and the file itself can be post-processed or edited to adjust > the > layout. > > Features of prof2dot: > > * display either the call graph (default) or the call tree, > > * colorize by cost center count, time or allocations, > > * group cost centers in the same module. > > Prof2dot installs as a typical caballized application. > Running "prof2dot -?" from the command line will give a short summary of > how to use the program and its options. > > Rendering very large graphs can exceed the internal resource limits of > dot. > You may have to compile your own version of the Graphviz tools with higher > limits > to handle these cases. > > A example of a colorized profile of a medium sized project is shown on our > company's web site: http://antiope.com/downloads.html. > Click on the small > image to download a pdf of the complete profile graph. > > Prof2dot is available from hackage or the link given above. > > > -Greg > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080401/4f82931c/attachment.htm From mail at joachim-breitner.de Tue Apr 1 12:30:43 2008 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue Apr 1 12:26:53 2008 Subject: ghc fails to find the right instance Message-ID: <1207067443.3494.12.camel@otto.ehbuehl.net> Hi, I was told on #haskell that I should bring this up here, to ask whether this is a bug in ghc6 or otherwise explain this to me. I?m trying to write the function "addd" which takes an arbitrary number of Integer arguments and returns the sum. This code works: -- Try 1 class More a where more ::Integer -> a instance (More a, Integral i) => More (i -> a) where more v1 v2 = more (v1 + toInteger v2) instance More Integer where more v = v addd :: More a => a addd = more 0 printI :: Integer -> IO () printI = print main = do printI $ addd printI $ addd 1 printI $ addd 1 2 printI $ addd 1 2 3 -- SNIP But when I try to use a concret type (Integer) instead of the (Integral i =>) condition (which should make the program more concrete, I?d say) and write the following instance: -- Try 2 (changed lines of code) instance More a => More (Integer -> a) where more v1 v2 = more (v1 + v2) -- SNIP I get this error: test.hs:4:0: Illegal instance declaration for `More (Integer -> a)' (All instance types must be of the form (T a1 ... an) where a1 ... an are distinct type *variables* Use -XFlexibleInstances if you want to disable this.) In the instance declaration for `More (Integer -> a)' Failed, modules loaded: none. Well, I add {-# LANGUAGE FlexibleInstances #-} and get this error for the line "printI $ addd 1" (and similar errors for the other following addd lines): test.hs:19:17: No instance for (More (t -> Integer)) arising from a use of `addd' at test.hs:19:17-22 Possible fix: add an instance declaration for (More (t -> Integer)) In the second argument of `($)', namely `addd 1' In the expression: printI $ addd 1 In a 'do' expression: printI $ addd 1 And this is the point where I?m lost and would like to ask for hints what this means. Thanks, Joachim -- Joachim "nomeata" Breitner mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nomeata@debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080401/ba855517/attachment.bin From claus.reinke at talk21.com Tue Apr 1 12:53:07 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Tue Apr 1 12:49:13 2008 Subject: ghc fails to find the right instance References: <1207067443.3494.12.camel@otto.ehbuehl.net> Message-ID: <21b101c89418$ddf81c50$e6278351@cr3lt> 'Integer -> a' is more concrete, less general than 'i -> a', so it matches fewer types. '1 :: Num a => a' is more general than 'Integer'. | No instance for (More (t -> Integer)) | arising from a use of `addd' at test.hs:19:17-22 if nothing forces the parameter (!) to be Integer, the more concrete instance won't match. try type-annotating the numeric literals. claus From mail at joachim-breitner.de Tue Apr 1 13:12:49 2008 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue Apr 1 13:09:00 2008 Subject: ghc fails to find the right instance In-Reply-To: <21b101c89418$ddf81c50$e6278351@cr3lt> References: <1207067443.3494.12.camel@otto.ehbuehl.net> <21b101c89418$ddf81c50$e6278351@cr3lt> Message-ID: <1207069969.7207.2.camel@otto.ehbuehl.net> Hi, Am Dienstag, den 01.04.2008, 17:53 +0100 schrieb Claus Reinke: > 'Integer -> a' is more concrete, less general than 'i -> a', > so it matches fewer types. > > '1 :: Num a => a' is more general than 'Integer'. > > | No instance for (More (t -> Integer)) > | arising from a use of `addd' at test.hs:19:17-22 > > if nothing forces the parameter (!) to be Integer, the > more concrete instance won't match. try type-annotating > the numeric literals. Indeed, printI $ addd (1::Int) (2::Int) (3::Int) does work. But I can?t follow your explanation completely. When I use the variant with Integer, ghc will not use the instance because (1::Num a => a) is too general. But why does it use the Integral i-Instance in the working variant? (1::Num a=> a) is also more general than (1::Integral i => i), isn?t it? Thanks, Joachim -- Joachim "nomeata" Breitner mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nomeata@debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080401/f963edeb/attachment-0001.bin From claus.reinke at talk21.com Tue Apr 1 15:11:52 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Tue Apr 1 15:07:56 2008 Subject: ghc fails to find the right instance References: <1207067443.3494.12.camel@otto.ehbuehl.net><21b101c89418$ddf81c50$e6278351@cr3lt> <1207069969.7207.2.camel@otto.ehbuehl.net> Message-ID: <21ed01c8942c$40322880$e6278351@cr3lt> |But I can?t follow your explanation completely. When I use the variant |with Integer, ghc will not use the instance because (1::Num a => a) is |too general. | |But why does it use the Integral i-Instance in the working variant? |(1::Num a=> a) is also more general than (1::Integral i => i), isn?t it? because instance selection does not take instance contexts into account (a frequent source of feature requests;-): http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensions.html#instance-overlap so, the match is against 'i', and the 'Integral i' is added to the constraints needing proof *after* that instance has been chosen. claus From gwright at comcast.net Wed Apr 2 02:17:40 2008 From: gwright at comcast.net (Gregory Wright) Date: Wed Apr 2 02:14:10 2008 Subject: ANN: prof2dot, a graphical profiling tool In-Reply-To: References: <6BE969B5-113C-4DAC-89AC-B215AAE60E88@comcast.net> Message-ID: <21AFD150-0A8A-4F2E-9175-0D594488E22D@comcast.net> Hi Cristian, On Apr 1, 2008, at 11:03 AM, Cristian Perfumo wrote: > I was wondering if it handles per-thread information when you have > more than one thread involved. (Actually the question is not related > to the graphical tool, but the announcement triggered it). The prof2dot tool only knows about the information that is in the profiling dump file. IIRC, cost centers are not associated with threads in this file. (The format isn't documented, but it is not hard to figure out, given a look at the code that generates it.) Is recording the thread in which a cost was incurred really helpful? If it is, I could look into adding it. But are you more interested in a graphical representation of thread execution --- which threads are executing and when? You should check if any of the old Glasgow Parallel Haskell tools are close to what you want. If so, it might be less work to resurrect one of those. Best Wishes, Greg > > Best. > Cristian > > 2008/3/8 Gregory Wright : > > > I am pleased to announce the first release of prof2dot, a graphical > profiling tool > for use with GHC. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080402/40e0ffa6/attachment.htm From Patrick.Surry at portraitsoftware.com Wed Apr 2 16:26:04 2008 From: Patrick.Surry at portraitsoftware.com (Patrick Surry) Date: Wed Apr 2 16:22:13 2008 Subject: Confused about typing in ghci Message-ID: <93BECC602E286B499D5443ECB850D2FF0126A60F@newman.usa.aitgroupad.com> I'm new to Haskell and functional programming; have been exploring the fixed-point combinator based on the exercise in the HSOE book. Having an odd issue with typing in ghci which I don't understand - maybe it's to do with section 3.4.5. "Type defaulting in GHCi" but I don't really grok that yet... (BTW, an unrelated question: is there a good reference where I can understand the precendence/associativity rules for Haskell? I continually find myself needing lots of parens before expressions behave as I expect, and get very confused trying to use the $ operator - usually resorting to lots of parens again :-) My typing question might boil down to this simple example, though my original example follows: -- Why don't these (particularly g and g') all have the same type? Prelude> :t (\x -> x+1) (\x -> x+1) :: (Num a) => a -> a Prelude> let g = (\x -> x+1) Prelude> :t g g :: Integer -> Integer Prelude> let g' x = x + 1 Prelude> :t g' g' :: (Num a) => a -> a -- Here's my original fixed-point combinator example: Prelude> let fix f = f (fix f) -- here's a silly (but working) implementation of length using fix: Prelude> fix (\g xs -> if xs == [] then 0 else (1 + g (tail xs))) [1,2,3,4] 4 -- so I examine the types of the parts, which seems fine: Prelude> :t fix (\g xs -> if xs == [] then 0 else (1 + g (tail xs))) ... :: (Num t, Eq a) => [a] -> t Prelude> :t (\g xs -> if xs == [] then 0 else (1 + g (tail xs))) ... :: (Num t, Eq a) => ([a] -> t) -> [a] -> t -- but now I try to bind the anonymous function to a name -- this seems to get the types wrong and no longer works as I expect: Prelude> let lenstep = (\g xs -> if xs == [] then 0 else (1 + g (tail xs))) Prelude> :t lenstep lenstep :: ([()] -> Integer) -> [()] -> Integer Prelude> :t fix lenstep fix lenstep :: [()] -> Integer Prelude> let len' = fix (\g xs -> if xs == [] then 0 else (1 + g (tail xs))) Prelude> :t len' len' :: [()] -> Integer Prelude> Prelude> len' [1,2,3,4] :1:12: No instance for (Num ()) arising from the literal `4' at :1:12 Possible fix: add an instance declaration for (Num ()) In the expression: 4 In the first argument of `len'', namely `[1, 2, 3, 4]' In the expression: len' [1, 2, 3, 4] -- maybe this is just me not understanding name binding properly; it seems to work if I do it this way: Prelude> let lenstep' g xs = (if xs == [] then 0 else (1 + g (tail xs))) Prelude> :t lenstep' lenstep' :: (Eq a, Num t) => ([a] -> t) -> [a] -> t Prelude> :t fix lenstep' fix lenstep' :: (Eq a, Num t) => [a] -> t Prelude> fix lenstep' [1,2,3,4] 4 -- but what's the difference? Cheers, Patrick Patrick.Surry@portraitsoftware.com , VP Technology Tel: (617) 457 5230 Mob: (857) 919 1700 Fax: (617) 457 5299 Map Portrait Software introduces Portrait Campaign Manager : Easy, integrated campaign management for automated and highly targeted outbound marketing http://supportcentre.portraitsoftware.com/Vmail/emailfooter/balloon.gif http://supportcentre.portraitsoftware.com/Vmail/emailfooter/portrait_sof tware_logo.gif www.portraitsoftware.com ________________________________________________________________________ DISCLAIMER: This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. If you received this email in error, please notify the sender and delete the message from your computer. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080402/bd2fe14e/attachment-0001.htm From mdanish at andrew.cmu.edu Wed Apr 2 16:40:03 2008 From: mdanish at andrew.cmu.edu (Matthew Danish) Date: Wed Apr 2 16:35:59 2008 Subject: Confused about typing in ghci In-Reply-To: <93BECC602E286B499D5443ECB850D2FF0126A60F@newman.usa.aitgroupad.com> References: <93BECC602E286B499D5443ECB850D2FF0126A60F@newman.usa.aitgroupad.com> Message-ID: <20080402204003.GD25960@mapcar.org> On Wed, Apr 02, 2008 at 04:26:04PM -0400, Patrick Surry wrote: > -- Why don't these (particularly g and g') all have the same type? > Prelude> :t (\x -> x+1) > (\x -> x+1) :: (Num a) => a -> a > Prelude> let g = (\x -> x+1) > Prelude> :t g > g :: Integer -> Integer > Prelude> let g' x = x + 1 > Prelude> :t g' > g' :: (Num a) => a -> a It's the monomorphism restriction in action, along with defaulting. Basically, the rule is: Any binding of the form "g = ..." where there are no parameters *syntactically* must not be polymorphic with type-class restrictions. If you disable it with -fno-monomorphism-restriction then the differences go away. In addition, Haskell has some special-case "defaulting" rules for turning Num classed type-variables into concrete types, which explains the appearance of "Integer" specifically. The reason for existence of this restriction is that such a "g" may be recomputed for each use, much like a function call. This could lead to surprising behavior, though perfectly safe. In Haskell, it's not such a big deal, because of pure code, so some people prefer to turn the restriction off. Your options are to turn it off, always write syntactic parameters like "g x = ...", or provide an explicit polymorphic type signature like "g :: Num a => a -> a". -- -- Matthew Danish -- user: mrd domain: cmu.edu -- OpenPGP public key: C24B6010 on keyring.debian.org From Patrick.Surry at portraitsoftware.com Wed Apr 2 16:54:36 2008 From: Patrick.Surry at portraitsoftware.com (Patrick Surry) Date: Wed Apr 2 16:50:43 2008 Subject: Confused about typing in ghci In-Reply-To: <20080402204003.GD25960@mapcar.org> References: <93BECC602E286B499D5443ECB850D2FF0126A60F@newman.usa.aitgroupad.com> <20080402204003.GD25960@mapcar.org> Message-ID: <93BECC602E286B499D5443ECB850D2FF0126A620@newman.usa.aitgroupad.com> Thanks for the quick reply - I'm not sure I really understand exactly what your rule means, but it's led me over to http://www.haskell.org/haskellwiki/Monomorphism_restriction where it seems possible that I might eventually figure it out :) Any thoughts on the other question about where I can go to understand Haskell's precedence/associativity rules better (and avoid so many parens)? Cheers, Patrick -----Original Message----- From: Debian User [mailto:mdanish@andrew.cmu.edu] Sent: Wednesday, April 02, 2008 4:40 PM To: Patrick Surry Cc: glasgow-haskell-users@haskell.org Subject: Re: Confused about typing in ghci On Wed, Apr 02, 2008 at 04:26:04PM -0400, Patrick Surry wrote: > -- Why don't these (particularly g and g') all have the same type? > Prelude> :t (\x -> x+1) > (\x -> x+1) :: (Num a) => a -> a > Prelude> let g = (\x -> x+1) > Prelude> :t g > g :: Integer -> Integer > Prelude> let g' x = x + 1 > Prelude> :t g' > g' :: (Num a) => a -> a It's the monomorphism restriction in action, along with defaulting. Basically, the rule is: Any binding of the form "g = ..." where there are no parameters *syntactically* must not be polymorphic with type-class restrictions. If you disable it with -fno-monomorphism-restriction then the differences go away. In addition, Haskell has some special-case "defaulting" rules for turning Num classed type-variables into concrete types, which explains the appearance of "Integer" specifically. The reason for existence of this restriction is that such a "g" may be recomputed for each use, much like a function call. This could lead to surprising behavior, though perfectly safe. In Haskell, it's not such a big deal, because of pure code, so some people prefer to turn the restriction off. Your options are to turn it off, always write syntactic parameters like "g x = ...", or provide an explicit polymorphic type signature like "g :: Num a => a -> a". -- -- Matthew Danish -- user: mrd domain: cmu.edu -- OpenPGP public key: C24B6010 on keyring.debian.org ________________________________________________________________________ DISCLAIMER: This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. If you received this email in error, please notify the sender and delete the message from your computer. From mdanish at andrew.cmu.edu Wed Apr 2 17:06:07 2008 From: mdanish at andrew.cmu.edu (Matthew Danish) Date: Wed Apr 2 17:02:03 2008 Subject: Confused about typing in ghci In-Reply-To: <93BECC602E286B499D5443ECB850D2FF0126A620@newman.usa.aitgroupad.com> References: <93BECC602E286B499D5443ECB850D2FF0126A60F@newman.usa.aitgroupad.com> <20080402204003.GD25960@mapcar.org> <93BECC602E286B499D5443ECB850D2FF0126A620@newman.usa.aitgroupad.com> Message-ID: <20080402210607.GE25960@mapcar.org> On Wed, Apr 02, 2008 at 04:54:36PM -0400, Patrick Surry wrote: > Thanks for the quick reply - I'm not sure I really understand exactly > what your rule means, but it's led me over to > http://www.haskell.org/haskellwiki/Monomorphism_restriction where it > seems possible that I might eventually figure it out :) Really, don't overthink it too much. Anything that looks like g = ... syntactically (that means, as written in the file) cannot have a polymorphic type-class restricted type (something with a "=>" in the type). The distinction being made is that "g = ..." has nothing but space in between the "g" and the "=". No parameters syntactically. > Any thoughts on the other question about where I can go to understand > Haskell's precedence/associativity rules better (and avoid so many > parens)? The Haskell Report, perhaps? -- -- Matthew Danish -- user: mrd domain: cmu.edu -- OpenPGP public key: C24B6010 on keyring.debian.org From marlowsd at gmail.com Thu Apr 3 12:47:31 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Apr 3 12:43:46 2008 Subject: scope of header files In-Reply-To: <47D854D3.901@gmail.com> References: <1204758974.11558.256.camel@localhost> <20080305234641.GA29735@soi.city.ac.uk> <1204763015.11558.305.camel@localhost> <20080306013705.GA4914@sliver.repetae.net> <47D6FDF9.6050404@gmail.com> <20080312174355.GA15073@sliver.repetae.net> <47D854D3.901@gmail.com> Message-ID: <47F50A23.7070000@gmail.com> Simon Marlow wrote: > John Meacham wrote: >> On Tue, Mar 11, 2008 at 02:47:37PM -0700, Simon Marlow wrote: >>> Yeah, I'd like -fvia-C to be headerless. We talked about it a while >>> back (on the haskell-prime list I think). The main issue is that GHC >>> would have to generate prototypes based on the FFI declaration, and >>> since it can't guarantee to generate a prototype that is exactly the >>> same as the C prototype given in the header file (e.g. it doesn't >>> know about const), we would have to ensure that there really are no >>> other prototypes in scope, to prevent errors from the C compiler. >> >> I was thinking that you just wouldn't include any extra c headers at all >> then, just write out the appropriate c code to call with the conventions >> specified in the ffi import specification and you won't need external >> headers at all so there isn't anything to conflict with. > > Yes, pretty much. There are a bunch of C headers that define the macros > used by the generated C code, and we have to be careful that they don't > include anything external - in the past we used to #include several > things from /usr/include, but I think we're much cleaner these days. FYI, I've now done this: GHC 6.10 will consistently ignore c-includes and header files in FFI declarations. Cheers, Simon From waldmann at imn.htwk-leipzig.de Fri Apr 4 08:07:23 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Fri Apr 4 08:03:16 2008 Subject: Wanted: migration guide from ghc-6.6 to ghc-6.8 Message-ID: <47F619FB.8000300@imn.htwk-leipzig.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear all, I could use a list of things to watch out for when converting Haskell sources written for ghc-6.6 for compilation with ghc-6.8. Of course I'll try write down some items while I find them but I'd hope not to start at zero... Is there an easy way to get a "library API diff" (automatically, say, from full 6.6 and 6.8 installations)? Best regards, Johannes Waldmann. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH9hn73ZnXZuOVyMIRAk1nAKDEteU/FHMHz4yDgL936r/rRfLy5gCfTTFz 0fv7U+nP4ELZ9xZT/qicODc= =B50t -----END PGP SIGNATURE----- From olivier.boudry at gmail.com Fri Apr 4 09:14:20 2008 From: olivier.boudry at gmail.com (Olivier Boudry) Date: Fri Apr 4 09:10:11 2008 Subject: Wanted: migration guide from ghc-6.6 to ghc-6.8 In-Reply-To: <47F619FB.8000300@imn.htwk-leipzig.de> References: <47F619FB.8000300@imn.htwk-leipzig.de> Message-ID: Hi Johanes, You could look at the following wiki page: http://haskell.org/haskellwiki/Upgrading_packages It lists most of the issues you may face when upgrading to GHC-6.8 and Cabal 1.2. Hope this helps, Olivier. On Fri, Apr 4, 2008 at 1:07 PM, Johannes Waldmann < waldmann@imn.htwk-leipzig.de> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dear all, > > I could use a list of things to watch out for > when converting Haskell sources written for ghc-6.6 > for compilation with ghc-6.8. > > Of course I'll try write down some items while I find them > but I'd hope not to start at zero... > > Is there an easy way to get a "library API diff" > (automatically, say, from full 6.6 and 6.8 installations)? > > Best regards, Johannes Waldmann. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.4-svn0 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFH9hn73ZnXZuOVyMIRAk1nAKDEteU/FHMHz4yDgL936r/rRfLy5gCfTTFz > 0fv7U+nP4ELZ9xZT/qicODc= > =B50t > -----END PGP SIGNATURE----- > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080404/71978a09/attachment.htm From simonpj at microsoft.com Mon Apr 7 05:14:34 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Apr 7 05:10:16 2008 Subject: [GHC] #2153: GHCi does not have a :source command to load further .ghci files In-Reply-To: <052.3c4132b63087efb25d0e1dd5966447d6@localhost> References: <043.51c925bf8ca398d8c29d97455f25e3eb@localhost> <052.3c4132b63087efb25d0e1dd5966447d6@localhost> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE39A1BAF@EA-EXMSG-C334.europe.corp.microsoft.com> | Wow, that simple??? | | What needs to be done to get this in ":?" output? (It should be in the | manual, at least...) Indeed! But it's more application-note than user manual. Fortunately, we have a place for such material, namely GHC's "collaborative documentation" (a wiki) http://haskell.org/haskellwiki/GHC Would someone like to copy Claus's excellent message http://www.haskell.org/pipermail/haskell-cafe/2007-September/032260.html to the Wiki documentation on GHCi, here: http://haskell.org/haskellwiki/GHC/GHCi (with his permission of course). That's the right place for it. Sam, you'd be an ideal person to do this, because you know what you wanted in the first place, so you could make sure the answer is easy to find. But anyone else would do fine! Simon | -----Original Message----- | From: glasgow-haskell-bugs-bounces@haskell.org [mailto:glasgow-haskell-bugs-bounces@haskell.org] On | Behalf Of GHC | Sent: 07 April 2008 02:46 | Cc: glasgow-haskell-bugs@haskell.org | Subject: Re: [GHC] #2153: GHCi does not have a :source command to load further .ghci files | | #2153: GHCi does not have a :source command to load further .ghci files | ---------------------+------------------------------------------------------ | Reporter: SamB | Owner: | Type: bug | Status: closed | Priority: normal | Milestone: | Component: GHCi | Version: 6.8.2 | Severity: normal | Resolution: wontfix | Keywords: | Difficulty: Unknown | Testcase: | Architecture: Unknown | Os: Unknown | | ---------------------+------------------------------------------------------ | Comment (by SamB): | | Wow, that simple??? | | What needs to be done to get this in ":?" output? (It should be in the | manual, at least...) | | -- | Ticket URL: | GHC | The Glasgow Haskell Compiler From waldmann at imn.htwk-leipzig.de Mon Apr 7 08:40:41 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Mon Apr 7 08:36:30 2008 Subject: Wanted: migration guide from ghc-6.6 to ghc-6.8 In-Reply-To: <47F6257B.5090309@dfki.de> References: <47F619FB.8000300@imn.htwk-leipzig.de> <47F6257B.5090309@dfki.de> Message-ID: <47FA1649.4040809@imn.htwk-leipzig.de> >> list of things to watch out for >> when converting Haskell sources written for ghc-6.6 >> for compilation with ghc-6.8. Thanks for the pointers. Luckily, only a few changes were needed, http://leiffrenzel.de/eclipse/wiki/doku.php?id=hare_with_gh-6.8 (sic). and most of them related to GHC API. I'm not completely sure whether it's semantically correct but at least it compiles. Best regards, J.W. From claus.reinke at talk21.com Tue Apr 8 20:14:53 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Tue Apr 8 20:10:37 2008 Subject: [GHC] #2153: GHCi does not have a :source command to load further .ghci files References: <043.51c925bf8ca398d8c29d97455f25e3eb@localhost><052.3c4132b63087efb25d0e1dd5966447d6@localhost> <638ABD0A29C8884A91BC5FB5C349B1C32AE39A1BAF@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <018a01c899d6$beaeffd0$0a407ad5@cr3lt> it is actually in the users guide, just not where one would find it when looking for a way to do this.. http://www.haskell.org/ghc/docs/latest/html/users_guide/ghci-commands.html section 3.7 (GHCi commands), as one of the examples for using ':def'. perhaps it would help to (-: todo; +: done): - repeat the ':def :. readFile' example in section 3.9 (The .ghci file), http://www.haskell.org/ghc/docs/latest/html/users_guide/ghci-dot-files.html where more people are likely to find it. having this command seems essential for debugging .ghci files - in section 3.9, add a link to the haskell wiki page, referring to http://haskell.org/haskellwiki/GHC/GHCi as "examples of useful .ghci definitions" (that page could do with some improvements, though) + i've added a link to my old tutorial to that haskell wiki page, feel free to use the text from that message or the .ghci files - section 3.9 doesn't seem to reflect the current situation wrt .ghci locations on windows! i tried at the time to get others to post their .ghci files at well, and share their favourite tricks, but there weren't many responses. hth, claus ----- Original Message ----- From: "Simon Peyton-Jones" To: Cc: "Claus Reinke" Sent: Monday, April 07, 2008 10:14 AM Subject: RE: [GHC] #2153: GHCi does not have a :source command to load further .ghci files >| Wow, that simple??? > | > | What needs to be done to get this in ":?" output? (It should be in the > | manual, at least...) > > Indeed! But it's more application-note than user manual. Fortunately, we have a place for such > material, namely GHC's "collaborative documentation" (a wiki) > http://haskell.org/haskellwiki/GHC > > Would someone like to copy Claus's excellent message > http://www.haskell.org/pipermail/haskell-cafe/2007-September/032260.html > to the Wiki documentation on GHCi, here: > http://haskell.org/haskellwiki/GHC/GHCi > > (with his permission of course). That's the right place for it. Sam, you'd be an ideal person to > do this, because you know what you wanted in the first place, so you could make sure the answer is > easy to find. But anyone else would do fine! > > Simon > > > | -----Original Message----- > | From: glasgow-haskell-bugs-bounces@haskell.org [mailto:glasgow-haskell-bugs-bounces@haskell.org] > On > | Behalf Of GHC > | Sent: 07 April 2008 02:46 > | Cc: glasgow-haskell-bugs@haskell.org > | Subject: Re: [GHC] #2153: GHCi does not have a :source command to load further .ghci files > | > | #2153: GHCi does not have a :source command to load further .ghci files > | ---------------------+------------------------------------------------------ > | Reporter: SamB | Owner: > | Type: bug | Status: closed > | Priority: normal | Milestone: > | Component: GHCi | Version: 6.8.2 > | Severity: normal | Resolution: wontfix > | Keywords: | Difficulty: Unknown > | Testcase: | Architecture: Unknown > | Os: Unknown | > | ---------------------+------------------------------------------------------ > | Comment (by SamB): > | > | Wow, that simple??? > | > | What needs to be done to get this in ":?" output? (It should be in the > | manual, at least...) > | > | -- > | Ticket URL: > | GHC > | The Glasgow Haskell Compiler > -------------------------------------------------------------------------------- > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From gale at sefer.org Wed Apr 9 09:23:41 2008 From: gale at sefer.org (Yitzchak Gale) Date: Wed Apr 9 09:19:28 2008 Subject: [GHC] #2153: GHCi does not have a :source command to load further .ghci files In-Reply-To: <018a01c899d6$beaeffd0$0a407ad5@cr3lt> References: <043.51c925bf8ca398d8c29d97455f25e3eb@localhost> <052.3c4132b63087efb25d0e1dd5966447d6@localhost> <638ABD0A29C8884A91BC5FB5C349B1C32AE39A1BAF@EA-EXMSG-C334.europe.corp.microsoft.com> <018a01c899d6$beaeffd0$0a407ad5@cr3lt> Message-ID: <2608b8a80804090623i7ca89d11m5a08d2c6aec9b649@mail.gmail.com> Claus Reinke wrote: > i tried at the time to get others to post their .ghci files at well, > and share their favourite tricks, but there weren't many responses. OK, OK. I just posted "Customized GHCi interactive environments" to wiki. It's a simple but very powerful trick that I use all the time. I hope others will also post their favorites. -Yitz From ndmitchell at gmail.com Thu Apr 10 10:21:38 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Apr 10 10:17:09 2008 Subject: Unexpected lack of optimisation in -O0 Message-ID: <404396ef0804100721i31bbc176lb22d7593b5a95037@mail.gmail.com> Hi, I just tried compiling the following program: foo = (1 :: Int) == (2 :: Int) with ghc --ddump-simpl, and no optimisation flags, in GHC 6.6.1 The resultant code is: Test.foo = case GHC.Base.$f2 of tpl_X8 { GHC.Base.:DEq tpl1_B2 tpl2_B3 -> tpl1_B2 (GHC.Base.I# 1) (GHC.Base.I# 2) } GHC has introduced dictionaries in this example. In comparison, Yhc and nhc wouldn't introduce dictionaries here, as the type class desugaring knows the type of the item is fixed, and makes a direct call to the appropriate function. If the desugaring was changed, it would make programs in GHCi run faster, would reduce the size of programs, and would speed up the optimiser, as it would have less to do. I am not sure how much additional work this would require in the simplifier, but if it was minimal, the gains would probably be worth it. I was just reading the Monad.Reader, where a Yhc based Haskell Interpreter states that comparisons against GHCi are "unfair", because Yhc gains too much benefit from this desguaring. Thanks Neil From bulat.ziganshin at gmail.com Thu Apr 10 10:21:44 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Apr 10 10:22:07 2008 Subject: Unexpected lack of optimisation in -O0 In-Reply-To: <404396ef0804100721i31bbc176lb22d7593b5a95037@mail.gmail.com> References: <404396ef0804100721i31bbc176lb22d7593b5a95037@mail.gmail.com> Message-ID: <814028334.20080410182144@gmail.com> Hello Neil, Thursday, April 10, 2008, 6:21:38 PM, you wrote: > I was just reading the Monad.Reader, where a Yhc based Haskell > Interpreter states that comparisons against GHCi are "unfair", because > Yhc gains too much benefit from this desguaring. i believe that dictionaries is the most important point of haskell inefficiency (second one is laziness) and this feature may allow ghci/ghc-O0 to became much faster -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From dbueno at gmail.com Sat Apr 12 11:03:18 2008 From: dbueno at gmail.com (Denis Bueno) Date: Sat Apr 12 10:58:45 2008 Subject: Wrong Answer Computing Graph Dominators Message-ID: <6dbd4d000804120803v14bb53d5i3556d20039358d16@mail.gmail.com> I'm using the Data.Graph.Inductive.Query.Dominators library (http://haskell.org/ghc/docs/latest/html/libraries/fgl/Data-Graph-Inductive-Query-Dominators.html). The library is a bit spare on comments, so I may or may not be using it correctly. My goal is to compute the set of nodes that dominate two different nodes of a DAG, with respect to one initial node. My approach is: import qualified Data.Graph.Inductive.Graph as Graph import qualified Data.Graph.Inductive.Query.Dominators as Dom uips = intersect domConfl domAssigned :: [Graph.Node] -- my goal domConfl = fromJust $ lookup conflNode domFromLastd -- dominators of first node domAssigned = fromJust $ lookup (negate conflNode) domFromLastd -- dominators of second node domFromLastd = Dom.dom conflGraph lastd -- source node I compute the dominators individually and my answer is their intersection. When I call the dom function, my assumption is that I need to pass it the source node, and it tells me, for any node x to which there is a path from the source, the list of nodes for which *any path* from source to x must touch, i.e., the list of dominators of x. The DAG in question is attached as a postscript file, which is generated by `dot -Tps` using the output of the Graphviz module directly from the graph object. The nodes for which I'm computing dominators are labeled -2 and 2 (that is, conflNode = 2). The problem is that I think the answer is wrong. In particular I think the set of dominators for -2 is {20, -2}, and the set for 2 is {20, 2}. Their intersection is {20}, which is what I expect. But what I am getting is: --> uips = [-9,20] --> domConfl = [2,-9,20] --> domAssigned = [-2,-9,-12,20] --> lastd = 20 But -9 is not a dominator for 2, since 20,-7,8,6,2 is a path from 20 to 2 that does not touch 9. -9 is also not a dominator for -2, since 20,-7,8,6,-2 is a path from 20 to -2 not touching 9. Am I missing something? I've simplified the code above slightly from the original code in order to ignore some irrelevancies. The original code is for computing a learned clause in a SAT solver. The code in the state that will reproduce the error above is available via a git clone: git clone http://fid.stygian.net/dpllsat Build via cabal, using the --disable-optimization option to configure in order to enable assertions, then run: ./dist/build/dsat/dsat ./tests/problems/uf20/uf20-0226.cnf The graph should be saved in conflict.dot and with `dot -Tps -o conflict.ps conflict.dot` you should be able to turn it into the ps file attached. The problematic code referenced above starts on line 759. -- Denis -------------- next part -------------- A non-text attachment was scrubbed... Name: bad-dominators.ps Type: application/postscript Size: 12697 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080412/773ce669/bad-dominators-0001.ps From duncan.coutts at worc.ox.ac.uk Sun Apr 13 05:54:35 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Apr 13 05:49:59 2008 Subject: [Haskell-cafe] more on my ghc package issues In-Reply-To: <5ae4f2ba0804122133m64651017i7ed6f047ce61756d@mail.gmail.com> References: <5ae4f2ba0804112055h755ce4daj2b160335bced1aee@mail.gmail.com> <22fcbd520804120720j2de9266i3bb27695cd8c8e05@mail.gmail.com> <5ae4f2ba0804120927y3b453b56v77c732f32308b426@mail.gmail.com> <83B4374E-6A2D-4818-B6ED-7E8A67F93B83@ece.cmu.edu> <5ae4f2ba0804122133m64651017i7ed6f047ce61756d@mail.gmail.com> Message-ID: <1208080475.9923.63.camel@dell.linuxdev.us.dell.com> On Sat, 2008-04-12 at 23:33 -0500, Galchin, Vasili wrote: > 2) This strongly looks like the package database manager, i.e. > ghc-pkg. Source please so I can understand where this d*amn "unknown > package: unix-2.3.0.0" message is coming from and why? Yes, ghc/ghc-pkg is giving this message because you're trying to use a package that depends on a package that you unregistered. In your case, you unregistered unix-2.3.0.0 but process-1.0.0.0 depended on that. Cabal depends on process-1.0.0.0 which means you now cannot runghc Setup.hs scripts because they all import Cabal. Look at the output of ghc-pkg list. It marks in {} the packages that are broken due to missing dependencies. Remember you also have two package databases, the per-user one and the global one. The per-user one is stored under ~/.ghc You can see the exact path in the ghc-pkg list output. The packages from the user db mask those from the global db, so if you have messed up the per-user one then you will still get problems even if you reset the global one to default. If you're just trying to get back to a known state then you can delete the per-user ghc package db. ghc-pkg will re-create it next time you register a package as a user. > 3) Serious rant mode on ... I am a computer industry veteran(decades) > who is trying to convince, coggle, etc. younger colleagues about the > usefulness of FPLs for correctness, etc, and then => "unknown > package ....". The error messages from ghc-pkg are not very helpful and it does not prevent you from removing packages which other packages still depend on. The best advice at the moment is, don't un-register packages, at least not without considering what other packages still depend on them. There's no easy way of doing a reverse dependency lookup I think yet via ghc-pkg. You can see direct dependencies, eg $ ghc-pkg field containers depends depends: base-3.0.1.0 array-0.1.0.0 As it happens, the latest version of Cabal gives a much better error message in the case that you try to configure a package that depends on a broken package. It says exactly which package is broken due to which missing dependency. In this case we'd get a message like: The following installed packages are broken because other packages they depend on are missing. These broken packages must be rebuilt before they can be used. package process-1.0.0.0 is broken due to missing package unix-2.3.0.0 It would be nice if ghc/ghci/runghc could give a similarly helpful error message. Duncan From marco-oweber at gmx.de Sun Apr 13 15:36:43 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Sun Apr 13 15:32:06 2008 Subject: ghci: can't load module BitSet, and some others Message-ID: <20080413193643.GD29673@gmx.de> Hi. I'm totally puzzled: ghc-pkg describe ghc shows BitSet as exposed module. When grepping the whole ghc source code the only occurance I can find is in the package.in file for the ghc package. But that't it Trying to load it using GHC-api or ghci fails ? Is this module depreceated and only there for compatibility reasons? darcs changes reveals: Wed Oct 11 15:16:14 CEST 2006 Simon Marlow * remove BitSet, it isn't used So is it time to remove it completely? I can't load all these modules: BitSet FieldLabel IlxGen Java JavaGen PrintJava RegisterAlloc So what's wrong here? Sincerly MarcWeber From marco-oweber at gmx.de Sun Apr 13 18:22:09 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Sun Apr 13 18:17:31 2008 Subject: ghci: can't load module BitSet, and some others In-Reply-To: <20080413193643.GD29673@gmx.de> References: <20080413193643.GD29673@gmx.de> Message-ID: <20080413222209.GA7605@gmx.de> They do no longer exist: > BitSet > FieldLabel > IlxGen > RegisterAlloc I've found this kind of error at least twice error "RegisterAlloc.livenessSCCs" ^^^^^^^^^ I've found this kind of error twice in ghc code.. Should this be updated to the new module name? Don't know about these modules: > Java > JavaGen > PrintJava Does anyone know? Sincerly Marc Weber From waldmann at imn.htwk-leipzig.de Mon Apr 14 06:27:58 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Mon Apr 14 06:23:24 2008 Subject: GHC API (parsing) Message-ID: <480331AE.2090904@imn.htwk-leipzig.de> Dear all, how can I convince the Language.Haskell.Parser to accept "GHC Haskell" (i.e., -fglasgow-exts, e.g. for existential types) or: how can I convince the GHC API loader to parse a module from a string (not from a file)? Any hints appreciated, Johannes. From niklas.broberg at gmail.com Mon Apr 14 06:52:33 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Mon Apr 14 06:47:52 2008 Subject: GHC API (parsing) In-Reply-To: <480331AE.2090904@imn.htwk-leipzig.de> References: <480331AE.2090904@imn.htwk-leipzig.de> Message-ID: > how can I convince the Language.Haskell.Parser to accept "GHC Haskell" > (i.e., -fglasgow-exts, e.g. for existential types) You use my haskell-src-exts package instead. :-) http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src-exts-0.3.3 Cheers, /Niklas From mnislaih at gmail.com Mon Apr 14 07:22:42 2008 From: mnislaih at gmail.com (pepe) Date: Mon Apr 14 07:18:05 2008 Subject: [Haskell-cafe] retrospective on 'seq' -> 'unsafeSeq' ? In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE4D7A6E9@EA-EXMSG-C334.europe.corp.microsoft.com> References: <404396ef0804140307g757887bcr8429d3b8d9cf7545@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE4D7A6E9@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: On 14/04/2008, at 12:19, Simon Peyton-Jones wrote: > | > type constraints accordingly. (Analogously there could be an > unsafeShow that > | > allows showing offending values in an 'error' without adding a > Show > | > constraint to the type signature.) > | > | Ideally, unsafeShow could also show types as they are underneath, > not > | as a pretty-printing Show might show them. I have often wanted to > | overload Show to print things in a readable way, but to have a > showRaw > | which shows things as they are, for debugging purposes. I have even > | written such code for Yhc: > | http://www.cs.york.ac.uk/fp/yhc/snapshot/docs/Yhc-Core-ShowRaw.html > | > | I think unsafeShow is a fantastic idea - and would be much more > useful > | to me than unsafeSeq - plus is a non-breaking change. I think Hugs > | already has 90% of the code to support this, and GHCi's debugger I > | think has a fair chunk of it, so it could be added given not too > much > | work. > > Yes, as you say, the debugger has most of the machinery. I just > don't know what it'd take to make it a callable function. Pepe? > > Someone might want to make a feature-request ticket for this, with > as much background and/or suggested design as poss. unsafeShow sounds quite useful, especially to avoid adding a Show constraint in function signatures only for debugging (of course a decent refactoring tool for Haskell would help with this too, so I hope the HaRe SoC project proposal gets accepted and done!). :print has the code for doing this, but it needs the type information collected by the compiler. In GHC API speak, it needs the HscEnv from the Session object. If we can expose the Session created for GHCi (how? exporting it from GHC.Main? in a thread-local object? FFI trickery?), then this would need nearly zero work, albeit it would print things only when working in GHCi of course. But you can still compile all your modules to object code and call main from GHCi, so I don't think this is a big restriction considering unsafeShow is only for debugging purposes. Another question is where in the package hierarchy would this function live. Since the code it would use is in the ghc package, it would introduce a dependency on it. And I am fairly sure that there is no package in the standard ghc distribution which depends on the ghc package. Ian, can it be made to live in ghc-prim without creating a dependency on the ghc package? Alternatively, with some effort one can create a type-agnostic version of unsafeShow, which would print things in a more raw format, but probably sufficient anyway. I don't think it would work with unboxed values in general, although it can be made to work with the standard types. Actually, Bernie Pope wrote some code for this [1, see GHC Heap Printing library] some time ago, although with the new primitives and changes made for :print in GHC 6.8, this would be way easier nowadays. No need to use StablePtrs, no need to turn on profiling, and above all, no C needed :) And as a bonus this would work out of GHCi too. If there is a clean way to access the Session object, the first option means less implementation work, less code to maintain in GHC, and better functionality. What does the GHC team think? [1] - http://www.cs.mu.oz.au/~bjpop/code.html From waldmann at imn.htwk-leipzig.de Mon Apr 14 07:37:06 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Mon Apr 14 07:32:21 2008 Subject: GHC API (parsing) In-Reply-To: References: <480331AE.2090904@imn.htwk-leipzig.de> Message-ID: <480341E2.9020602@imn.htwk-leipzig.de> > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src-exts-0.3.3 interesting, I'll look into that. * it's not exactly a drop-in replacement for Language.Haskell.* ? (HsNewTypeDecl is different?) * for the others, number of constructor arguments does not match, e.g. `HsConDecl' should have 2 arguments, but has been given 3 * how is your parser tied to ghc? I.e. what happens if the next ghc release introduces new syntax? general question * is there any parser that keeps comments (i.e. makes AST nodes from them)? what parser does Haddock use? Best regards, J.W. From niklas.broberg at gmail.com Mon Apr 14 07:57:40 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Mon Apr 14 07:53:05 2008 Subject: GHC API (parsing) In-Reply-To: <480341E2.9020602@imn.htwk-leipzig.de> References: <480331AE.2090904@imn.htwk-leipzig.de> <480341E2.9020602@imn.htwk-leipzig.de> Message-ID: > * it's not exactly a drop-in replacement for Language.Haskell.* ? > (HsNewTypeDecl is different?) > > * for the others, number of constructor arguments does not match, e.g. > `HsConDecl' should have 2 arguments, but has been given 3 Indeed it is like you say, these are pragmatic choices. The extensions introduce new requirements, and the choice was between modelling only the general case, or separating the H98 case and the extension as two different constructors. I chose the former, since I believe anyone using this library would want to use the extensions anyway, and choosing the latter would have meant a lot of extra boilerplate code (for the user, not me). > * how is your parser tied to ghc? > I.e. what happens if the next ghc release introduces new syntax? It is not at all tied to ghc, other than that I try to keep up with the major extensions that ghc provides. There are some things in ghc that my library does not model, e.g. arrows syntax (patches welcome!). But if there's anything specific that you need that isn't already in there, drop me a feature request and I'll try to fix it for you. Cheers, /Niklas From claus.reinke at talk21.com Mon Apr 14 09:32:42 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Mon Apr 14 09:28:07 2008 Subject: GHC API (parsing) References: <480331AE.2090904@imn.htwk-leipzig.de> <480341E2.9020602@imn.htwk-leipzig.de> Message-ID: <023801c89e34$0666fd80$40107ad5@cr3lt> > general question > > * is there any parser that keeps comments > (i.e. makes AST nodes from them)? what parser does Haddock use? you might want to add your voice and cc to Ticket #1886 ;-) "GHC API should preserve and provide access to comments" http://hackage.haskell.org/trac/ghc/ticket/1886 claus From marco-oweber at gmx.de Mon Apr 14 11:14:33 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Mon Apr 14 11:09:52 2008 Subject: Haskell-src-ext In-Reply-To: References: <480331AE.2090904@imn.htwk-leipzig.de> Message-ID: <20080414151433.GA1271@gmx.de> On Mon, Apr 14, 2008 at 12:52:33PM +0200, Niklas Broberg wrote: > > how can I convince the Language.Haskell.Parser to accept "GHC Haskell" > > (i.e., -fglasgow-exts, e.g. for existential types) > You use my haskell-src-exts package instead. :-) Hi Niklas, nice to meet you. And even nicer to see how well your library is supported :) I'm planning to extend shim to get a more featured ide (vim / emacs.. Maybe the Eclipse supporters do join as well?) One thing I'd like to add is adding modules/ import statements to a module. Do you think your' parsers / resulting abstract syntax tree is suited to add some import statements? Or do you suggest hacking my own fuzzy approach? Is it easy to explain the main difference between your output and the output produced by the GHC parser? Sincerly Marc Weber From waldmann at imn.htwk-leipzig.de Mon Apr 14 11:22:33 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Mon Apr 14 11:17:46 2008 Subject: Haskell-src-ext In-Reply-To: <20080414151433.GA1271@gmx.de> References: <480331AE.2090904@imn.htwk-leipzig.de> <20080414151433.GA1271@gmx.de> Message-ID: <480376B9.2050509@imn.htwk-leipzig.de> > [...] to add some import statements? what is your plan? Leif wrote down some ideas (for eclipsefp2) here: http://leiffrenzel.de/eclipse/wiki/doku.php?id=editororganizeimports best regards, J.W. From niklas.broberg at gmail.com Mon Apr 14 12:02:36 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Mon Apr 14 11:57:55 2008 Subject: Haskell-src-ext In-Reply-To: <20080414151433.GA1271@gmx.de> References: <480331AE.2090904@imn.htwk-leipzig.de> <20080414151433.GA1271@gmx.de> Message-ID: > Hi Niklas, > nice to meet you. Likewise. :-) > I'm planning to extend shim to get a more featured ide (vim / emacs.. > Maybe the Eclipse supporters do join as well?) > > One thing I'd like to add is adding modules/ import statements to a > module. > Do you think your' parsers / resulting abstract syntax tree is suited > to add some import statements? Or do you suggest hacking my own fuzzy > approach? I'd say that's definitely a good use of haskell-src-exts, and very easy to accomplish. A fuzzy approach sounds scary to me. ;-) > Is it easy to explain the main difference between your output and the > output produced by the GHC parser? I'd say the most striking difference is that the AST used by haskell-src-exts is much much simpler than the GHC one. It's only an AST, it doesn't try to cater to the different passes of a compiler to do renaming or any such nonsense. It is also contained in a single module so it is easy to reference (try digging up where some specific constructor in the GHC AST is defined and you'll appreciate the merit of this). For any project that just needs to parse/fiddle with/print haskell source code, I see very little reason to choose GHC API instead of haskell-src-exts. The only reason is of course that GHC API is guaranteed to be up to date with the latest GHC, and will be able to parse exactly everything that GHC does. On the other hand, haskell-src-exts allows you to handle regular patterns and literal XML syntax a la HSP, which GHC doesn't. :-) Cheers, /Niklas From tov at ccs.neu.edu Mon Apr 14 13:44:09 2008 From: tov at ccs.neu.edu (Jesse Tov) Date: Mon Apr 14 13:50:24 2008 Subject: Haskell-src-ext In-Reply-To: References: <480331AE.2090904@imn.htwk-leipzig.de> <20080414151433.GA1271@gmx.de> Message-ID: Niklas Broberg wrote: > For any project that just needs to parse/fiddle with/print haskell > source code, I see very little reason to choose GHC API instead of > haskell-src-exts. Does your pretty-printer round trip? One problem I've had using GHC API is that the pretty-printer produces unparseable output. Jesse From marco-oweber at gmx.de Mon Apr 14 16:14:11 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Mon Apr 14 16:09:33 2008 Subject: GHC API (parsing) In-Reply-To: <023801c89e34$0666fd80$40107ad5@cr3lt> References: <480341E2.9020602@imn.htwk-leipzig.de> <023801c89e34$0666fd80$40107ad5@cr3lt> Message-ID: <20080414201411.GA491@gmx.de> > "GHC API should preserve and provide access to comments" > http://hackage.haskell.org/trac/ghc/ticket/1886 What does this lead to? Introspection? So you can get haddock comments from ghci? This would be interesting Marc Weber From waldmann at imn.htwk-leipzig.de Mon Apr 14 16:51:19 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Mon Apr 14 16:46:58 2008 Subject: GHC API (parsing) In-Reply-To: <20080414201411.GA491@gmx.de> References: <480341E2.9020602@imn.htwk-leipzig.de> <023801c89e34$0666fd80$40107ad5@cr3lt> <20080414201411.GA491@gmx.de> Message-ID: <4803C3C7.3000302@imn.htwk-leipzig.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Introspection? So you can get haddock comments from ghci? see also http://hackage.haskell.org/trac/ghc/ticket/2168 best regards, j.w. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIA8PH3ZnXZuOVyMIRAjnyAJ4qtDaBWUbBIuWGfZnP4yboC08FNQCfYvuX PZmW/t7u1Qnhjxzx4Lz+pys= =XPmx -----END PGP SIGNATURE----- From niklas.broberg at gmail.com Mon Apr 14 17:09:47 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Mon Apr 14 17:05:28 2008 Subject: Haskell-src-ext In-Reply-To: References: <480331AE.2090904@imn.htwk-leipzig.de> <20080414151433.GA1271@gmx.de> Message-ID: > Does your pretty-printer round trip? Absolutely. I'd think a parser that can't parse what the pretty-printer yields means you either have a broken parser or a broken pretty-printer. :-) Except for line numbering (it inserts but doesn't read line pragmas), the AST should be preserved under f = parse . pretty. Cheers, /Niklas From claus.reinke at talk21.com Mon Apr 14 17:45:57 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Mon Apr 14 17:41:19 2008 Subject: Haskell-src-ext References: <480331AE.2090904@imn.htwk-leipzig.de><20080414151433.GA1271@gmx.de> Message-ID: <02eb01c89e78$ed5d06a0$40107ad5@cr3lt> >> Does your pretty-printer round trip? > > Absolutely. I'd think a parser that can't parse what the > pretty-printer yields means you either have a broken parser or a > broken pretty-printer. :-) > > Except for line numbering (it inserts but doesn't read line pragmas), > the AST should be preserved under f = parse . pretty. and what about (pretty . parse) = id :: String -> String ?-) preserving everything that isn't transformed at the AST level would be a necessary starting point for refactoring larger code bases. having easy access to comments and layout information is where most frontends tend to let us down. how much of the source is preserved by (pretty . parse)? layout/comments/pragmas/.. claus ps it is good to hear that src-ext is supported, follows language developments, and is separated from the other parts of your projects!-) From niklas.broberg at gmail.com Mon Apr 14 17:58:18 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Mon Apr 14 17:53:37 2008 Subject: Haskell-src-ext In-Reply-To: <02eb01c89e78$ed5d06a0$40107ad5@cr3lt> References: <480331AE.2090904@imn.htwk-leipzig.de> <20080414151433.GA1271@gmx.de> <02eb01c89e78$ed5d06a0$40107ad5@cr3lt> Message-ID: > > Except for line numbering (it inserts but doesn't read line pragmas), > > the AST should be preserved under f = parse . pretty. > > and what about (pretty . parse) = id :: String -> String ?-) Most certainly not I'm afraid. It doesn't handle pragmas at all (treats them as comments), and by default it inserts line pragmas in the output (though that can be turned off). Comments are simply discarded, and to be honest I really don't see how they could be kept in general, except in specific pre-defined places (like for Haddock). I'm sure you have ideas on that though. Layout is also not preserved exactly, and do { ... ; ... } results in the same AST as if done with layout instead of { ; }. > preserving everything that isn't transformed at the AST level > would be a necessary starting point for refactoring larger > code bases. having easy access to comments and layout > information is where most frontends tend to let us down. Indeed, and I'm afraid haskell-src-exts will join the crowd in that regard. But to be honest I'm not sure haskell-src-exts *should* do those things you ask for, since the added machinery would be rather heavy-weight for applications that just want the basic stuff, which I guess is the vast majority of applications. > ps it is good to hear that src-ext is supported, follows language > developments, and is separated from the other parts of your > projects!-) Thanks, and yes I try to keep them as separate as possible, knowing their usefulness to others. Cheers, /Niklas From ivan.salazarv at gmail.com Mon Apr 14 21:19:37 2008 From: ivan.salazarv at gmail.com (Ivan Salazar) Date: Mon Apr 14 21:15:00 2008 Subject: Sending binary files through a socket Message-ID: <90bf67330804141819o4e417b78w7ca433d04d4be0d9@mail.gmail.com> Hello, I'm having a lot of trouble sending binary files through a socket (I'm trying to program a very minimalistic webserver) but I just can't find a way to read and send binary files, even though, plain text and html documents are sent correctly. My code looks something like this: sendResource handle name = do exist <- doesFileExist name isFile <- liftM not (doesDirectoryExist name) if exist && isFile then do resource <- Data.ByteString.readFile name hPutStr handle (header ++ fileType ++ "\n") hSetBinaryMode handle True hPutStr handle resource else do hPutStr handle page404 where fileType = maybe ("text/plain") (flip const []) (lookup (takeExtension name) extensions) Thanks for your help in advance. PS: Yes, I'm terribly newbie to Haskell. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080414/fa154cc9/attachment-0001.htm From bjpop at csse.unimelb.edu.au Mon Apr 14 23:51:53 2008 From: bjpop at csse.unimelb.edu.au (Bernie Pope) Date: Mon Apr 14 23:40:32 2008 Subject: [Haskell-cafe] retrospective on 'seq' -> 'unsafeSeq' ? In-Reply-To: References: <404396ef0804140307g757887bcr8429d3b8d9cf7545@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE4D7A6E9@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <8DA45EC3-210E-4FA1-8EBF-3B8CF27C06C8@csse.unimelb.edu.au> On 14/04/2008, at 9:22 PM, pepe wrote: > Alternatively, with some effort one can create a type-agnostic > version of unsafeShow, which would print things in a more raw > format, but probably sufficient anyway. I don't think it would work > with unboxed values in general, although it can be made to work > with the standard types. Actually, Bernie Pope wrote some code for > this [1, see GHC Heap Printing library] some time ago, although > with the new primitives and changes made for :print in GHC 6.8, > this would be way easier nowadays. No need to use StablePtrs, no > need to turn on profiling, and above all, no C needed :) > And as a bonus this would work out of GHCi too. Yes, an almost-universal printer would be possible now that we have data constructor names attached to info tables. I'd sort of planned to do that, and then got side-tracked. Of course, this won't be able to print functions in any helpful way, unless we attach source code information to functions as well (which may be worth doing anyway?). One thing to watch out for is cycles in data structures. You may not want to try to detect them, but at least you should be lazy in generating the printable representation of values. And then there is the question of whether to evaluate thunks during printing. Perhaps such a printer would also be useful for the GHCi debugger in cases where it can't infer the right types? Bernie. From claus.reinke at talk21.com Tue Apr 15 04:44:08 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Tue Apr 15 04:39:37 2008 Subject: Haskell-src-ext References: <480331AE.2090904@imn.htwk-leipzig.de><20080414151433.GA1271@gmx.de><02eb01c89e78$ed5d06a0$40107ad5@cr3lt> Message-ID: <006e01c89ed4$e33955a0$673f7ad5@cr3lt> > ..Comments are simply > discarded, and to be honest I really don't see how they could be kept > in general, except in specific pre-defined places (like for Haddock). > I'm sure you have ideas on that though. Layout is also not preserved > exactly, and do { ... ; ... } results in the same AST as if done with > layout instead of { ; }. just recalling some previous discussions: a) add a whitespace&layout field to every AST construct + should work well enough for source location info and for braces yes/no flags - doesn't work so well for comments: do they belong to the next or the previous item, or are they standalone text? b) add a comment construct to the AST + avoids association issue, comments stand on their own - AST traversals have to deal with comments - AST transformations still have to decide which comments to move with which AST fragments + comments in untransformed code remain c) add source location and layout info to every AST construct, keep comments out of the AST, link source locations to comment sections + keeps AST traversals simple - AST transformations still need to decide which comments to move with which AST fragments + allows finding related comments after AST transformations (the ghc ticket suggests two lookup functions, for comments before/after a given AST fragment) + comments in untransformed code remain d) ..? i'd be interested in other alternatives so far, it seems that c is the way to go (HaRe used the Programatica's token stream as comment storage, with every identifier having source location info, and some heuristics for matching comments to AST fragments), though i'd be interested in other alternatives - keeping the parts of a split-up source representation in sync during transformation and weaving everything back together before presentation proved tedious. > Indeed, and I'm afraid haskell-src-exts will join the crowd in that > regard. But to be honest I'm not sure haskell-src-exts *should* do > those things you ask for, since the added machinery would be rather > heavy-weight for applications that just want the basic stuff, which I > guess is the vast majority of applications. would the added machinery really affect applications that don't care about comments/layout? with (c), there'd be one field not to look at and a comment store to ignore. and the bonus would be to enable a large variety of applications based on source to source transformations (refactoring, pretty printing, desugaring, layout<->braces, optimizations, ..). but perhaps that isn't the target for haskell-src-ext, and things like HaRe are currently hoping/aiming for the ghc api. >> ps it is good to hear that src-ext is supported, follows language >> developments, and is separated from the other parts of your >> projects!-) > > Thanks, and yes I try to keep them as separate as possible, > knowing their usefulness to others. keep up the good work!-) claus From mwassell at bigpond.net.au Tue Apr 15 06:27:28 2008 From: mwassell at bigpond.net.au (Mark Wassell) Date: Tue Apr 15 06:32:23 2008 Subject: Using GHC API to generate STG Message-ID: <48048310.8050708@bigpond.net.au> Hello, I am looking at how GHC generates STG and I am finding with a very simple piece of Haskell my usage of the API is not generating as much STG as I see when using -dump-stg option. In particular it isn't generating a binding for the nullary constructor LNull (I hope that's the correct terminology) The code is module Ex2 where data List a = LCon a (List a) | LNull -- deriving Show main :: List Int main = LCon 1 LNull Using the API I get [sat_s1pdQ = NO_CCS GHC.Base.I#! [1]; Ex2.main = NO_CCS Ex2.LCon! [sat_s1pdQ Ex2.LNull]; main = \u srt:SRT:[(s1pdS, Ex2.main)] [] Ex2.main;] with -ddump-stg I get a_r5Y = NO_CCS GHC.Base.I#! [1]; SRT(a_r5Y): [] Ex2.main = NO_CCS Ex2.LCon! [a_r5Y Ex2.LNull]; SRT(Ex2.main): [] Ex2.LCon = \r [eta_s67 eta_s68] Ex2.LCon [eta_s67 eta_s68]; SRT(Ex2.LCon): [] Ex2.LNull = NO_CCS Ex2.LNull! []; <---- This is missing SRT(Ex2.LNull): [] (in particular the Ex2.LNull is missing from the API STG) My thrown together API code is session <- GHC.newSession $ Just path (dflags,_) <- GHC.getSessionDynFlags session >>= Packages.initPackages GHC.setSessionDynFlags session dflags {GHC.hscTarget=GHC.HscAsm} core <- GHC.compileToCore session fp case core of Just core' -> do core'' <- corePrepPgm dflags core' [] stg <- coreToStg (PackageConfig.stringToPackageId "Ex2") core'' putStrLn $ (show $ (ppr stg) defaultDumpStyle) Nothing -> return () Mark From simonpj at microsoft.com Tue Apr 15 10:44:31 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Apr 15 10:39:48 2008 Subject: Using GHC API to generate STG In-Reply-To: <48048310.8050708@bigpond.net.au> References: <48048310.8050708@bigpond.net.au> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE4D7B204@EA-EXMSG-C334.europe.corp.microsoft.com> LNull is a constructor, so it has no definition in STG. How might it be defined? LNull = ??? Instead, the code generator takes the list of data types (TyCons) as well as the list of bindings. From the former it generates all the per-data-type goop, including info tables for its constructors. So the TyCons are what you want! Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On | Behalf Of Mark Wassell | Sent: 15 April 2008 11:27 | To: glasgow-haskell-users | Subject: Using GHC API to generate STG | | Hello, | | I am looking at how GHC generates STG and I am finding with a very | simple piece of Haskell my usage of the API is not generating as much | STG as I see when using -dump-stg option. In particular it isn't | generating a binding for the nullary constructor LNull (I hope that's | the correct terminology) | | The code is | | module Ex2 where | | data List a = LCon a (List a) | LNull -- deriving Show | | main :: List Int | main = LCon 1 LNull | | Using the API I get | | [sat_s1pdQ = NO_CCS GHC.Base.I#! [1]; | Ex2.main = NO_CCS Ex2.LCon! [sat_s1pdQ Ex2.LNull]; | main = \u srt:SRT:[(s1pdS, Ex2.main)] [] Ex2.main;] | | with -ddump-stg I get | | a_r5Y = NO_CCS GHC.Base.I#! [1]; | SRT(a_r5Y): [] | Ex2.main = NO_CCS Ex2.LCon! [a_r5Y Ex2.LNull]; | SRT(Ex2.main): [] | Ex2.LCon = \r [eta_s67 eta_s68] Ex2.LCon [eta_s67 eta_s68]; | SRT(Ex2.LCon): [] | Ex2.LNull = NO_CCS Ex2.LNull! []; <---- This is missing | SRT(Ex2.LNull): [] | | (in particular the Ex2.LNull is missing from the API STG) | | My thrown together API code is | | session <- GHC.newSession $ Just path | (dflags,_) <- GHC.getSessionDynFlags session >>= | Packages.initPackages | GHC.setSessionDynFlags session dflags {GHC.hscTarget=GHC.HscAsm} | core <- GHC.compileToCore session fp | case core of | Just core' -> do | core'' <- corePrepPgm dflags core' [] | stg <- coreToStg | (PackageConfig.stringToPackageId "Ex2") core'' | putStrLn $ (show $ (ppr stg) | defaultDumpStyle) | Nothing -> return () | | | | Mark | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From dons at galois.com Wed Apr 16 20:32:05 2008 From: dons at galois.com (Don Stewart) Date: Wed Apr 16 20:27:32 2008 Subject: gmp In-Reply-To: <5802BB37-7AF1-463F-B993-4DCEE0E74F9D@cse.unsw.edu.au> References: <478F88EA.6020206@dfki.de> <20080117170048.GD10397@scytale.galois.com> <2608b8a80801170928m67c1a774q1d9a2c947a38382c@mail.gmail.com> <20080117181457.GA10636@scytale.galois.com> <2608b8a80801171048v8f76edfh2158e6bc0d12130@mail.gmail.com> <5802BB37-7AF1-463F-B993-4DCEE0E74F9D@cse.unsw.edu.au> Message-ID: <20080417003205.GB24560@scytale.galois.com> chak: > Yitzchak Gale: > >OK for the time > >being, but it would be really, really good to be able to compile > >ghc without gmp. > > Well, just go ahead and write an alternative portable & high- > performance implementation of Integer. > > >This idea of a Mac OS X binary with statically-linked > >gmp is nice, it is really convenient. But someone needs > >to completely clarify the license issues in that case, and > >make it completely clear to all users. > > I completely agree that we need to document the situation clearly. > Otherwise, I don't really see what the fuss is about. Most GHC users > don't care whether GMP is linked into their code (as its either only > used internally or has a GPL-compatible license anyway). > > If a company wants to distribute GHC compiled binaries of non-GPL > compatible code, well, they have to compile their own version of GHC > on the Mac that links GMP dynamically, and then, use that version of > GHC to link their final product. That is going to be a trivial task > compared to developing that product in the first place. So, who > cares? I agree: there's a lot of effort here without an obvious demand. Do we know of anyone not using GHC commercially because the can't use GMP? -- Don From m at ryangunter.com Thu Apr 17 16:49:16 2008 From: m at ryangunter.com (Mike Gunter) Date: Thu Apr 17 16:47:39 2008 Subject: 6.8 unable to derive with higher-kinded variable (6.6 could) Message-ID: <87myns4377.fsf@c966553-A.attbi.com> 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> From simonpj at microsoft.com Fri Apr 18 04:17:33 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Apr 18 04:12:40 2008 Subject: 6.8 unable to derive with higher-kinded variable (6.6 could) In-Reply-To: <87myns4377.fsf@c966553-A.attbi.com> References: <87myns4377.fsf@c966553-A.attbi.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE5239F44@EA-EXMSG-C334.europe.corp.microsoft.com> | 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. | data T w = T (w Bool) deriving (Show) | data ID x = ID x deriving (Show) | main = print (T (ID False)) Look at the instance declaration you'd get instance Show (w Bool) => Show (T w) It's not clear that this leads to terminating instance resolution -- and on occasion it didn't! That's bad for a built-in mechanism like 'deriving'. So I tightened up the rules for derived instances, so the (inferred) context must be classes applied to type variable. Nevertheless, if you write the instance decl yourself, GHC lets you: data T w = T (w Bool) deriving instance Show (w Bool) => Show (T w) This uses the new 'standalone deriving' so that you can write the instance decl, including the context; by saying 'deriving' you ask GHC to fill in the methods in the standard way, which it does. Simon From cmb21 at kent.ac.uk Fri Apr 18 15:21:24 2008 From: cmb21 at kent.ac.uk (C.M.Brown) Date: Fri Apr 18 15:16:30 2008 Subject: Error Interpreting Main with API Message-ID: Hello, I am trying to use the API to interpret a Main module and get some type information from it. However, everytime I try to load a "Main.hs" module using the API I get the following error message: /usr/local/packages/ghc-6.8.2/lib/ghc-6.8.2/libHSrts.a(Main.o): In function `real_main': Main.c:(.text+0x7): undefined reference to `__stginit_ZCMain' Main.c:(.text+0x36): undefined reference to `ZCMain_main_closure' collect2: ld returned 1 exit status If I create an empty file called "Main" within the directory where "Main.hs" is located the program suceeds, I'm guessing this is because there is no linking involved. Is there an extra flag I need to pass to GHC in order to avoid this error? It works perfectly if I try it on a module that is not called Main. main = defaultErrorHandler defaultDynFlags $ do let packageConf = "/usr/local/packages/ghc-6.8.2/lib/ghc-6.8.2" session <- GHC.newSession {-JustTypecheck-} (Just (filter (/= '\n') packageConf)) dflags0 <- getSessionDynFlags session (f1,b) <- parseDynamicFlags dflags0 ["-fglasgow-exts"] setSessionDynFlags session f1{verbosity=6, hscTarget = HscInterpreted} target <- GHC.guessTarget "/home/cmb21//HaRe_Project/testing/subIntroPattern/Main.hs" Nothing hscTarget=HscNothing} GHC.addTarget session target GHC.load session GHC.LoadAllTargets usermod <- findModule session (mkModuleName "Main") Nothing setContext session [usermod] [] return session I hope somebody can share some light! Kind regards, Chris. From jimmyguang2005 at yahoo.com Fri Apr 18 16:14:27 2008 From: jimmyguang2005 at yahoo.com (Liang Guang) Date: Fri Apr 18 16:09:35 2008 Subject: help with an intriguing problem Message-ID: <692842.60242.qm@web65501.mail.ac4.yahoo.com> Hi! the ghc compiler keeps complaing " can't find module 'Char', perhaps you haven't installed the profiling libraries for package haskell98?". but actually I did install it, and i checked with ghc -v , it is right there: "wired-in package haskell98 mapped to haskell98-1.0.1.0", and Char.hi is right there in the folder haskell98-1.0.1.0.. can't figure out why it happened.. anyone please ? Thanks! Liang --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080418/4d3c5bb1/attachment.htm From daniel.is.fischer at web.de Fri Apr 18 16:35:33 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Fri Apr 18 16:28:59 2008 Subject: help with an intriguing problem In-Reply-To: <692842.60242.qm@web65501.mail.ac4.yahoo.com> References: <692842.60242.qm@web65501.mail.ac4.yahoo.com> Message-ID: <200804182235.33154.daniel.is.fischer@web.de> Am Freitag, 18. April 2008 22:14 schrieb Liang Guang: > Hi! > the ghc compiler keeps complaing " can't find module 'Char', perhaps you > haven't installed the profiling libraries for package haskell98?". but > actually I did install it, and i checked with ghc -v , it is right there: > "wired-in package haskell98 mapped to haskell98-1.0.1.0", and Char.hi is > right there in the folder haskell98-1.0.1.0.. can't figure out why it > happened.. anyone please ? > > > Thanks! > Liang > You'd want the hierarchical modules now. Replace import Char with import Data.Char and it should work. From dons at galois.com Fri Apr 18 16:49:59 2008 From: dons at galois.com (Don Stewart) Date: Fri Apr 18 16:45:05 2008 Subject: help with an intriguing problem In-Reply-To: <692842.60242.qm@web65501.mail.ac4.yahoo.com> References: <692842.60242.qm@web65501.mail.ac4.yahoo.com> Message-ID: <20080418204959.GG3462@scytale.galois.com> jimmyguang2005: > Hi! > the ghc compiler keeps complaing " can't find module 'Char', perhaps you > haven't installed the profiling libraries for package haskell98?". > but actually I did install it, and i checked with ghc -v , it is right > there: > "wired-in package haskell98 mapped to haskell98-1.0.1.0", and Char.hi is > right there in the folder haskell98-1.0.1.0.. > can't figure out why it happened.. anyone please ? > > > Thanks! > Liang > Could you just use Data.Char instead? From daniel.is.fischer at web.de Fri Apr 18 16:51:48 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Fri Apr 18 16:45:11 2008 Subject: help with an intriguing problem In-Reply-To: <692842.60242.qm@web65501.mail.ac4.yahoo.com> References: <692842.60242.qm@web65501.mail.ac4.yahoo.com> Message-ID: <200804182251.48552.daniel.is.fischer@web.de> Am Freitag, 18. April 2008 22:14 schrieb Liang Guang: > Hi! > the ghc compiler keeps complaing " can't find module 'Char', perhaps you > haven't installed the profiling libraries for package haskell98?". but > actually I did install it, and i checked with ghc -v , it is right there: > "wired-in package haskell98 mapped to haskell98-1.0.1.0", and Char.hi is > right there in the folder haskell98-1.0.1.0.. can't figure out why it > happened.. anyone please ? > > > Thanks! > Liang On second reading, ghc asks for profiling libraries for haskell98, that would mean you should look for Char.p_hi. If there are no *.p_hi files in the folder, that library wasn't built for profiling and you should do that then, runghc ./Setup.hs configure -p runghc ./Setup.hs build runghc ./Setup.hs haddock runghc ./Setup.hs install Hope this helps, Daniel From jimmyguang2005 at yahoo.com Fri Apr 18 18:20:32 2008 From: jimmyguang2005 at yahoo.com (Liang Guang) Date: Fri Apr 18 18:15:36 2008 Subject: help with an intriguing problem In-Reply-To: <200804182251.48552.daniel.is.fischer@web.de> Message-ID: <192962.23703.qm@web65513.mail.ac4.yahoo.com> Thanks! It is a very helpful hint.. I didnot find the profiling library for ghc-6.8.2, so I installed ghc661-prof, but the yum ( i use fedora 8) installed the latest ghc-6.8.2, so they end up in different directories.. now it is working. Cheers, Liang Daniel Fischer wrote: Am Freitag, 18. April 2008 22:14 schrieb Liang Guang: > Hi! > the ghc compiler keeps complaing " can't find module 'Char', perhaps you > haven't installed the profiling libraries for package haskell98?". but > actually I did install it, and i checked with ghc -v , it is right there: > "wired-in package haskell98 mapped to haskell98-1.0.1.0", and Char.hi is > right there in the folder haskell98-1.0.1.0.. can't figure out why it > happened.. anyone please ? > > > Thanks! > Liang On second reading, ghc asks for profiling libraries for haskell98, that would mean you should look for Char.p_hi. If there are no *.p_hi files in the folder, that library wasn't built for profiling and you should do that then, runghc ./Setup.hs configure -p runghc ./Setup.hs build runghc ./Setup.hs haddock runghc ./Setup.hs install Hope this helps, Daniel --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080418/ed30b0ec/attachment.htm From marlowsd at gmail.com Mon Apr 21 12:41:29 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Apr 21 12:36:30 2008 Subject: Error Interpreting Main with API In-Reply-To: References: Message-ID: <480CC3B9.4090205@gmail.com> C.M.Brown wrote: > Hello, > > I am trying to use the API to interpret a Main module and get some type > information from it. However, everytime I try to load a "Main.hs" module > using the API I get the following error message: > > /usr/local/packages/ghc-6.8.2/lib/ghc-6.8.2/libHSrts.a(Main.o): In > function `real_main': > Main.c:(.text+0x7): undefined reference to `__stginit_ZCMain' > Main.c:(.text+0x36): undefined reference to `ZCMain_main_closure' > collect2: ld returned 1 exit status > > If I create an empty file called "Main" within the directory where > "Main.hs" is located the program suceeds, I'm guessing this is because > there is no linking involved. Is there an extra flag I need to pass to GHC > in order to avoid this error? It works perfectly if I try it on a > module that is not called Main. The GHC API is behaving just like --make: it links the program if you have a Main module. To ask it not to link, you want to do the same as '--make -c', which in the GHC API means setting the ghcLink field of DynFlags to NoLink. Cheers, Simon From cmb21 at kent.ac.uk Mon Apr 21 13:56:08 2008 From: cmb21 at kent.ac.uk (C.M.Brown) Date: Mon Apr 21 13:51:03 2008 Subject: Error Interpreting Main with API In-Reply-To: <480CC3B9.4090205@gmail.com> References: <480CC3B9.4090205@gmail.com> Message-ID: Simon, > The GHC API is behaving just like --make: it links the program if you > have a Main module. To ask it not to link, you want to do the same as > '--make -c', which in the GHC API means setting the ghcLink field of > DynFlags to NoLink. Thanks, this has solved the problem I was having. I wonder whether it would be a good idea to amend the Wiki page to relect this? I think it is reasonable to assume that other users are going to want to use the API against Main modules and it's possibly not too clear at the moment how to do this. Regards, Chris. From simonpj at microsoft.com Tue Apr 22 03:03:57 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Apr 22 02:58:51 2008 Subject: Error Interpreting Main with API In-Reply-To: References: <480CC3B9.4090205@gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE53041B5@EA-EXMSG-C334.europe.corp.microsoft.com> | > The GHC API is behaving just like --make: it links the program if you | > have a Main module. To ask it not to link, you want to do the same as | > '--make -c', which in the GHC API means setting the ghcLink field of | > DynFlags to NoLink. | | Thanks, this has solved the problem I was having. I wonder whether it | would be a good idea to amend the Wiki page to relect this? I think it is | reasonable to assume that other users are going to want to use the API | against Main modules and it's possibly not too clear at the moment how to | do this. Yes I do, please! Would you feel up to doing so? I'm sure Simon'd check your text for veracity! thanks Simon From cmb21 at kent.ac.uk Tue Apr 22 03:52:49 2008 From: cmb21 at kent.ac.uk (C.M.Brown) Date: Tue Apr 22 03:49:28 2008 Subject: Error Interpreting Main with API In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE53041B5@EA-EXMSG-C334.europe.corp.microsoft.com> References: <480CC3B9.4090205@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE53041B5@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: Hi Simon, > Yes I do, please! Would you feel up to doing so? I'm sure Simon'd check your text for veracity! I have modified the wiki, and added a new section under "initialisation": http://www.haskell.org/haskellwiki/GHC/As_a_library Would it also be appropriate to modify that wiki page to reflect some of the changes between 6.6.1 and 6.8.2? I don't mind doing this at some point today or tomorrow... Regards, Chris. From simonpj at microsoft.com Tue Apr 22 04:05:42 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Apr 22 04:00:37 2008 Subject: Error Interpreting Main with API In-Reply-To: References: <480CC3B9.4090205@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE53041B5@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE5304260@EA-EXMSG-C334.europe.corp.microsoft.com> | Would it also be appropriate to modify that wiki page to reflect some of | the changes between 6.6.1 and 6.8.2? I don't mind doing this at some point | today or tomorrow... Yes please, that would be vv helpful. S From mechvel at botik.ru Tue Apr 22 08:32:44 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Tue Apr 22 08:29:12 2008 Subject: instance export decls Message-ID: <20080422123244.GA18149@scico.botik.ru> Dear GHC developers, people, Do you agree that there exists such a problem for a programmer as recalling exported instances? Have Haskell and/or GHC some constructs and tools to help the programmer to recall the exported instances for a module? Could GHC support the instance export messages for each module? In Haskell-98, the exported instances cannot be named explicitly in the export list. Right? But for easier understanding of a program, it is desirable to allow to name (in a short form) instances in the export list. For this reason, I add comments, and write the export like this: module Poly (WithHead(..), WithTail(..), -- classes Mon(..), Polynomial(..), lc, polMons -- , instances -- for Mon: WithHead, List; -- for Polynomial: WithHead, Cast Polynomial Mon ) The comment of kind "-- , instances ..." helps to recall which instances are exported, without inspecting all the (lengthy) module source. But when the programmer changes the source, one often forgets to add/remove the needed comments about instances. I often forget them (maybe, lazy to recall) when I move pieces of code between modules. So, I suggest the following feature for GHC. 1. To allow the export declarations of kind instance {} (maybe to suggest this for Haskell ?) 2. If the module under compilation has the word `instance' in its export list, then ghc finds the difference set diff for the exported instance kinds eKinds and the instance kinds nKinds named in the export list. If not $ null diff, it issues the message: "Warning: the exported instance kinds and the instance kinds named in the export differ in the following items: ...". Seeing such a message, the user corrects the export list in the source according to diff. For the export list and for their messages, it is probably better to use a short denotation: the instance kind rather than full instance declaration. In the instance kind, the part of "(...) =>" is skipped. What people think of this suggestion? Thank you in advance for your notes and help, ----------------- Serge Mechveliani mechvel@botik.ru From cmb21 at kent.ac.uk Wed Apr 23 06:41:13 2008 From: cmb21 at kent.ac.uk (C.M.Brown) Date: Wed Apr 23 06:36:03 2008 Subject: runstmt within API Message-ID: Hello, I want to use the ghc evaluator on the fly for some refactorings within HaRe. However, I notice that runstmt ::Session -> String -> IO RunResult. Is there anyway I can grab the result of the evaluated expression as a String (rather than it being outputted to the terminal)? It seems RunResult is defined: data RunResult = RunOk [Name] -- names bound by the expression | RunFailed | RunException GHC.IOBase.Exception If I can't grab its result, is there a way to query the [Name] to get a list of bindings in String format? Preferably something like "it = expression". Kind regards, Chris. From mnislaih at gmail.com Wed Apr 23 09:40:26 2008 From: mnislaih at gmail.com (pepe) Date: Wed Apr 23 09:35:24 2008 Subject: runstmt within API In-Reply-To: References: Message-ID: <375D0250-EADA-433E-9D39-283531F6F544@gmail.com> Chris, On 23/04/2008, at 12:41, C.M.Brown wrote: > Hello, > > I want to use the ghc evaluator on the fly for some refactorings > within > HaRe. However, I notice that runstmt ::Session -> String -> IO > RunResult. > > Is there anyway I can grab the result of the evaluated expression as a > String (rather than it being outputted to the terminal)? > The result of an expression is not a String, but an arbitrary value of some type. If there is a Show instance around for it, you can use that to get a String. One way to do that (untested): > nameToString :: Session -> Name -> IO String > nameToString cms@(Session ref) name = do > dflags <- GHC.getSessionDynFlags cms > do > let noop_log _ _ _ _ = return () > expr = "show " ++ showSDoc (ppr name) > GHC.setSessionDynFlags cms dflags{log_action=noop_log} > mb_txt <- GHC.compileExpr cms expr > case mb_txt of > Just txt_ | txt <- unsafeCoerce# txt_, not (null txt) > -> return $ Just txt > _ -> return Nothing > `finally` > GHC.setSessionDynFlags cms dflags The expression "show " is evaluated via compileExpr. CompileExpr will return a HValue that you need to cast to a String. Or one can use dynCompileExpr instead. The code takes care of temporarily replacing log_action to capture the type error arising in the case there is not a Show instance available. A way to tell runStmt that you don't want the result outputted to stdout is to enable the flag -no-print-bind-result. It would be nice to wrap this code in a more friendly API. Hopefully the SoC project will take care of that ! Cheers pepe From cmb21 at kent.ac.uk Wed Apr 23 10:31:21 2008 From: cmb21 at kent.ac.uk (C.M.Brown) Date: Wed Apr 23 10:26:11 2008 Subject: runstmt within API In-Reply-To: <375D0250-EADA-433E-9D39-283531F6F544@gmail.com> References: <375D0250-EADA-433E-9D39-283531F6F544@gmail.com> Message-ID: Hi Pepe, > The result of an expression is not a String, but an arbitrary value of > some type. Yes, sorry I forgot to mention that I will also be evaluating expressions of type Bool in this context. > One way to do that (untested): > ... Thanks for that. I had to modify it a bit to typecheck and compile, but it seems to work remarkably well! > stdout is to enable the flag -no-print-bind-result > > It would be nice to wrap this code in a more friendly API. Hopefully > the SoC project will take care of that ! Yes, indeed something like runStmtToString :: Session -> String -> IO (Maybe Sting) or something. Thanks, Chris. From simonpj at microsoft.com Thu Apr 24 03:52:26 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Apr 24 03:47:17 2008 Subject: [Haskell] How to define tail function for Even/Odd GADT lists? In-Reply-To: <480F9D02.3090406@gmail.com> References: <480F9D02.3090406@gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE53918AF@EA-EXMSG-C334.europe.corp.microsoft.com> [Redirecting to ghc-users] You're right that tailList "ought" to work. There are at least two reasons that it doesn't. First, GHC does not have a robust implementation of GADTs + functional dependencies. The interaction is very tricky. So I tried re-expressing it using type families, thus: data Even; data Odd type family Flip a :: * type instance Flip Even = Odd type instance Flip Odd = Even data List a b where Nil :: List a Even Cons :: a -> List a b -> List a (Flip b) tailList :: List a b -> List a (Flip b) tailList (Cons _ xs) = xs (I find the program quite a bit easier to read in this form.) Now I get the error (from the HEAD) Occurs check: cannot construct the infinite type: b = Flip (Flip b) In the pattern: Cons _ xs In the definition of `tailList': tailList (Cons _ xs) = xs There's a bug here -- reporting an occurs check is premature. But there is also a real problem: if you look at the type constraints arising from tailList you'll see that you get c ~ Flip b b ~ Flip c where c is the existential you get from the GADT match. Now, *we* know that b = Flip (Flip b) is always tru, but GHC doesn't. After all, you could add new type instances type instance Flip Int = Bool type instance Flip Bool = Char and then the equation wouldn't hold. The best we can hope for is to get tailList :: (b ~ Flip (Flip b)) => List a b -> List a (Flip b) although this too is rejected at the moment because of the above bug. What we really want is a *closed* type family, like this type family Flip a where Flip Even = Odd Flip Odd = Even (preferably supported by kinds) and even *then* it's not clear whether it's reasonable to expect the compiler to solve the above problem by trying all possibilities. This relates to http://hackage.haskell.org/trac/ghc/ticket/2101 That is probably more than you wanted to know. Since there's a bug here, I'll make a ticket. Simon | -----Original Message----- | From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Ahn, Ki Yung | Sent: 23 April 2008 21:33 | To: Haskell@haskell.org | Subject: [Haskell] How to define tail function for Even/Odd GADT lists? | | Using GADTs and functional dependencies, we can define GADT lists | that statically distinguishes even length lists from odd length lists. | | > data Even | > data Odd | > | > class Flip b c | b -> c, c -> b where | > | > instance Flip Even Odd where | > instance Flip Odd Even where | > | > data List a b where | > Nil :: List a Even | > Cons :: Flip b c => a -> List a b -> List a c | | For example, | | Nil :: forall a. List a Even | Cons True Nil :: List Bool Odd | Cons False (Cons True Nil) :: List Bool Even | | | We were able to define the function that returns the head. | | > headList :: List a b -> a | > headList (Cons x _) = x | | However, we were not able to write a function that returns the tail. | | > tailList :: Flip b c => List a b -> List a c | > tailList (Cons _ xs) = xs | | Is there a way to define the tailList function within the current | GHC type system implementation (maybe using some other language | extensions), or do we need to improve the type system regarding | GADTs and functional dependencies? | | $ ghci -fglasgow-exts EOlist.hs | GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help | Loading package base ... linking ... done. | [1 of 1] Compiling Main ( EOlist.lhs, interpreted ) | | EOlist.lhs:30:25: | Couldn't match expected type `c' against inferred type `b1' | `c' is a rigid type variable bound by | the type signature for `tailList' at EOlist.lhs:29:21 | `b1' is a rigid type variable bound by | the constructor `Cons' at EOlist.lhs:30:12 | Expected type: List a c | Inferred type: List a b1 | In the expression: xs | In the definition of `tailList': tailList (Cons _ xs) = xs | Failed, modules loaded: none. | Prelude> | | Note: You can save this message content as EOList.lhs and load the | script with ghci to observe the type error message above. | _______________________________________________ | Haskell mailing list | Haskell@haskell.org | http://www.haskell.org/mailman/listinfo/haskell From bjorn at bringert.net Thu Apr 24 06:41:38 2008 From: bjorn at bringert.net (Bjorn Bringert) Date: Thu Apr 24 06:36:24 2008 Subject: ANN: ghc 6.8.2 from MacPorts In-Reply-To: <086856DC-BB3C-40B5-BC79-77F35A009179@cs.nott.ac.uk> References: <50CC9CBD-56CD-463B-A5A1-154503419C21@comcast.net> <086856DC-BB3C-40B5-BC79-77F35A009179@cs.nott.ac.uk> Message-ID: On Thu, Mar 6, 2008 at 7:57 PM, Wouter Swierstra wrote: > Hi Greg, > > Thanks again for maintaining ghc in macports! > > I tried installing ghc through macports. Unfortunately, the build failed > with the following error message below. I'd be happy to send you a complete > log, if you think it would help. Many thanks, > > Wouter > > > > main/ParsePkgConf.hs:296:35: Not in scope: `extraLibraries' > > main/ParsePkgConf.hs:297:35: Not in scope: `extraGHCiLibraries' > > main/ParsePkgConf.hs:298:35: Not in scope: `includeDirs' > > main/ParsePkgConf.hs:299:35: Not in scope: `includes' > > main/ParsePkgConf.hs:300:35: Not in scope: `hugsOptions' > > main/ParsePkgConf.hs:301:35: Not in scope: `ccOptions' > > main/ParsePkgConf.hs:302:35: Not in scope: `ldOptions' > > main/ParsePkgConf.hs:303:35: Not in scope: `frameworkDirs' > > main/ParsePkgConf.hs:304:35: Not in scope: `frameworks' > > main/ParsePkgConf.hs:305:35: Not in scope: `haddockInterfaces' > > main/ParsePkgConf.hs:306:35: Not in scope: `haddockHTMLs' > > main/ParsePkgConf.hs:307:34: Not in scope: `depends' > > main/ParsePkgConf.hs:320:43: Not in scope: `depends' > < samples), 18M in use, 0.00 INIT (0.00 elapsed), 0.09 MUT (0.13 elapsed), > 0.06 GC (0.07 elapsed) :ghc>> > make[2]: *** [stage2/main/ParsePkgConf.o] Error 1 > make[1]: *** [stage2] Error 2 > make: *** [bootstrap2] Error 2 > > Warning: the following items did not execute (for ghc): > org.macports.activate org.macports.build org.macports.destroot > org.macports.install > Error: Status 1 encountered during processing. I got the same error when trying to install ghc 6.8.2 from MacPorts on OS X 10.4.11/Intel. It seems like the stage2 build is picking up the wrong version of Cabal from my user packages left over from a previous GHC 6.8.2 installation. Deleting ~/.ghc fixes the problem. Maybe the GHC build should be changed to make sure that it doesn't use user packages? /Bj?rn From gwright at comcast.net Thu Apr 24 09:25:26 2008 From: gwright at comcast.net (Gregory Wright) Date: Thu Apr 24 09:20:24 2008 Subject: ANN: ghc 6.8.2 from MacPorts In-Reply-To: References: <50CC9CBD-56CD-463B-A5A1-154503419C21@comcast.net> <086856DC-BB3C-40B5-BC79-77F35A009179@cs.nott.ac.uk> Message-ID: Hi Bj?rn, On Apr 24, 2008, at 6:41 AM, Bjorn Bringert wrote: > On Thu, Mar 6, 2008 at 7:57 PM, Wouter Swierstra > wrote: >> Hi Greg, >> >> Thanks again for maintaining ghc in macports! >> >> I tried installing ghc through macports. Unfortunately, the build >> failed >> with the following error message below. I'd be happy to send you a >> complete >> log, if you think it would help. Many thanks, >> >> Wouter >> >> >> >> main/ParsePkgConf.hs:296:35: Not in scope: `extraLibraries' >> >> main/ParsePkgConf.hs:297:35: Not in scope: `extraGHCiLibraries' >> >> main/ParsePkgConf.hs:298:35: Not in scope: `includeDirs' >> >> main/ParsePkgConf.hs:299:35: Not in scope: `includes' >> >> main/ParsePkgConf.hs:300:35: Not in scope: `hugsOptions' >> >> main/ParsePkgConf.hs:301:35: Not in scope: `ccOptions' >> >> main/ParsePkgConf.hs:302:35: Not in scope: `ldOptions' >> >> main/ParsePkgConf.hs:303:35: Not in scope: `frameworkDirs' >> >> main/ParsePkgConf.hs:304:35: Not in scope: `frameworks' >> >> main/ParsePkgConf.hs:305:35: Not in scope: `haddockInterfaces' >> >> main/ParsePkgConf.hs:306:35: Not in scope: `haddockHTMLs' >> >> main/ParsePkgConf.hs:307:34: Not in scope: `depends' >> >> main/ParsePkgConf.hs:320:43: Not in scope: `depends' >> <> residency (3 >> samples), 18M in use, 0.00 INIT (0.00 elapsed), 0.09 MUT (0.13 >> elapsed), >> 0.06 GC (0.07 elapsed) :ghc>> >> make[2]: *** [stage2/main/ParsePkgConf.o] Error 1 >> make[1]: *** [stage2] Error 2 >> make: *** [bootstrap2] Error 2 >> >> Warning: the following items did not execute (for ghc): >> org.macports.activate org.macports.build org.macports.destroot >> org.macports.install >> Error: Status 1 encountered during processing. > > I got the same error when trying to install ghc 6.8.2 from MacPorts on > OS X 10.4.11/Intel. It seems like the stage2 build is picking up the > wrong version of Cabal from my user packages left over from a previous > GHC 6.8.2 installation. Deleting ~/.ghc fixes the problem. Maybe the > GHC build should be changed to make sure that it doesn't use user > packages? > > Bj?rn I'll see if I can come up with a patch to the build system that avoids this. BTW, what version the Cabal in your user packages? I was never able to reproduce this myself --- I probably didn't stumble upon the right (i.e., wrong) combination of cabals. bw, Greg From bjorn at bringert.net Thu Apr 24 11:36:00 2008 From: bjorn at bringert.net (Bjorn Bringert) Date: Thu Apr 24 11:30:46 2008 Subject: ANN: ghc 6.8.2 from MacPorts In-Reply-To: References: <50CC9CBD-56CD-463B-A5A1-154503419C21@comcast.net> <086856DC-BB3C-40B5-BC79-77F35A009179@cs.nott.ac.uk> Message-ID: On Thu, Apr 24, 2008 at 3:25 PM, Gregory Wright wrote: > On Apr 24, 2008, at 6:41 AM, Bjorn Bringert wrote: > > On Thu, Mar 6, 2008 at 7:57 PM, Wouter Swierstra > wrote: > > > > > Hi Greg, > > > > > > Thanks again for maintaining ghc in macports! > > > > > > I tried installing ghc through macports. Unfortunately, the build failed > > > with the following error message below. I'd be happy to send you a > complete > > > log, if you think it would help. Many thanks, > > > > > > Wouter > > > > > > > > > > > > main/ParsePkgConf.hs:296:35: Not in scope: `extraLibraries' > > > > > > main/ParsePkgConf.hs:297:35: Not in scope: `extraGHCiLibraries' > > > > > > main/ParsePkgConf.hs:298:35: Not in scope: `includeDirs' > > > > > > main/ParsePkgConf.hs:299:35: Not in scope: `includes' > > > > > > main/ParsePkgConf.hs:300:35: Not in scope: `hugsOptions' > > > > > > main/ParsePkgConf.hs:301:35: Not in scope: `ccOptions' > > > > > > main/ParsePkgConf.hs:302:35: Not in scope: `ldOptions' > > > > > > main/ParsePkgConf.hs:303:35: Not in scope: `frameworkDirs' > > > > > > main/ParsePkgConf.hs:304:35: Not in scope: `frameworks' > > > > > > main/ParsePkgConf.hs:305:35: Not in scope: `haddockInterfaces' > > > > > > main/ParsePkgConf.hs:306:35: Not in scope: `haddockHTMLs' > > > > > > main/ParsePkgConf.hs:307:34: Not in scope: `depends' > > > > > > main/ParsePkgConf.hs:320:43: Not in scope: `depends' > > > < > > samples), 18M in use, 0.00 INIT (0.00 elapsed), 0.09 MUT (0.13 elapsed), > > > 0.06 GC (0.07 elapsed) :ghc>> > > > make[2]: *** [stage2/main/ParsePkgConf.o] Error 1 > > > make[1]: *** [stage2] Error 2 > > > make: *** [bootstrap2] Error 2 > > > > > > Warning: the following items did not execute (for ghc): > > > org.macports.activate org.macports.build org.macports.destroot > > > org.macports.install > > > Error: Status 1 encountered during processing. > > > > > > > I got the same error when trying to install ghc 6.8.2 from MacPorts on > > OS X 10.4.11/Intel. It seems like the stage2 build is picking up the > > wrong version of Cabal from my user packages left over from a previous > > GHC 6.8.2 installation. Deleting ~/.ghc fixes the problem. Maybe the > > GHC build should be changed to make sure that it doesn't use user > > packages? > > > > Bj?rn > > > > I'll see if I can come up with a patch to the build system that avoids > this. > BTW, what version the Cabal in your user packages? I was never able to > reproduce this myself --- I probably didn't stumble upon the right (i.e., wrong) > combination of cabals. Hmm, unfortunately I have deleted ~/.ghc but it may have been Cabal-1.3.7. /Bjorn From Geraint.Jones at wolfson.ox.ac.uk Fri Apr 25 12:05:27 2008 From: Geraint.Jones at wolfson.ox.ac.uk (Geraint Jones) Date: Fri Apr 25 12:00:10 2008 Subject: strictness of interpreted haskell implementations Message-ID: <200804251605.m3PG5ROF022372@clpc214.comlab.ox.ac.uk> Are there well-known differences in the implementations of Haskell in ghci and hugs? I've got some moderately intricate code (simulations of pipelined processors) that behave differently - apparently because ghci Haskell is stricter than hugs Haskell, and I cannot find any obviously relevant claims about strictness in the documentation. From dons at galois.com Fri Apr 25 12:08:49 2008 From: dons at galois.com (Don Stewart) Date: Fri Apr 25 12:03:38 2008 Subject: strictness of interpreted haskell implementations In-Reply-To: <200804251605.m3PG5ROF022372@clpc214.comlab.ox.ac.uk> References: <200804251605.m3PG5ROF022372@clpc214.comlab.ox.ac.uk> Message-ID: <20080425160849.GA9345@scytale.galois.com> Geraint.Jones: > Are there well-known differences in the implementations of Haskell in > ghci and hugs? I've got some moderately intricate code (simulations > of pipelined processors) that behave differently - apparently because > ghci Haskell is stricter than hugs Haskell, and I cannot find any > obviously relevant claims about strictness in the documentation. Hugs does no optimisations, while GHC does a truckload, including strictness analysis. Some of these optimisations prevent space leaks. You might want to also check with ghc -Onot , ghc -O2 (esp. if performance matters). -- Don From duncan.coutts at worc.ox.ac.uk Fri Apr 25 15:17:53 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Apr 25 15:12:24 2008 Subject: strictness of interpreted haskell implementations In-Reply-To: <20080425160849.GA9345@scytale.galois.com> References: <200804251605.m3PG5ROF022372@clpc214.comlab.ox.ac.uk> <20080425160849.GA9345@scytale.galois.com> Message-ID: <1209151073.30059.22.camel@localhost> On Fri, 2008-04-25 at 09:08 -0700, Don Stewart wrote: > Geraint.Jones: > > Are there well-known differences in the implementations of Haskell in > > ghci and hugs? I've got some moderately intricate code (simulations > > of pipelined processors) that behave differently - apparently because > > ghci Haskell is stricter than hugs Haskell, and I cannot find any > > obviously relevant claims about strictness in the documentation. I think they should give the same answer. It sounds like a bug in one implementation or the other. > Hugs does no optimisations, while GHC does a truckload, including > strictness analysis. Some of these optimisations prevent space leaks. Though none should change the static semantics. Post the code. Even if you don't have time to track down the difference, someone might. Duncan From josef.svenningsson at gmail.com Fri Apr 25 17:57:10 2008 From: josef.svenningsson at gmail.com (Josef Svenningsson) Date: Fri Apr 25 17:51:52 2008 Subject: strictness of interpreted haskell implementations In-Reply-To: <1209151073.30059.22.camel@localhost> References: <200804251605.m3PG5ROF022372@clpc214.comlab.ox.ac.uk> <20080425160849.GA9345@scytale.galois.com> <1209151073.30059.22.camel@localhost> Message-ID: <8dde104f0804251457m5a9b135bw289d3a6e08d77e64@mail.gmail.com> On Fri, Apr 25, 2008 at 9:17 PM, Duncan Coutts wrote: > > On Fri, 2008-04-25 at 09:08 -0700, Don Stewart wrote: > > Geraint.Jones: > > > Are there well-known differences in the implementations of Haskell in > > > ghci and hugs? I've got some moderately intricate code (simulations > > > of pipelined processors) that behave differently - apparently because > > > ghci Haskell is stricter than hugs Haskell, and I cannot find any > > > obviously relevant claims about strictness in the documentation. > > I think they should give the same answer. It sounds like a bug in one > implementation or the other. > I suspect this might be a library thing. If ghc and hugs uses different versions of the library and some function had its strictness property changed then that might account for the discrepancy. > > Hugs does no optimisations, while GHC does a truckload, including > > strictness analysis. Some of these optimisations prevent space leaks. > > Though none should change the static semantics. > That was my initial reaction as well, but then I recalled that some of ghc's optimizations actually changes the strictness behavior. The foldr/build transformation for instance can actually change the strictness of a function such that you can actually observe it. So we can't rule out that ghc is doing something it shouldn't be doing. > Post the code. Even if you don't have time to track down the difference, > someone might. > Yep, without the code we're just fumbling in the dark. Cheers, Josef From igloo at earth.li Sat Apr 26 16:58:02 2008 From: igloo at earth.li (Ian Lynagh) Date: Sat Apr 26 16:52:50 2008 Subject: ANN: ghc 6.8.2 from MacPorts In-Reply-To: References: <50CC9CBD-56CD-463B-A5A1-154503419C21@comcast.net> <086856DC-BB3C-40B5-BC79-77F35A009179@cs.nott.ac.uk> Message-ID: <20080426205802.GA17765@matrix.chaos.earth.li> On Thu, Apr 24, 2008 at 09:25:26AM -0400, Gregory Wright wrote: > > I'll see if I can come up with a patch to the build system that avoids > this. I think that this was actually done a while ago: [pass -no-user-package-conf to ghc-inplace Simon Marlow **20080104162840] { Thanks Ian From marlowsd at gmail.com Mon Apr 28 15:15:52 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Apr 28 15:10:27 2008 Subject: Error Interpreting Main with API In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE5304260@EA-EXMSG-C334.europe.corp.microsoft.com> References: <480CC3B9.4090205@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE53041B5@EA-EXMSG-C334.europe.corp.microsoft.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE5304260@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <48162268.2030900@gmail.com> Simon Peyton-Jones wrote: > | Would it also be appropriate to modify that wiki page to reflect some of > | the changes between 6.6.1 and 6.8.2? I don't mind doing this at some point > | today or tomorrow... > > Yes please, that would be vv helpful. Right; the page currently has a mixture of 6.6 and 6.8-style examples of the API. In particular, the GhcMode thing is completely gone in 6.8, and hence newSession only takes one argument. I suspect many of the examples don't work because they're using a mixture of the two APIs. Anyway, Thomas Schilling's summer of code project should address all this: he'll be writing some proper documentation for the API. Cheers, Simon From ndmitchell at gmail.com Mon Apr 28 16:30:08 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Apr 28 16:24:39 2008 Subject: Optimisation of unpackCString# Message-ID: <404396ef0804281330y7a2429eap8d25bc3c38469f10@mail.gmail.com> Hi (All these results are from GHC 6.9.20071226, but suspect they hold for 6.9.* and 6.8) The following code: test = head "neil" Produces (with -O2): Text.HTML.TagSoup.Development.Sample.test = case GHC.Base.unpackCString# "neil" of wild_aaU { [] -> GHC.List.badHead @ GHC.Base.Char; : x_aaY ds1_aaZ -> x_aaY } However: test = head ['n','e','i','l'] Produces: Text.HTML.TagSoup.Development.Sample.test = GHC.Base.C# 'n' The packing of the string has damaged the optimisation. Is there anyway to mitigate this? I ideally want to do this in RULES to derive an efficient parser from a set of parser combinators, and the unpackCString# really gets in the way of future optimisations. I could imagine adding two rules to the simplifier: case unpackCString# "" of ==> case [] of case unpackCString# "xyz" of ==> case (C# 'x': unpackCString# "yz") of Then the simplifier could recover the optimised version. Thanks Neil From dons at galois.com Mon Apr 28 16:54:41 2008 From: dons at galois.com (Don Stewart) Date: Mon Apr 28 16:49:25 2008 Subject: Optimisation of unpackCString# In-Reply-To: <404396ef0804281330y7a2429eap8d25bc3c38469f10@mail.gmail.com> References: <404396ef0804281330y7a2429eap8d25bc3c38469f10@mail.gmail.com> Message-ID: <20080428205441.GC19390@scytale.galois.com> ndmitchell: > Hi > > (All these results are from GHC 6.9.20071226, but suspect they hold > for 6.9.* and 6.8) > > The following code: > > test = head "neil" > > Produces (with -O2): > > Text.HTML.TagSoup.Development.Sample.test = > case GHC.Base.unpackCString# "neil" of wild_aaU { > [] -> GHC.List.badHead @ GHC.Base.Char; : x_aaY ds1_aaZ -> x_aaY > } > > However: > > test = head ['n','e','i','l'] > > Produces: > > Text.HTML.TagSoup.Development.Sample.test = GHC.Base.C# 'n' > > The packing of the string has damaged the optimisation. Is there > anyway to mitigate this? I ideally want to do this in RULES to derive > an efficient parser from a set of parser combinators, and the > unpackCString# really gets in the way of future optimisations. > > I could imagine adding two rules to the simplifier: > > case unpackCString# "" of ==> case [] of > case unpackCString# "xyz" of ==> case (C# 'x': unpackCString# "yz") of > > Then the simplifier could recover the optimised version. The first case makes sense, and is just a RULE. Though it seems GHC already does this? g = head "" goes to: M.g = badHead @ Char without prompting. Now, ByteString uses a rule relating to unpackCString#: {-# RULES "ByteString pack/packAddress" forall s . pack (unpackCString# s) = inlinePerformIO (B.unsafePackAddress s) #-} So I wondered if I could write a rule for head/unpackCString {-# OPTIONS -fglasgow-exts #-} module M where import GHC.Base -- ^ enable rewrite rules {-# RULES "head/string literal" forall s . head (unpackCString# s) = case s of ""# -> head [] _ -> C# (indexCharArray# (unsafeCoerce# s) 0#) #-} f = head "neil" Urgh. not what we want though. GHC won't index the string at compile time, and I can't write a RULE for it. I was surprised to note we can actually match on unboxed string literals in rules, but then the question is how to recover the nice list structure again. As the string has already been packed for us, this seems a bit hard. Otherwise a unpack (pack s) rule could be used. Perhaps you can newtype Char and use string overloading to work around the packing issue? -- Don From dons at galois.com Mon Apr 28 17:00:38 2008 From: dons at galois.com (Don Stewart) Date: Mon Apr 28 16:55:15 2008 Subject: Optimisation of unpackCString# In-Reply-To: <20080428205441.GC19390@scytale.galois.com> References: <404396ef0804281330y7a2429eap8d25bc3c38469f10@mail.gmail.com> <20080428205441.GC19390@scytale.galois.com> Message-ID: <20080428210038.GD19390@scytale.galois.com> dons: > ndmitchell: > > Hi > > > > (All these results are from GHC 6.9.20071226, but suspect they hold > > for 6.9.* and 6.8) > > > > The following code: > > > > test = head "neil" > > > > Produces (with -O2): > > > > Text.HTML.TagSoup.Development.Sample.test = > > case GHC.Base.unpackCString# "neil" of wild_aaU { > > [] -> GHC.List.badHead @ GHC.Base.Char; : x_aaY ds1_aaZ -> x_aaY > > } > > > > However: > > > > test = head ['n','e','i','l'] > > > > Produces: > > > > Text.HTML.TagSoup.Development.Sample.test = GHC.Base.C# 'n' > > > > The packing of the string has damaged the optimisation. Is there > > anyway to mitigate this? I ideally want to do this in RULES to derive > > an efficient parser from a set of parser combinators, and the > > unpackCString# really gets in the way of future optimisations. > > > > I could imagine adding two rules to the simplifier: > > > > case unpackCString# "" of ==> case [] of > > case unpackCString# "xyz" of ==> case (C# 'x': unpackCString# "yz") of > > > > Then the simplifier could recover the optimised version. > > The first case makes sense, and is just a RULE. Though it seems GHC already > does this? > > g = head "" > > goes to: > > M.g = badHead @ Char > > without prompting. > > Now, ByteString uses a rule relating to unpackCString#: > > {-# RULES > "ByteString pack/packAddress" forall s . > pack (unpackCString# s) = inlinePerformIO (B.unsafePackAddress s) > #-} > > So I wondered if I could write a rule for head/unpackCString > > {-# OPTIONS -fglasgow-exts #-} > > module M where > > import GHC.Base > > -- ^ enable rewrite rules > {-# RULES > "head/string literal" forall s . > head (unpackCString# s) = case s of > ""# -> head [] > _ -> C# (indexCharArray# (unsafeCoerce# s) 0#) > #-} > > f = head "neil" > > Urgh. not what we want though. GHC won't index the string at compile time, > and I can't write a RULE for it. > > I was surprised to note we can actually match on unboxed string literals in > rules, but then the question is how to recover the nice list structure again. > > As the string has already been packed for us, this seems a bit hard. > Otherwise a unpack (pack s) rule could be used. > > Perhaps you can newtype Char and use string overloading to work around the > packing issue? This goes back to an old gripe of mine actually -- we can't get at the length of a C string literal at compile time either, which would be super useful in rules. If we had some light primitives for this, that GHC new about (head#, length#), that accessed the internal data about what strings are up to, that could be useful. -- Don From ndmitchell at gmail.com Mon Apr 28 17:02:45 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Apr 28 16:57:17 2008 Subject: Optimisation of unpackCString# In-Reply-To: <20080428205441.GC19390@scytale.galois.com> References: <404396ef0804281330y7a2429eap8d25bc3c38469f10@mail.gmail.com> <20080428205441.GC19390@scytale.galois.com> Message-ID: <404396ef0804281402u6c4bcdb7med13525c23e879d7@mail.gmail.com> Hi > The first case makes sense, and is just a RULE. Though it seems GHC already > does this? > > g = head "" > > goes to: > > M.g = badHead @ Char > > without prompting. Nope, as far as I can tell "" gets translated to [], not unpackCString# "" - hence the unpack never gets in the way. If you had the second rule, you'd soon want the first. > So I wondered if I could write a rule for head/unpackCString > > Urgh. not what we want though. GHC won't index the string at compile time, > and I can't write a RULE for it. Yeah, I tried that too... > Perhaps you can newtype Char and use string overloading to work around the > packing issue? That would work on GHC, but not on Hugs. Thanks Neil From dons at galois.com Mon Apr 28 17:04:14 2008 From: dons at galois.com (Don Stewart) Date: Mon Apr 28 16:58:52 2008 Subject: Optimisation of unpackCString# In-Reply-To: <404396ef0804281402u6c4bcdb7med13525c23e879d7@mail.gmail.com> References: <404396ef0804281330y7a2429eap8d25bc3c38469f10@mail.gmail.com> <20080428205441.GC19390@scytale.galois.com> <404396ef0804281402u6c4bcdb7med13525c23e879d7@mail.gmail.com> Message-ID: <20080428210414.GF19390@scytale.galois.com> ndmitchell: > Hi > > > The first case makes sense, and is just a RULE. Though it seems GHC already > > does this? > > > > g = head "" > > > > goes to: > > > > M.g = badHead @ Char > > > > without prompting. > > Nope, as far as I can tell "" gets translated to [], not > unpackCString# "" - hence the unpack never gets in the way. If you had > the second rule, you'd soon want the first. > > > So I wondered if I could write a rule for head/unpackCString > > > > Urgh. not what we want though. GHC won't index the string at compile time, > > and I can't write a RULE for it. > > Yeah, I tried that too... > > > Perhaps you can newtype Char and use string overloading to work around the > > packing issue? > > That would work on GHC, but not on Hugs. Optimisation and Hu