From jeremy at n-heptane.com Fri Jan 1 12:16:49 2010 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Fri Jan 1 11:50:02 2010 Subject: ANN: Happstack 0.4.1 In-Reply-To: <4B3B3B6B.3010102@gmail.com> References: <54342.1261377119@n-heptane.com> <694519c50912211933p257746abgca00c46a443264ac@mail.gmail.com> <4B3B3B6B.3010102@gmail.com> Message-ID: Hello Simon, I have seen several manifestations of this issue now. I filed a report here: http://hackage.haskell.org/trac/ghc/ticket/3799 - jeremy On Dec 30, 2009, at 5:37 AM, Simon Marlow wrote: > On 22/12/09 03:33, Antoine Latter wrote: >> On Mon, Dec 21, 2009 at 6:31 AM, wrote: >>> Hello, >>> >>> That sort of missing symbol error at link time is often (but not >>> always) a >>> sign that some libraries got recompiled but not others. So there are >>> references to the old symbol names hanging around. >>> >>> I would try to ghc-pkg unregister syb-with-class and everything >>> that depends >>> on it, and then try cabal install happstack again. >>> >> >> I'm pretty well stumped at this point. I've cleared off everything >> and >> gone up to GHC 6.12 HEAD, and a 'cabal install happstack-data' gives >> me the same symbol not defined error in Happstack.Data.Xml.Base. >> >> But here's the spooky part, if I run it by hand like so: >> >> ghc --make src/Happstack/Data/Xml/Base.hs >> src/Happstack/Data/Default.hs src/Happstack/Data/ >> DeriveAll.hs src/Happstack/Data/Normalize.hs src/Happstack/Data/ >> Migrate.hs >> >> after resolving issues due to CPP not being run, everything runs to >> completion, no errors. Also, the list of things we're pulling in >> during the template-haskell execution is much smaller (see bellow). >> >> Has anyone seen this, where template-haskell behaves different when >> run from cabal-install (or Setup.hs) than from ghc --make (or ghci)? >> >>>>>>> >> 2 of 5] Compiling Happstack.Data.Migrate ( >> src/Happstack/Data/Migrate.hs, src/Happstack/Data/Migrate.o ) >> [3 of 5] Compiling Happstack.Data.Default ( >> src/Happstack/Data/Default.hs, src/Happstack/Data/Default.o ) >> [4 of 5] Compiling Happstack.Data.DeriveAll ( >> src/Happstack/Data/DeriveAll.hs, src/Happstack/Data/DeriveAll.o ) >> [5 of 5] Compiling Happstack.Data.Xml.Base ( >> src/Happstack/Data/Xml/Base.hs, src/Happstack/Data/Xml/Base.o ) >> Loading package ghc-prim ... linking ... done. >> Loading package integer-gmp ... linking ... done. >> Loading package base ... linking ... done. >> Loading package ffi-1.0 ... linking ... done. >> Loading package array-0.3.0.0 ... linking ... done. >> Loading package bytestring-0.9.1.5 ... linking ... done. >> Loading package containers-0.3.0.0 ... linking ... done. >> Loading package pretty-1.0.1.1 ... linking ... done. >> Loading package syb-0.1.0.2 ... linking ... done. >> Loading package template-haskell ... linking ... done. >> Loading package syb-with-class-0.6.1 ... linking ... done. >> mkUsageInfo: internal name? Element{tc a4av} >> <<<<< > > Did you submit a ticket for this? I don't recall seeing one. > > Cheers, > Simon From aslatter at gmail.com Fri Jan 1 13:26:30 2010 From: aslatter at gmail.com (Antoine Latter) Date: Fri Jan 1 12:59:42 2010 Subject: GHC.Prim.ByteArray# - confusing documentation In-Reply-To: <4B3B3DC1.4040409@gmail.com> References: <694519c50912241518p3ab50470m5d544fd5235abf1@mail.gmail.com> <4B3B2F26.3010504@gmail.com> <101998021.20091230140928@gmail.com> <4B3B3DC1.4040409@gmail.com> Message-ID: <694519c51001011026h62bea16cr9c159b7ab4bd1110@mail.gmail.com> On Wed, Dec 30, 2009 at 5:47 AM, Simon Marlow wrote: > On 30/12/09 11:09, Bulat Ziganshin wrote: >> >> Hello Simon, >> >> Wednesday, December 30, 2009, 1:44:54 PM, you wrote: >> >> btw, is it possible to fix the behavior? it will reduce overhead for >> storing small strings > > It would be possible yes. ?When the RTS needs to know the size of the array > in words it would have to do a calculation, so you'd have to find all the > places in the RTS that do this (probably only a handful, as most of them go > through the arr_words_sizeW() inline function). > > I don't plan to do this right now. ?If someone else wants to tackle it then > please go ahead, it'd be a fun afternoon hack. > I've written this up as ticket 3800: http://hackage.haskell.org/trac/ghc/ticket/3800 The patches for ghc and integer-gmp are attached to the ticket. Antoine From qdunkan at gmail.com Sat Jan 2 01:28:03 2010 From: qdunkan at gmail.com (Evan Laforge) Date: Sat Jan 2 01:01:11 2010 Subject: hptSomeThingsBelowUs missing module Message-ID: <2518b95d1001012228g28fcefbflcad22960a54592ce@mail.gmail.com> Ever since upgrading to 6.12.1, I've been getting a new warning. I compile with --make, e.g. (clipping out irrelevant stuff): ghc-6.12.1 -threaded -W -debug -package ghc --make \ -main-is App.Main App/Main.hs \ -o build/seq If I remove all imports to a module (say Util.Debug), compiling other modules prints this warning: WARNING in hptSomeThingsBelowUs missing module Util.Debug Probable cause: out-of-date interface files I searched on trac but didn't see anything with this name. Is this a known issue? It doesn't seem to cause any harm in the eventual binary, but is somewhat alarming to see a bunch of them scroll past. Manually wiping out a bunch of .hi files causes recompilation and the warning goes away. From bulat.ziganshin at gmail.com Sat Jan 2 06:07:56 2010 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Jan 2 05:41:13 2010 Subject: hptSomeThingsBelowUs missing module In-Reply-To: <2518b95d1001012228g28fcefbflcad22960a54592ce@mail.gmail.com> References: <2518b95d1001012228g28fcefbflcad22960a54592ce@mail.gmail.com> Message-ID: <35397616.20100102140756@gmail.com> Hello Evan, Saturday, January 2, 2010, 9:28:03 AM, you wrote: > Ever since upgrading to 6.12.1, I've been getting a new warning. I > Manually wiping out a bunch of .hi files causes recompilation and the > warning goes away. you need to do it. different ghc versions aren't compatible on .hi/.o files format/contents -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From qdunkan at gmail.com Sat Jan 2 11:02:03 2010 From: qdunkan at gmail.com (Evan Laforge) Date: Sat Jan 2 10:35:10 2010 Subject: hptSomeThingsBelowUs missing module In-Reply-To: <35397616.20100102140756@gmail.com> References: <2518b95d1001012228g28fcefbflcad22960a54592ce@mail.gmail.com> <35397616.20100102140756@gmail.com> Message-ID: <2518b95d1001020802m6e7a4aa0s5fd505d329a79c7a@mail.gmail.com> >> Ever since upgrading to 6.12.1, I've been getting a new warning. ?I > >> Manually wiping out a bunch of .hi files causes recompilation and the >> warning goes away. > > you need to do it. different ghc versions aren't compatible on .hi/.o > files format/contents Oh, it's not a 6.10 vs. 6.12 thing, I upgraded weeks ago and have rebuilt from scratch many times since. One thing I forgot to mention last time: the warning isn't totally harmless because it will cause ghci to fail to run functions no matter how much I reload modules. I have to quit and restart it to get it to work. From ndmitchell at gmail.com Mon Jan 4 15:15:03 2010 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Jan 4 14:48:07 2010 Subject: Where did the GHC API go? In-Reply-To: <4B3B6600.2000107@gmail.com> References: <42784f260912201447ub41b061q51baf68ca6f1c1dd@mail.gmail.com> <4B2F6C30.3080705@gmail.com> <404396ef0912231334p37435e89q6e245841844b24fa@mail.gmail.com> <20091224141815.GC5781@matrix.chaos.earth.li> <404396ef0912271024v498b3dbo8d47b42bbdc4b323@mail.gmail.com> <20091229114317.GA14270@matrix.chaos.earth.li> <4B3B6600.2000107@gmail.com> Message-ID: <404396ef1001041215v510dc90dgc8a33b12574a98be@mail.gmail.com> Hi, As a suggestion to stop this issue repeating, why not have the latest URL be an automatic and visible forward to the stable and guaranteed URL? (I can't remember the HTTP code, but I think it's permanent redirect) That way people are less likely to see these "unstable" URL's in their web browser, copy them, and have them end up all over the place. I think Google will also avoid indexing them at the latest URL. As it happens, I've put in another timebomb into Hoogle by linking to http://haskell.org/ghc/docs/latest/html/libraries/base-4.2.0.0/Prelude.html#v:filter - the very URL Ian said the docs had moved to (but is again unstable and not guaranteed in the long term). Having the URL redirection would have avoided that mistake. (I'll fix Hoogle as well though) Thanks, Neil 2009/12/30 Simon Marlow : > On 29/12/09 11:43, Ian Lynagh wrote: > >> You could also use e.g. the >> ? ? http://haskell.org/ghc/docs/6.12.1/html/libraries/index.html >> docs, which are stable. > > I've added symlinks for now. > > Cheers, > ? ? ? ?Simon > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From marlowsd at gmail.com Tue Jan 5 04:27:48 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Jan 5 04:01:02 2010 Subject: Building GHC 6.12 with GHC 6.12 + alex In-Reply-To: <694519c50912311208j57c86ec0mf5ed7edff7d4e65a@mail.gmail.com> References: <694519c50912310719v7d27943do81fdc970da2bd5fe@mail.gmail.com> <694519c50912311026i3c94fa5av8e22cd4cdb57b92@mail.gmail.com> <694519c50912311035u202556f8jfb71cbf2cab308fc@mail.gmail.com> <4B3CFFD9.2050205@gmail.com> <694519c50912311208j57c86ec0mf5ed7edff7d4e65a@mail.gmail.com> Message-ID: <4B430614.3060600@gmail.com> On 31/12/2009 20:08, Antoine Latter wrote: > On Thu, Dec 31, 2009 at 1:47 PM, Simon Marlow wrote: >> On 31/12/09 18:35, Antoine Latter wrote: >>> >>> >>> Further details: >>> >>> If I patch alex to explicitly set the encoding whenever it reads from >>> or writes to a file, all of these problems go away. I'm not really >>> sure why alex needs this and nothing else does, but so it goes. >>> >>> Is there a separate bug tracker for alex, or should this just be a GHC >>> bug? >> >> Thanks for looking into this - yes Alex needs to explicitly use utf8 for >> reading and writing files. Those of us using a utf-8 locale probably >> wouldn't have noticed the problem, what's your locale set to? >> >> If you can send me the patch, that will save me time figuring it out for >> myself. Alex doesn't have a bug tracker, but you're welcome to use GHC's if >> you want. >> >> Cheers, >> Simon >> > > I have the following environment variable set: > > __CF_USER_TEXT_ENCODING=0x1F5:0:0 > > But I have no idea what that means. Presumably something other than utf8. > > The alex patch is attached, but I have not tested it on anything other > than GHC 6.12. Applied, and I've uploaded Alex 2.3.2 to Hackage. Cheers, Simon From igloo at earth.li Wed Jan 6 06:35:09 2010 From: igloo at earth.li (Ian Lynagh) Date: Wed Jan 6 06:08:05 2010 Subject: Poll: Error message spans Message-ID: <20100106113509.GA2179@matrix.chaos.earth.li> Hi all, Currently, when GHC reports an error it only gives a source position, not a source span. For example, with this module: main = print (f (const 'x' 'x') 'y') f xs y = xs ++ [y] you get an error starting: u.hs:1:18: Couldn't match expected type `[a]' against inferred type `Char' There's a (probably little-known) flag -ferror-spans with which you get this error instead: u.hs:1:18-30: Couldn't match expected type `[a]' against inferred type `Char' i.e. rather than just giving the start column number 18, it gives you the span 18-30 (the "const 'x' 'x'"). Would you find the extra information useful, or just noise? i.e. should we show error spans by default? Thanks Ian From bulat.ziganshin at gmail.com Wed Jan 6 06:41:40 2010 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Jan 6 06:14:57 2010 Subject: Poll: Error message spans In-Reply-To: <20100106113509.GA2179@matrix.chaos.earth.li> References: <20100106113509.GA2179@matrix.chaos.earth.li> Message-ID: <17310709079.20100106144140@gmail.com> Hello Ian, Wednesday, January 6, 2010, 2:35:09 PM, you wrote: > Would you find the extra information useful, or just noise? > i.e. should we show error spans by default? i think it's useful in some cases, and don't add noticeable visual overhead in remaining ones -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From v.dijk.bas at gmail.com Wed Jan 6 07:43:53 2010 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Wed Jan 6 07:17:09 2010 Subject: Associativity of ViewPatterns Message-ID: Hello, Why is the following a syntax error: f (view1 -> view2 -> pattern) = ... and the following isn't: f (view1 -> (view2 -> pattern)) = ... I would prefer the first version. regards, Bas From simonpj at microsoft.com Wed Jan 6 11:34:04 2010 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Jan 6 11:07:11 2010 Subject: Associativity of ViewPatterns In-Reply-To: References: Message-ID: <59543203684B2244980D7E4057D5FBC10AF8D36D@DB3EX14MBXC308.europe.corp.microsoft.com> Good point. I'll fix that, in HEAD at least. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Bas van Dijk | Sent: 06 January 2010 12:44 | To: glasgow-haskell-users@haskell.org | Subject: Associativity of ViewPatterns | | Hello, | | Why is the following a syntax error: | | f (view1 -> view2 -> pattern) = ... | | and the following isn't: | | f (view1 -> (view2 -> pattern)) = ... | | I would prefer the first version. | | regards, | | Bas | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From alexander.dunlap at gmail.com Thu Jan 7 00:01:46 2010 From: alexander.dunlap at gmail.com (Alexander Dunlap) Date: Wed Jan 6 23:34:57 2010 Subject: Poll: Error message spans In-Reply-To: <20100106113509.GA2179@matrix.chaos.earth.li> References: <20100106113509.GA2179@matrix.chaos.earth.li> Message-ID: <57526e771001062101x7daf57adn1334adc0cf01bdf8@mail.gmail.com> On Wed, Jan 6, 2010 at 3:35 AM, Ian Lynagh wrote: > > Hi all, > > Currently, when GHC reports an error it only gives a source position, > not a source span. For example, with this module: > > ? ?main = print (f (const 'x' 'x') 'y') > ? ?f xs y = xs ++ [y] > > you get an error starting: > > ? ?u.hs:1:18: > ? ? ? ?Couldn't match expected type `[a]' against inferred type `Char' > > There's a (probably little-known) flag -ferror-spans with which you get > this error instead: > > ? ?u.hs:1:18-30: > ? ? ? ?Couldn't match expected type `[a]' against inferred type `Char' > > i.e. rather than just giving the start column number 18, it gives you > the span 18-30 (the "const 'x' 'x'"). > > > Would you find the extra information useful, or just noise? > i.e. should we show error spans by default? > > > Thanks > Ian > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > I certainly wouldn't find it distracting, and I think it could be quite useful in many cases. I vote for turning it on by default. Alex From v.dijk.bas at gmail.com Thu Jan 7 03:43:54 2010 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Thu Jan 7 03:17:07 2010 Subject: Associativity of ViewPatterns In-Reply-To: <59543203684B2244980D7E4057D5FBC10AF8D36D@DB3EX14MBXC308.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC10AF8D36D@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: On Wed, Jan 6, 2010 at 5:34 PM, Simon Peyton-Jones wrote: > Good point. I'll fix that, in HEAD at least. Thanks, BTW did you fix the infix instance headers problem in HEAD I previously mailed about? regards, Bas From simonpj at microsoft.com Thu Jan 7 05:02:28 2010 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Jan 7 04:35:44 2010 Subject: Associativity of ViewPatterns In-Reply-To: References: <59543203684B2244980D7E4057D5FBC10AF8D36D@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: <59543203684B2244980D7E4057D5FBC10AF9A87B@DB3EX14MBXC306.europe.corp.microsoft.com> Yes I did. That too was an oversight. Thanks for pointing both out. S | -----Original Message----- | From: Bas van Dijk [mailto:v.dijk.bas@gmail.com] | Sent: 07 January 2010 08:44 | To: Simon Peyton-Jones | Cc: glasgow-haskell-users@haskell.org | Subject: Re: Associativity of ViewPatterns | | On Wed, Jan 6, 2010 at 5:34 PM, Simon Peyton-Jones | wrote: | > Good point. I'll fix that, in HEAD at least. | | Thanks, | | BTW did you fix the infix instance headers problem in HEAD I | previously mailed about? | | regards, | | Bas From v.dijk.bas at gmail.com Thu Jan 7 05:18:03 2010 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Thu Jan 7 04:51:15 2010 Subject: Associativity of ViewPatterns In-Reply-To: <59543203684B2244980D7E4057D5FBC10AF9A87B@DB3EX14MBXC306.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC10AF8D36D@DB3EX14MBXC308.europe.corp.microsoft.com> <59543203684B2244980D7E4057D5FBC10AF9A87B@DB3EX14MBXC306.europe.corp.microsoft.com> Message-ID: On Thu, Jan 7, 2010 at 11:02 AM, Simon Peyton-Jones wrote: > Yes I did. ?That too was an oversight. Thanks for pointing both out. Ok thanks (I asked just to make sure I don't have to create a ticket.) Bas From Christian.Maeder at dfki.de Thu Jan 7 07:01:41 2010 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Jan 7 06:34:34 2010 Subject: haddock source link are wrong for haskell98 modules Message-ID: <4B45CD25.8090907@dfki.de> Hi, is this a known issue? All source links in haskell98 modules are dead I.e. in http://www.haskell.org/ghc/docs/latest/html/libraries/haskell98-1.0.1.1/Array.html The link under the first "Source" (at the right margin) points to http://www.haskell.org/ghc/docs/latest/html/libraries/haskell98-1.0.1.1/src/GHC-Arr.html#Array which does not exist. Can this be fixed easily? Cheers Christian From Christian.Maeder at dfki.de Thu Jan 7 07:13:49 2010 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Jan 7 06:46:43 2010 Subject: haddock source link are wrong for haskell98 modules In-Reply-To: <4B45CD25.8090907@dfki.de> References: <4B45CD25.8090907@dfki.de> Message-ID: <4B45CFFD.2020205@dfki.de> The link to Data.Time http://www.haskell.org/ghc/docs/latest/html/libraries/old-time-1.0.0.3/Data-Time.html in System.Time http://www.haskell.org/ghc/docs/latest/html/libraries/old-time-1.0.0.3/System-Time.html is also dead. There seems to be a problem with inter-package links. C. Christian Maeder schrieb: > Hi, > > is this a known issue? All source links in haskell98 modules are dead > > I.e. in > > http://www.haskell.org/ghc/docs/latest/html/libraries/haskell98-1.0.1.1/Array.html > > The link under the first "Source" (at the right margin) points to > > http://www.haskell.org/ghc/docs/latest/html/libraries/haskell98-1.0.1.1/src/GHC-Arr.html#Array > > which does not exist. > > Can this be fixed easily? > > Cheers Christian From byorgey at seas.upenn.edu Thu Jan 7 12:06:14 2010 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Thu Jan 7 11:39:05 2010 Subject: Poll: Error message spans In-Reply-To: <57526e771001062101x7daf57adn1334adc0cf01bdf8@mail.gmail.com> References: <20100106113509.GA2179@matrix.chaos.earth.li> <57526e771001062101x7daf57adn1334adc0cf01bdf8@mail.gmail.com> Message-ID: <20100107170614.GA3510@seas.upenn.edu> On Wed, Jan 06, 2010 at 09:01:46PM -0800, Alexander Dunlap wrote: > On Wed, Jan 6, 2010 at 3:35 AM, Ian Lynagh wrote: > > > > Would you find the extra information useful, or just noise? > > i.e. should we show error spans by default? > > > I certainly wouldn't find it distracting, and I think it could be > quite useful in many cases. I vote for turning it on by default. I agree. -Brent From igloo at earth.li Thu Jan 7 12:30:55 2010 From: igloo at earth.li (Ian Lynagh) Date: Thu Jan 7 12:03:46 2010 Subject: haddock source link are wrong for haskell98 modules In-Reply-To: <4B45CFFD.2020205@dfki.de> References: <4B45CD25.8090907@dfki.de> <4B45CFFD.2020205@dfki.de> Message-ID: <20100107173055.GA16672@matrix.chaos.earth.li> On Thu, Jan 07, 2010 at 01:13:49PM +0100, Christian Maeder wrote: > The link to Data.Time > http://www.haskell.org/ghc/docs/latest/html/libraries/old-time-1.0.0.3/Data-Time.html > in System.Time > http://www.haskell.org/ghc/docs/latest/html/libraries/old-time-1.0.0.3/System-Time.html > is also dead. > > Christian Maeder schrieb: > > Hi, > > > > is this a known issue? All source links in haskell98 modules are dead > > > > I.e. in > > > > http://www.haskell.org/ghc/docs/latest/html/libraries/haskell98-1.0.1.1/Array.html > > > > The link under the first "Source" (at the right margin) points to > > > > http://www.haskell.org/ghc/docs/latest/html/libraries/haskell98-1.0.1.1/src/GHC-Arr.html#Array > > > > which does not exist. Thanks for the report; I've filed a ticket for these: http://hackage.haskell.org/trac/ghc/ticket/3810 Thanks Ian From malcolm.wallace at cs.york.ac.uk Thu Jan 7 16:13:10 2010 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Thu Jan 7 15:45:58 2010 Subject: Poll: Error message spans In-Reply-To: <20100107170614.GA3510@seas.upenn.edu> References: <20100106113509.GA2179@matrix.chaos.earth.li> <57526e771001062101x7daf57adn1334adc0cf01bdf8@mail.gmail.com> <20100107170614.GA3510@seas.upenn.edu> Message-ID: >>> Would you find the extra information useful, or just noise? >>> i.e. should we show error spans by default? >>> >> I certainly wouldn't find it distracting, and I think it could be >> quite useful in many cases. I vote for turning it on by default. > > I agree. +1. It is a feature I have always found useful in other tools. (Although ghc does usually quote the entire literal source expression denoted by the span, so perhaps the info is slightly redundant.) Regards, Malcolm From rtvd at mac.com Sat Jan 9 17:33:26 2010 From: rtvd at mac.com (Denys Rtveliashvili) Date: Sat Jan 9 17:06:14 2010 Subject: Adding support for CLDouble Message-ID: <1263076406.3967.31.camel@blackswan> Hi, Currently ghc 6.12 does not have support for CLDouble type (and there is an open issue on trac about it http://hackage.haskell.org/trac/ghc/ticket/3353 ). I have been trying to figure out what is necessary to add it. After playing with the code a bit I've got a few questions... 1. Should there be a LDouble type, just like for CFloat and CDouble there there are Haskell-native types Float and Double? 2. The ghc compiler references Float and Double in its code. When a similar code is added for LDouble, the compiler does not get built. In particular, 'compiler/coreSyn/CoreSyn.lhs' does not see 'LDouble' despite I declared and exported it in 'libraries/ghc-prim/GHC/Types.hs'. This probably makes sense in case compiler is built first. But then in turns out to be a chicken and egg situation as to support a new type in GHC one needs to have another GHC that already supports it. Or, perhaps, I am missing something? 3. http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/HaskellExecution/Registers mentions that there are registers for floats and doubles. What should be done about long doubles then? With kind regards and hope that gurus may shed some light on the above, Denys Rtveliashvili From jon at ffconsultancy.com Sun Jan 10 00:42:46 2010 From: jon at ffconsultancy.com (Jon Harrop) Date: Sat Jan 9 23:00:51 2010 Subject: Ray tracer language comparison Message-ID: <201001100542.46907.jon@ffconsultancy.com> I recently published some performance results using GHC 6.12: http://flyingfrogblog.blogspot.com/2010/01/hlvm-on-ray-tracer-language-comparison.html However, I just noticed that the Haskell is producing garbage output with GHC 6.12 and not 6.10 or 6.8. You may like to check this with a recent build or put the program in the GHC test suite. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e From dmitry.tsygankov at gmail.com Sun Jan 10 11:09:33 2010 From: dmitry.tsygankov at gmail.com (Dmitry Tsygankov) Date: Sun Jan 10 10:42:16 2010 Subject: Type families and type inference - a question Message-ID: <53126cd61001100809g3a5827cdpa686affedfcdfb87@mail.gmail.com> Dear all, I was playing around recently with translating the dependency injection idea (http://martinfowler.com/articles/injection.html) into Haskell, and got to the following code: {-# LANGUAGE TypeFamilies, FlexibleContexts #-} data Movie = Movie { getDirector :: String } data (MovieFinder f) => MovieLister f = MovieLister { getFinder :: f } -- Cannot remove the type signature here createLister :: (MovieFinder f) => (FinderResultMonad f) (MovieLister f) createLister = fmap MovieLister createFinder class (Monad (FinderResultMonad f), Functor (FinderResultMonad f)) => MovieFinder f where type FinderResultMonad f :: * -> * createFinder :: (FinderResultMonad f) f findAll :: f -> (FinderResultMonad f) [Movie] It may be dumb (well, the Java version isn't particularly useful either), but the thing I really do not understand is the type signature - why can't I simply remove it? Some output from GHCi: GHCi, version 6.12.1: http://www.haskell.org/ghc/ :? for help *IfaceInj> :t fmap MovieLister fmap MovieLister :: (MovieFinder a, Functor f) => f a -> f (MovieLister a) *IfaceInj> :t createFinder createFinder :: (MovieFinder f) => FinderResultMonad f f Looks reasonable so far... *IfaceInj> :t fmap MovieLister createFinder fmap MovieLister createFinder :: (f ~ FinderResultMonad a, MovieFinder a, Functor f) => f (MovieLister a) Here's the first WTF. If the type inference engine knows that f ~ FinderResultMonad a, it can 'guess' the type (MovieFinder a, Functor (FinderResultMonad a)) => (FinderResultMonad a) (MovieLister a) , can't it? And since there's a constraint on the MovieFinder type class, it can further 'guess' (MovieFinder a) => (FinderResultMonad a) (MovieLister a) , which is exactly the type signature I have written by hand, but it doesn't. Is it a bug, a missing feature, or just my lack of knowledge? OK, so far, so good, let's call it a missing feature or something that is impossible to implement. *IfaceInj> let q = fmap MovieLister createFinder :1:25: Couldn't match expected type `FinderResultMonad a' against inferred type `f' NB: `FinderResultMonad' is a type function, and may not be injective In the second argument of `fmap', namely `createFinder' In the expression: fmap MovieLister createFinder In the definition of `q': q = fmap MovieLister createFinder Here's the second WTF. It seems like the type inference engine CAN infer the type of (fmap MovieLister createFinder). If I manually enter the type inferred by ':t fmap MovieLister createFinder' to the signature of createLister, everything compiles OK. But if I remove the type signature from createLister completely, I get the same error: *IfaceInj> :load "/home/dima/projects/IfaceInj.hs" [1 of 1] Compiling IfaceInj ( /home/dima/projects/IfaceInj.hs, interpreted ) /home/dima/projects/IfaceInj.hs:9:32: Couldn't match expected type `FinderResultMonad a' against inferred type `f' NB: `FinderResultMonad' is a type function, and may not be injective In the second argument of `fmap', namely `createFinder' In the expression: fmap MovieLister createFinder In the definition of `createLister': createLister = fmap MovieLister createFinder Failed, modules loaded: none. That looks like a bug to me, but I can't be sure since I have no real experience in Haskell. Any ideas? Regards, Dmitry. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100110/4fdd07a8/attachment.html From bulat.ziganshin at gmail.com Sun Jan 10 11:28:40 2010 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun Jan 10 11:01:31 2010 Subject: Type families and type inference - a question In-Reply-To: <53126cd61001100809g3a5827cdpa686affedfcdfb87@mail.gmail.com> References: <53126cd61001100809g3a5827cdpa686affedfcdfb87@mail.gmail.com> Message-ID: <892787424.20100110192840@gmail.com> Hello Dmitry, Sunday, January 10, 2010, 7:09:33 PM, you wrote: > -- Cannot remove the type signature here > createLister :: (MovieFinder f) => (FinderResultMonad f) (MovieLister f) > createLister = fmap MovieLister createFinder it's a Monomorphism Restriction of Haskell'98, disabled with -XNoMonomorphismRestriction -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From dmitry.tsygankov at gmail.com Sun Jan 10 11:49:51 2010 From: dmitry.tsygankov at gmail.com (Dmitry Tsygankov) Date: Sun Jan 10 11:22:33 2010 Subject: Type families and type inference - a question In-Reply-To: <892787424.20100110192840@gmail.com> References: <53126cd61001100809g3a5827cdpa686affedfcdfb87@mail.gmail.com> <892787424.20100110192840@gmail.com> Message-ID: <53126cd61001100849t32137fafl64231a27969ef574@mail.gmail.com> Oh, I see... Thank you, it works now with NoMonomorphismRestriction. The error message is extremely misleading though... And so is the type signature inferred by the compiler. 2010/1/10 Bulat Ziganshin > it's a Monomorphism Restriction of Haskell'98, disabled with > -XNoMonomorphismRestriction > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100110/5052dcc3/attachment.html From daniel.is.fischer at web.de Sun Jan 10 12:11:07 2010 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Sun Jan 10 11:45:30 2010 Subject: Type families and type inference - a question In-Reply-To: <53126cd61001100809g3a5827cdpa686affedfcdfb87@mail.gmail.com> References: <53126cd61001100809g3a5827cdpa686affedfcdfb87@mail.gmail.com> Message-ID: <201001101811.08026.daniel.is.fischer@web.de> Am Sonntag 10 Januar 2010 17:09:33 schrieb Dmitry Tsygankov: > Dear all, > > I was playing around recently with translating the dependency injection > idea (http://martinfowler.com/articles/injection.html) into Haskell, and > got to the following code: > > > {-# LANGUAGE TypeFamilies, FlexibleContexts #-} What you need is also {-# LANGUAGE NoMonomorphismRestriction #-} Read http://haskell.org/onlinereport/decls.html#sect4.5.5 and http://www.haskell.org/haskellwiki/Monomorphism_restriction for background. > > data Movie = Movie { getDirector :: String } > data (MovieFinder f) => MovieLister f = MovieLister { getFinder :: f } Don't do that. Type class constraints on data types probably do not what you think. You'll have to put the constraint on the functions using MovieLister nevertheless. > > -- Cannot remove the type signature here > createLister :: (MovieFinder f) => (FinderResultMonad f) (MovieLister f) > createLister = fmap MovieLister createFinder createLister is a top-level binding which is bound by a simple pattern binding. By the monomorphism restriction, such things must have a monomorphic type unless a type signature is given. The monomorphic type assigned to such an entity (if possible) is determined via the defaulting rules http://haskell.org/onlinereport/decls.html#sect4.3.4 Here, the inferred type is createLister :: (f ~ FinderResultMonad a, MovieFinder a, Functor f) => f (MovieLister a) which hasn't the form allowed by the defaulting rules, monomorphising fails (even if f is resolved to FinderResultMonad a, and the type is written as createLister :: (MovieFinder a) => FinderResultMonad a (MovieLister a), the problem remains that MovieFinder is not a class defined in the standard libraries, hence defaulting isn't possible). > > class (Monad (FinderResultMonad f), Functor (FinderResultMonad f)) => > MovieFinder f where > type FinderResultMonad f :: * -> * > createFinder :: (FinderResultMonad f) f > findAll :: f -> (FinderResultMonad f) [Movie] > > > It may be dumb (well, the Java version isn't particularly useful > either), but the thing I really do not understand is the type signature > - why can't I simply remove it? Monomorphism restriction. If you can't remove a type signature, it's almost always that (sometimes it's polymorphic recursion). > Some output from GHCi: > > GHCi, version 6.12.1: http://www.haskell.org/ghc/ :? for help > *IfaceInj> :t fmap MovieLister > fmap MovieLister > > :: (MovieFinder a, Functor f) => f a -> f (MovieLister a) > > *IfaceInj> :t createFinder > createFinder :: (MovieFinder f) => FinderResultMonad f f > > Looks reasonable so far... > > *IfaceInj> :t fmap MovieLister createFinder > fmap MovieLister createFinder > > :: (f ~ FinderResultMonad a, MovieFinder a, Functor f) => > > f (MovieLister a) > > Here's the first WTF. If the type inference engine knows that f ~ > FinderResultMonad a, it can 'guess' the type > (MovieFinder a, Functor (FinderResultMonad a)) => (FinderResultMonad a) > (MovieLister a) > , can't it? It can, see below. It just chose to display it in a different form. > And since there's a constraint on the MovieFinder type > class, it can further 'guess' > (MovieFinder a) => (FinderResultMonad a) (MovieLister a) > , which is exactly the type signature I have written by hand, but it > doesn't. Is it a bug, a missing feature, or just my lack of knowledge? It's the dreaded MR. That and the often surprising ways of ghci to display inferred types. > OK, so far, so good, let's call it a missing feature or something that > is impossible to implement. > > *IfaceInj> let q = fmap MovieLister createFinder > > :1:25: > Couldn't match expected type `FinderResultMonad a' > against inferred type `f' > NB: `FinderResultMonad' is a type function, and may not be > injective In the second argument of `fmap', namely `createFinder' > In the expression: fmap MovieLister createFinder > In the definition of `q': q = fmap MovieLister createFinder (Note: Surprisingly (?), if you load a module with {-# LANGUAGE NoMonomorphismRestriction #-} , the monomorphsm restriction is still enabled at the ghci prompt, so we have to disable it for that again - or we could have loaded the module with $ ghci -XNoMonomorphismRestriction Movie) *Movie> :set -XNoMonomorphismRestriction *Movie> let q = fmap MovieLister createFinder *Movie> :t q q :: (MovieFinder a) => FinderResultMonad a (MovieLister a) Okay, what happened there? > *IfaceInj> :t fmap MovieLister > fmap MovieLister > > :: (MovieFinder a, Functor f) => f a -> f (MovieLister a) > > *IfaceInj> :t createFinder > createFinder :: (MovieFinder a) => FinderResultMonad a a Now, to infer the type of fmap MovieLister createFinder, the type of (fmap MovieLister)'s argument, f a [we ignore contexts for a moment], has to be unified with the type of createFinder, FinderResultMoad a a. That gives, obviously, f ~ FinderResultMonad a, a further constraint. Joining the constraints, we get fmap MovieLister createFinder :: (f ~ FinderResultMonad a, MovieFinder a, Functor f) => f (MovieLister a) Fine. But now, since the expression is bound to a name, without a type signature, it must be made monomorphic - but it can't. The error message isn't helpful, though. > > Here's the second WTF. It seems like the type inference engine CAN infer > the type of (fmap MovieLister createFinder). If I manually enter the > type inferred by ':t fmap MovieLister createFinder' to the signature of > createLister, everything compiles OK. But if I remove the type signature > from createLister completely, I get the same error: > > *IfaceInj> :load "/home/dima/projects/IfaceInj.hs" > [1 of 1] Compiling IfaceInj ( /home/dima/projects/IfaceInj.hs, > interpreted ) > > /home/dima/projects/IfaceInj.hs:9:32: > Couldn't match expected type `FinderResultMonad a' > against inferred type `f' > NB: `FinderResultMonad' is a type function, and may not be > injective In the second argument of `fmap', namely `createFinder' > In the expression: fmap MovieLister createFinder > In the definition of `createLister': > createLister = fmap MovieLister createFinder > Failed, modules loaded: none. > > That looks like a bug to me, but I can't be sure since I have no real > experience in Haskell. > > Any ideas? > > Regards, > > Dmitry. From gale at sefer.org Sun Jan 10 14:40:34 2010 From: gale at sefer.org (Yitzchak Gale) Date: Sun Jan 10 14:13:16 2010 Subject: Type families and type inference - a question In-Reply-To: <201001101811.08026.daniel.is.fischer@web.de> References: <53126cd61001100809g3a5827cdpa686affedfcdfb87@mail.gmail.com> <201001101811.08026.daniel.is.fischer@web.de> Message-ID: <2608b8a81001101140s488feabbx8d9a178f1b4f772@mail.gmail.com> Daniel Fischer wrote: > (Note: Surprisingly (?), if you load a module with > {-# LANGUAGE NoMonomorphismRestriction #-} > , the monomorphsm restriction is still enabled at the ghci prompt, so we > have to disable it for that again - or we could have loaded the module with > $ ghci -XNoMonomorphismRestriction Movie) IMHO, the monomorphism restriction does not make sense at the GHCi prompt in any case, no matter what you have or haven't loaded, and no matter what your opinion of MR in general. I recommend that you create a file called ".ghci" in your home directory, and put into it the line: :set -XNoMonomorphismRestriction Then you won't be bothered by this anymore for things that you type in at the prompt. I think this may be scheduled to be fixed in a coming version of GHCi. Regards, Yitz From dmitry.tsygankov at gmail.com Sun Jan 10 23:08:30 2010 From: dmitry.tsygankov at gmail.com (Dmitry Tsygankov) Date: Sun Jan 10 22:41:13 2010 Subject: Type families and type inference - a question In-Reply-To: <2608b8a81001101140s488feabbx8d9a178f1b4f772@mail.gmail.com> References: <53126cd61001100809g3a5827cdpa686affedfcdfb87@mail.gmail.com> <201001101811.08026.daniel.is.fischer@web.de> <2608b8a81001101140s488feabbx8d9a178f1b4f772@mail.gmail.com> Message-ID: <53126cd61001102008k285a44aqf6262f50e9b2550e@mail.gmail.com> 2010/1/10 Yitzchak Gale > IMHO, the monomorphism restriction does not make sense at the > GHCi prompt in any case, no matter what you have or haven't > loaded, and no matter what your opinion of MR in general. Looks reasonable to me, that's why I intuitively expected let q = fmap MovieLister createFinder to work. Not sure I would want that behaviour when I ':load' a file though, as it may provide a false sense of security. -XTypeFamilies isn't turned on automatically, why should -XNoMonomorphismRestriction be? > I recommend that you create a file called ".ghci" > in your home directory, and put into it the line: > > :set -XNoMonomorphismRestriction That seems to also affect how the file is ':load'-ed, not sure I would want to do that. From daniel.is.fischer at web.de Mon Jan 11 02:45:08 2010 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Mon Jan 11 02:19:30 2010 Subject: Type families and type inference - a question In-Reply-To: <53126cd61001102008k285a44aqf6262f50e9b2550e@mail.gmail.com> References: <53126cd61001100809g3a5827cdpa686affedfcdfb87@mail.gmail.com> <2608b8a81001101140s488feabbx8d9a178f1b4f772@mail.gmail.com> <53126cd61001102008k285a44aqf6262f50e9b2550e@mail.gmail.com> Message-ID: <201001110845.09088.daniel.is.fischer@web.de> Am Montag 11 Januar 2010 05:08:30 schrieb Dmitry Tsygankov: > 2010/1/10 Yitzchak Gale > > > IMHO, the monomorphism restriction does not make sense at the > > GHCi prompt in any case, no matter what you have or haven't > > loaded, and no matter what your opinion of MR in general. > > Looks reasonable to me, that's why I intuitively expected > let q = fmap MovieLister createFinder > to work. > Not sure I would want that behaviour when I ':load' a file though, as > it may provide a false sense of security. -XTypeFamilies isn't turned > on automatically, why should -XNoMonomorphismRestriction be? > You're more likely to omit (forget) type signatures for quick bindings at the prompt. The monomorphism restriction is inconvenient then. > > I recommend that you create a file called ".ghci" > > > > in your home directory, and put into it the line: > > :set -XNoMonomorphismRestriction > > That seems to also affect how the file is ':load'-ed, not sure I would > want to do that. If you want the MR in some module, you can enable it via {-# LANGUAGE MonomorphismRestriction #-} there. It's a question of what you deem more (in)convenient. Since the MR is not entirely unlikely to be removed from the (default) language, the latter is more future-proof. From marlowsd at gmail.com Mon Jan 11 05:10:03 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Jan 11 04:42:45 2010 Subject: Poll: Error message spans In-Reply-To: <20100106113509.GA2179@matrix.chaos.earth.li> References: <20100106113509.GA2179@matrix.chaos.earth.li> Message-ID: <4B4AF8FB.3000905@gmail.com> On 06/01/10 11:35, Ian Lynagh wrote: > Currently, when GHC reports an error it only gives a source position, > not a source span. For example, with this module: > > main = print (f (const 'x' 'x') 'y') > f xs y = xs ++ [y] > > you get an error starting: > > u.hs:1:18: > Couldn't match expected type `[a]' against inferred type `Char' > > There's a (probably little-known) flag -ferror-spans with which you get > this error instead: > > u.hs:1:18-30: > Couldn't match expected type `[a]' against inferred type `Char' > > i.e. rather than just giving the start column number 18, it gives you > the span 18-30 (the "const 'x' 'x'"). > > > Would you find the extra information useful, or just noise? > i.e. should we show error spans by default? I think we should point out that this will mean tools that interpret GHC error messages will need to be updated: e.g. Emacs/vim modes. Errors that span multiple lines look like this: Foo.hs:(1,0)-(10,33): ... though the exact format could be changed. I lean towards leaving it turned off. Visual tools that want to turn it on can do so, but using GHC from the command line with a text editor I don't think I've ever wanted to know the endpoint of the expression to which an error message refers, and there are downsides: breaking tools, and extra clutter in the error messages. Cheers, Simon From valery.vv at gmail.com Mon Jan 11 05:14:23 2010 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Mon Jan 11 04:47:04 2010 Subject: is GHC developers wiki down? Message-ID: Clicking ``Developers (Wiki)'' link [http://hackage.haskell.org/trac/ghc] from GHC page [http://www.haskell.org/ghc/] returns Environment not found Neither the link is accessible from command line: $ curl -I 'http://hackage.haskell.org/trac/ghc' HTTP/1.0 404 Not Found Date: Mon, 11 Jan 2010 10:00:36 GMT Server: Apache/2.2.3 (Debian) Content-Type: text/plain; charset=UTF-8 Age: 38 Content-Length: 21 X-Cache: HIT from xproxy.foo.bar.ua X-Cache-Lookup: HIT from xproxy.foo.bar.ua:3128 Via: 1.1 xproxy.foo.bar.ua:3128 (squid/2.7.STABLE6) Connection: close -- Best regards, vvv From marlowsd at gmail.com Mon Jan 11 05:20:51 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Jan 11 04:53:35 2010 Subject: Ray tracer language comparison In-Reply-To: <201001100542.46907.jon@ffconsultancy.com> References: <201001100542.46907.jon@ffconsultancy.com> Message-ID: <4B4AFB83.5000107@gmail.com> On 10/01/10 05:42, Jon Harrop wrote: > > I recently published some performance results using GHC 6.12: > > http://flyingfrogblog.blogspot.com/2010/01/hlvm-on-ray-tracer-language-comparison.html > > However, I just noticed that the Haskell is producing garbage output with GHC > 6.12 and not 6.10 or 6.8. You may like to check this with a recent build or > put the program in the GHC test suite. Could you provide a link to the code that demonstrates the problem? There were several versions of ray.hs. Cheers, Simon From marlowsd at gmail.com Mon Jan 11 05:24:07 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Jan 11 04:56:51 2010 Subject: hptSomeThingsBelowUs missing module In-Reply-To: <2518b95d1001020802m6e7a4aa0s5fd505d329a79c7a@mail.gmail.com> References: <2518b95d1001012228g28fcefbflcad22960a54592ce@mail.gmail.com> <35397616.20100102140756@gmail.com> <2518b95d1001020802m6e7a4aa0s5fd505d329a79c7a@mail.gmail.com> Message-ID: <4B4AFC47.1040501@gmail.com> On 02/01/10 16:02, Evan Laforge wrote: >>> Ever since upgrading to 6.12.1, I've been getting a new warning. I >> >>> Manually wiping out a bunch of .hi files causes recompilation and the >>> warning goes away. >> >> you need to do it. different ghc versions aren't compatible on .hi/.o >> files format/contents > > Oh, it's not a 6.10 vs. 6.12 thing, I upgraded weeks ago and have > rebuilt from scratch many times since. > > One thing I forgot to mention last time: the warning isn't totally > harmless because it will cause ghci to fail to run functions no matter > how much I reload modules. I have to quit and restart it to get it to > work. If you can reproduce the problem, please submit a bug report. Cheers, Simon From marlowsd at gmail.com Mon Jan 11 05:29:51 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Jan 11 05:02:34 2010 Subject: is GHC developers wiki down? In-Reply-To: References: Message-ID: <4B4AFD9F.2090502@gmail.com> On 11/01/10 10:14, Valery V. Vorotyntsev wrote: > Clicking ``Developers (Wiki)'' link [http://hackage.haskell.org/trac/ghc] > from GHC page [http://www.haskell.org/ghc/] returns > > Environment not found It works if you put an extra slash on the end, ie. http://hackage.haskell.org/trac/ghc/ hackage.haskell.org is currently transitioning to a new server, and the GHC Trac has already moved over but requests have to be proxied through the old server. Ian set all this up, so I assume he only set up proxying for URLs beginning http://hackage.haskell.org/trac/ghc/. Ian? You may have noticed that we're now on Trac 0.11 thanks to the migration. Cheers, Simon From igloo at earth.li Mon Jan 11 05:30:09 2010 From: igloo at earth.li (Ian Lynagh) Date: Mon Jan 11 05:02:49 2010 Subject: is GHC developers wiki down? In-Reply-To: References: Message-ID: <20100111103009.GA10067@matrix.chaos.earth.li> On Mon, Jan 11, 2010 at 12:14:23PM +0200, Valery V. Vorotyntsev wrote: > Clicking ``Developers (Wiki)'' link [http://hackage.haskell.org/trac/ghc] > from GHC page [http://www.haskell.org/ghc/] returns > > Environment not found I've fixed the link. Thanks Ian From simonpj at microsoft.com Mon Jan 11 11:28:29 2010 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Jan 11 11:02:20 2010 Subject: Type families and type inference - a question In-Reply-To: <2608b8a81001101140s488feabbx8d9a178f1b4f772@mail.gmail.com> References: <53126cd61001100809g3a5827cdpa686affedfcdfb87@mail.gmail.com> <201001101811.08026.daniel.is.fischer@web.de> <2608b8a81001101140s488feabbx8d9a178f1b4f772@mail.gmail.com> Message-ID: <59543203684B2244980D7E4057D5FBC10AF9ED5A@DB3EX14MBXC306.europe.corp.microsoft.com> Yes indeed; see http://hackage.haskell.org/trac/ghc/ticket/3202 http://hackage.haskell.org/trac/ghc/ticket/3217 One-line summary: we have a spec, but no volunteer. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Yitzchak Gale | Sent: 10 January 2010 19:41 | To: Dmitry Tsygankov | Cc: glasgow-haskell-users | Subject: Re: Type families and type inference - a question | | Daniel Fischer wrote: | > (Note: Surprisingly (?), if you load a module with | > {-# LANGUAGE NoMonomorphismRestriction #-} | > , the monomorphsm restriction is still enabled at the ghci prompt, so we | > have to disable it for that again - or we could have loaded the module with | > $ ghci -XNoMonomorphismRestriction Movie) | | IMHO, the monomorphism restriction does not make sense at the | GHCi prompt in any case, no matter what you have or haven't | loaded, and no matter what your opinion of MR in general. | | I recommend that you create a file called ".ghci" | in your home directory, and put into it the line: | | :set -XNoMonomorphismRestriction | | Then you won't be bothered by this anymore for things | that you type in at the prompt. | | I think this may be scheduled to be fixed in a coming version | of GHCi. | | Regards, | Yitz | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From igloo at earth.li Wed Jan 13 16:57:07 2010 From: igloo at earth.li (Ian Lynagh) Date: Wed Jan 13 16:29:39 2010 Subject: Poll: Error message spans In-Reply-To: <4B4AF8FB.3000905@gmail.com> References: <20100106113509.GA2179@matrix.chaos.earth.li> <4B4AF8FB.3000905@gmail.com> Message-ID: <20100113215707.GA31431@matrix.chaos.earth.li> On Mon, Jan 11, 2010 at 10:10:03AM +0000, Simon Marlow wrote: > > don't think I've ever wanted to know the endpoint of the expression to > which an error message refers, Here's an example where it is useful (arguably due to a poor error message): http://hackage.haskell.org/trac/ghc/ticket/3746 Thanks Ian From nominolo at googlemail.com Fri Jan 15 16:53:46 2010 From: nominolo at googlemail.com (Thomas Schilling) Date: Fri Jan 15 16:26:33 2010 Subject: Poll: Error message spans In-Reply-To: <4B4AF8FB.3000905@gmail.com> References: <20100106113509.GA2179@matrix.chaos.earth.li> <4B4AF8FB.3000905@gmail.com> Message-ID: <916b84821001151353l4dc2bac1na37c5bbf90b11f84@mail.gmail.com> Additionally, tools based on the GHC API already have this information available and wouldn't be affected either way. -- Push the envelope. Watch it bend. From marcot at riseup.net Sun Jan 17 12:31:59 2010 From: marcot at riseup.net (Marco =?ISO-8859-1?Q?T=FAlio?= Gontijo e Silva) Date: Sun Jan 17 12:04:23 2010 Subject: ghc API in platforms with no GHCi Message-ID: <1263749519.2544.609.camel@zezinho> Hi. I noticed that in Debian/KFreeBSD the module ByteCodeLink is not available, which cause the build error of haskell-hint in Debian's buildds. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=564136 This is also the case of alpha, armel, hppa, mips, powerpc and s390. I haven't checked if these are the architectures without GHCi but I suspect they are. Is the full ghc API available only in arches in which GHCi is available? Greetings. -- marcot http://marcot.iaaeee.org/ From simonpj at microsoft.com Mon Jan 18 04:55:06 2010 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Jan 18 04:27:46 2010 Subject: [Template-haskell] Querying the instances a data type implements In-Reply-To: <0016e64cb8f8bfdc84047d64c92f@google.com> References: <0016e64cb8f8bfdc84047d64c92f@google.com> Message-ID: <59543203684B2244980D7E4057D5FBC10AFA4087@DB3EX14MBXC306.europe.corp.microsoft.com> All: as Robert says, I keep meaning to close the template-haskell list altogether; but I am not sure how to do so. Jonathan: where did you find a pointer to the mailing list? I should remove those too. Returning to the question, sadly there's no way to do what you want right now. There's an open feature request: http://hackage.haskell.org/trac/ghc/ticket/1835 Would anyone like to undertake it? It's not hard. Simon From: template-haskell-bounces@haskell.org [mailto:template-haskell-bounces@haskell.org] On Behalf Of jonathanGfischoff@gmail.com Sent: 17 January 2010 23:42 To: template-haskell@haskell.org Subject: [Template-haskell] Querying the instances a data type implements Hi, I am trying query the instances that a data type implements. Calling reify on the data type doesn't appear to return anything relating to type classes. I am very new to Template Haskell, so I apologize if there is a easy way to do this that I missed. -Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100118/7c9f1104/attachment.html From leather at cs.uu.nl Mon Jan 18 11:58:50 2010 From: leather at cs.uu.nl (Sean Leather) Date: Mon Jan 18 11:31:28 2010 Subject: Can't infer type (type family + "element" type) Message-ID: <3c6288ab1001180858j7d4939c3v821c18acae34d139@mail.gmail.com> Suppose I have a class C, > class C a where > ? type E a > ? c :: E a -> a -> a a datatype T, > data T a = T a and an instance of C for T > instance C (T a) where > ? type E (T a) = a > ? c x (T _) = T x I would like to write a function such as f > f t@(T x) = c x t without a type signature. Unfortunately, I can't because GHC tells me ??? Couldn't match expected type `t' against inferred type `T (E t)' ??? In the second argument of `c', namely `t' ??? In the expression: c x t ??? In the definition of `f': f (t@(T x)) = c x t There are at least three possible ways to write the above code such that it works. (1) Give a type signature for f > f :: T a -> T a (2) Define the class C using an equality constraint > class C t where > ? type E t > ? c :: (E t ~ e) => e -> t -> t (3) Define the class C using functional dependencies > class C t e | t -> e where > ? c :: e -> t -> t But the real question is why don't I get a type for f? This has been tested in GHC 6.10.1 and 6.12.1. Thanks, Sean From simonpj at microsoft.com Tue Jan 19 05:15:51 2010 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Jan 19 04:48:27 2010 Subject: Can't infer type (type family + "element" type) In-Reply-To: <3c6288ab1001180858j7d4939c3v821c18acae34d139@mail.gmail.com> References: <3c6288ab1001180858j7d4939c3v821c18acae34d139@mail.gmail.com> Message-ID: <59543203684B2244980D7E4057D5FBC10AFA4E80@DB3EX14MBXC306.europe.corp.microsoft.com> Looks like a bug to me! I am currently elbows-deep in re-engineering GHC's entire constraint generation and solving mechanism, which will, I hope, simply solve your problem. But meanwhile can I ask a favour: submit a Trac report with the offending code in reproducible form? Then I'll be sure to test the new code against all such tickets. Thanks Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Sean Leather | Sent: 18 January 2010 16:59 | To: GHC Users List | Subject: Can't infer type (type family + "element" type) | | Suppose I have a class C, | | > class C a where | > ? type E a | > ? c :: E a -> a -> a | | a datatype T, | | > data T a = T a | | and an instance of C for T | | > instance C (T a) where | > ? type E (T a) = a | > ? c x (T _) = T x | | I would like to write a function such as f | | > f t@(T x) = c x t | | without a type signature. Unfortunately, I can't because GHC tells me | | ??? Couldn't match expected type `t' against inferred type `T (E t)' | ??? In the second argument of `c', namely `t' | ??? In the expression: c x t | ??? In the definition of `f': f (t@(T x)) = c x t | | There are at least three possible ways to write the above code such | that it works. | | (1) Give a type signature for f | | > f :: T a -> T a | | (2) Define the class C using an equality constraint | | > class C t where | > ? type E t | > ? c :: (E t ~ e) => e -> t -> t | | (3) Define the class C using functional dependencies | | > class C t e | t -> e where | > ? c :: e -> t -> t | | But the real question is why don't I get a type for f? | | This has been tested in GHC 6.10.1 and 6.12.1. | | Thanks, | Sean | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From leather at cs.uu.nl Tue Jan 19 05:32:03 2010 From: leather at cs.uu.nl (Sean Leather) Date: Tue Jan 19 05:04:38 2010 Subject: Can't infer type (type family + "element" type) In-Reply-To: <59543203684B2244980D7E4057D5FBC10AFA4E80@DB3EX14MBXC306.europe.corp.microsoft.com> References: <3c6288ab1001180858j7d4939c3v821c18acae34d139@mail.gmail.com> <59543203684B2244980D7E4057D5FBC10AFA4E80@DB3EX14MBXC306.europe.corp.microsoft.com> Message-ID: <3c6288ab1001190232y34669658idd5007c2c2a68d30@mail.gmail.com> Done: http://hackage.haskell.org/trac/ghc/ticket/3826 Regards, Sean On Tue, Jan 19, 2010 at 11:15, Simon Peyton-Jones wrote: > Looks like a bug to me! I am currently elbows-deep in re-engineering GHC's > entire constraint generation and solving mechanism, which will, I hope, > simply solve your problem. > > But meanwhile can I ask a favour: submit a Trac report with the offending > code in reproducible form? Then I'll be sure to test the new code against > all such tickets. > > Thanks > > Simon > > | -----Original Message----- > | From: glasgow-haskell-users-bounces@haskell.org [mailto: > glasgow-haskell-users- > | bounces@haskell.org] On Behalf Of Sean Leather > | Sent: 18 January 2010 16:59 > | To: GHC Users List > | Subject: Can't infer type (type family + "element" type) > | > | Suppose I have a class C, > | > | > class C a where > | > type E a > | > c :: E a -> a -> a > | > | a datatype T, > | > | > data T a = T a > | > | and an instance of C for T > | > | > instance C (T a) where > | > type E (T a) = a > | > c x (T _) = T x > | > | I would like to write a function such as f > | > | > f t@(T x) = c x t > | > | without a type signature. Unfortunately, I can't because GHC tells me > | > | Couldn't match expected type `t' against inferred type `T (E t)' > | In the second argument of `c', namely `t' > | In the expression: c x t > | In the definition of `f': f (t@(T x)) = c x t > | > | There are at least three possible ways to write the above code such > | that it works. > | > | (1) Give a type signature for f > | > | > f :: T a -> T a > | > | (2) Define the class C using an equality constraint > | > | > class C t where > | > type E t > | > c :: (E t ~ e) => e -> t -> t > | > | (3) Define the class C using functional dependencies > | > | > class C t e | t -> e where > | > c :: e -> t -> t > | > | But the real question is why don't I get a type for f? > | > | This has been tested in GHC 6.10.1 and 6.12.1. > | > | Thanks, > | Sean > | _______________________________________________ > | 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/20100119/cb4fd3c3/attachment.html From taruti at taruti.net Tue Jan 19 22:31:13 2010 From: taruti at taruti.net (Taru Karttunen) Date: Tue Jan 19 22:03:27 2010 Subject: UTF-8 + Hsc2hs Message-ID: <1263957850-sup-4414@oz.taruti.net> GHC 6.12.1 hsc2hs seems to have an issue with compiling sources that contain certain UTF-8 charactes in the comments. It contains code like: showCChar c = ['\\', intToDigit (ord c `quot` 64), intToDigit (ord c `quot` 8 `mod` 8), intToDigit (ord c `mod` 8)] which quite obviously fails if c is a code point with a large ord value (like japanese text for example). This affects at least HsOpenSSL. - Taru Karttunen From nominolo at googlemail.com Wed Jan 20 13:47:40 2010 From: nominolo at googlemail.com (Thomas Schilling) Date: Wed Jan 20 13:20:16 2010 Subject: ghc API in platforms with no GHCi In-Reply-To: <1263749519.2544.609.camel@zezinho> References: <1263749519.2544.609.camel@zezinho> Message-ID: <916b84821001201047n252f3cf4ud347d5997d7a8cf8@mail.gmail.com> The byte code interpreter (which hlint uses) has its own dynamic linker to load binaries. I suppose the platforms that you listed this is not supported and GHCi (or more precisely the part of GHCi that requires the byte code interpreter) is not built. Specifically, the following modules are not built: DsMeta TcSplice Convert ByteCodeAsm ByteCodeFFI ByteCodeGen ByteCodeInstr ByteCodeItbls ByteCodeLink Debugger LibFFI Linker ObjLink RtClosureInspect I wonder whether TemplateHaskell is supported on those platforms, since that uses the interpreter, AFAIK. 2010/1/17 Marco T?lio Gontijo e Silva : > Hi. > > I noticed that in Debian/KFreeBSD the module ByteCodeLink is not > available, which cause the build error of haskell-hint in Debian's > buildds. > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=564136 > > This is also the case of alpha, armel, hppa, mips, powerpc and s390. ?I > haven't checked if these are the architectures without GHCi but I > suspect they are. > > Is the full ghc API available only in arches in which GHCi is available? > > Greetings. > -- > marcot > http://marcot.iaaeee.org/ > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -- Push the envelope. Watch it bend. From marcot at riseup.net Wed Jan 20 14:45:11 2010 From: marcot at riseup.net (Marco =?ISO-8859-1?Q?T=FAlio?= Gontijo e Silva) Date: Wed Jan 20 14:17:27 2010 Subject: ghc API in platforms with no GHCi In-Reply-To: <916b84821001201047n252f3cf4ud347d5997d7a8cf8@mail.gmail.com> References: <1263749519.2544.609.camel@zezinho> <916b84821001201047n252f3cf4ud347d5997d7a8cf8@mail.gmail.com> Message-ID: <1264016711.3988.32.camel@zezinho> Hi Thomas. Qua, 2010-01-20 ?s 18:47 +0000, Thomas Schilling escreveu: > The byte code interpreter (which hlint uses) has its own dynamic > linker to load binaries. I suppose the platforms that you listed this > is not supported and GHCi (or more precisely the part of GHCi that > requires the byte code interpreter) is not built. Thanks for your answer. If you're interested, I've changed hlint in Debian to be built only in i386, amd64 and sparc. Greetings. (...) -- marcot http://marcot.iaaeee.org/ From marlowsd at gmail.com Thu Jan 21 10:36:58 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Jan 21 10:09:19 2010 Subject: Adding support for CLDouble In-Reply-To: <1263076406.3967.31.camel@blackswan> References: <1263076406.3967.31.camel@blackswan> Message-ID: <4B58749A.5030709@gmail.com> On 09/01/2010 22:33, Denys Rtveliashvili wrote: > Currently ghc 6.12 does not have support for CLDouble type (and there is > an open issue on trac about it > http://hackage.haskell.org/trac/ghc/ticket/3353 ). This is quite a big job, incedentally. Apart from the x86 native code generator the changes will be fairly routine, however. > I have been trying to figure out what is necessary to add it. After > playing with the code a bit I've got a few questions... > > 1. Should there be a LDouble type, just like for CFloat and CDouble > there there are Haskell-native types Float and Double? You will need to add an LDouble# type, and some operations on it - at least conversions to/from Double#, I imagine. In Cmm, you need to add MachOps for the LDouble# operations, and the code generator needs to know about how to shuffle LDouble# values around (how much space they take on the stack and heap, for example). > 2. The ghc compiler references Float and Double in its code. When a > similar code is added for LDouble, the compiler does not get built. In > particular, 'compiler/coreSyn/CoreSyn.lhs' does not see 'LDouble' > despite I declared and exported it in 'libraries/ghc-prim/GHC/Types.hs'. > This probably makes sense in case compiler is built first. But then in > turns out to be a chicken and egg situation as to support a new type in > GHC one needs to have another GHC that already supports it. Or, perhaps, > I am missing something? GHC gets built in 2 "stages", stage 1 is built using your installed GHC, the libraries are then built using stage 1, and then stage 2 is built using stage 1 and those libraries. So if you add something to a library, it is only available in stage 2, and you need to use appropriate #ifdefs if it is necessary to use it in GHC itself (although this is generally discouraged if you can avoid it, we try to avoid adding version dependencies to the code if we can). > 3. > http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/HaskellExecution/Registers mentions that there are registers for floats and doubles. What should be done about long doubles then? Registers are not necessary, I believe, Indeed, since there are no registers that hold long doubles on x86 apart from the silly x87 register stack, I don't think it would help to add any register assignments. This means that long doubles will get passed on the stack, but that's not a big deal. Cheers, Simon From marlowsd at gmail.com Thu Jan 21 10:38:30 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Jan 21 10:10:52 2010 Subject: ghc API in platforms with no GHCi In-Reply-To: <1264016711.3988.32.camel@zezinho> References: <1263749519.2544.609.camel@zezinho> <916b84821001201047n252f3cf4ud347d5997d7a8cf8@mail.gmail.com> <1264016711.3988.32.camel@zezinho> Message-ID: <4B5874F6.8050603@gmail.com> On 20/01/2010 19:45, Marco T?lio Gontijo e Silva wrote: > Hi Thomas. > > Qua, 2010-01-20 ?s 18:47 +0000, Thomas Schilling escreveu: >> The byte code interpreter (which hlint uses) has its own dynamic >> linker to load binaries. I suppose the platforms that you listed this >> is not supported and GHCi (or more precisely the part of GHCi that >> requires the byte code interpreter) is not built. > > Thanks for your answer. If you're interested, I've changed hlint in > Debian to be built only in i386, amd64 and sparc. It may be that GHCi would work on some of those other architectures, as long as they use ELF. Cheers, Simon From daniel.gustafsson at gmail.com Thu Jan 21 13:19:34 2010 From: daniel.gustafsson at gmail.com (Daniel Gustafsson) Date: Thu Jan 21 12:51:43 2010 Subject: Scriptable error messages Message-ID: <800e39931001211019u49cd576cia88fa009efc8624e@mail.gmail.com> Hello Me and a fellow student are taking a course named Frontiers of Programming Languages, and in this course we should do a project with something. A while ago we were at a presentation of Feldspar, a Embedded Domain Specific Language, and one of the negative points of using haskell was that the error messages could be cryptic due to the various ways it was implemented. So we are now looking into the possibility of adding your own error messages to GHC as our project. We have about 8 weeks to implement, either all or some proof of concept. As such we are looking for comments, ideas and suggestions. Is this doable in GHC?, or what is needed. Thanks Daniel Gustafsson Simon Edwardsson Chalmers University of Technology (Gothenburg, Sweden) From leather at cs.uu.nl Thu Jan 21 14:11:05 2010 From: leather at cs.uu.nl (Sean Leather) Date: Thu Jan 21 13:43:33 2010 Subject: Scriptable error messages In-Reply-To: <800e39931001211019u49cd576cia88fa009efc8624e@mail.gmail.com> References: <800e39931001211019u49cd576cia88fa009efc8624e@mail.gmail.com> Message-ID: <3c6288ab1001211111i313ae8adh155dc2ec20fb9528@mail.gmail.com> > So we are now looking into the possibility of adding your own error > messages to GHC as our project. We have about 8 weeks to implement, > either all or some proof of concept. As such we are looking for > comments, ideas and suggestions. Is this doable in GHC?, or what is > needed. > For related work, see the publications of Bastiaan Heeren, esp. his PhD thesis. Search the following page for "error:" http://people.cs.uu.nl/bastiaan/ Regards, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100121/14b3fd78/attachment.html From simonpj at microsoft.com Fri Jan 22 07:13:11 2010 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Jan 22 06:45:39 2010 Subject: Scriptable error messages In-Reply-To: <800e39931001211019u49cd576cia88fa009efc8624e@mail.gmail.com> References: <800e39931001211019u49cd576cia88fa009efc8624e@mail.gmail.com> Message-ID: <59543203684B2244980D7E4057D5FBC10AFC8F2F@DB3EX14MBXC306.europe.corp.microsoft.com> GHC doesn't have any way to let you "plug in" new error messages. I imagine you mean in the type inference engine? Can you characterise more precisely what you want, perhaps by example. I do urge you to read the Utrecht work; they have done tremendous stuff on user-defined type rules and associated user-defined error messages. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Daniel Gustafsson | Sent: 21 January 2010 18:20 | To: glasgow-haskell-users@haskell.org | Subject: Scriptable error messages | | Hello | | Me and a fellow student are taking a course named Frontiers of | Programming Languages, and in this course we should do a project with | something. A while ago we were at a presentation of Feldspar, a | Embedded Domain Specific Language, and one of the negative points of | using haskell was that the error messages could be cryptic due to the | various ways it was implemented. | | So we are now looking into the possibility of adding your own error | messages to GHC as our project. We have about 8 weeks to implement, | either all or some proof of concept. As such we are looking for | comments, ideas and suggestions. Is this doable in GHC?, or what is | needed. | | Thanks | | Daniel Gustafsson | Simon Edwardsson | Chalmers University of Technology (Gothenburg, Sweden) | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From robert.van.herk at philips.com Fri Jan 22 07:31:05 2010 From: robert.van.herk at philips.com (Herk, Robert van) Date: Fri Jan 22 07:07:36 2010 Subject: Scriptable error messages In-Reply-To: <59543203684B2244980D7E4057D5FBC10AFC8F2F@DB3EX14MBXC306.europe.corp.microsoft.com> References: <800e39931001211019u49cd576cia88fa009efc8624e@mail.gmail.com>, <59543203684B2244980D7E4057D5FBC10AFC8F2F@DB3EX14MBXC306.europe.corp.microsoft.com> Message-ID: <35AD6BF061932E4291356D05B7078057402976B0C3@NLCLUEXM04.connect1.local> Dear Daniel, The Utrecht work can be found at: http://www.cs.uu.nl/wiki/bin/view/Helium/WebHome. Helium is a Haskell subset that strives to produce more understandable error messages. The theory behind it can be found in http://people.cs.uu.nl/bastiaan/phdthesis/index.html. Regards, Robert ________________________________________ From: glasgow-haskell-users-bounces@haskell.org [glasgow-haskell-users-bounces@haskell.org] On Behalf Of Simon Peyton-Jones [simonpj@microsoft.com] Sent: Friday, January 22, 2010 1:13 PM To: Daniel Gustafsson; glasgow-haskell-users@haskell.org Subject: RE: Scriptable error messages GHC doesn't have any way to let you "plug in" new error messages. I imagine you mean in the type inference engine? Can you characterise more precisely what you want, perhaps by example. I do urge you to read the Utrecht work; they have done tremendous stuff on user-defined type rules and associated user-defined error messages. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Daniel Gustafsson | Sent: 21 January 2010 18:20 | To: glasgow-haskell-users@haskell.org | Subject: Scriptable error messages | | Hello | | Me and a fellow student are taking a course named Frontiers of | Programming Languages, and in this course we should do a project with | something. A while ago we were at a presentation of Feldspar, a | Embedded Domain Specific Language, and one of the negative points of | using haskell was that the error messages could be cryptic due to the | various ways it was implemented. | | So we are now looking into the possibility of adding your own error | messages to GHC as our project. We have about 8 weeks to implement, | either all or some proof of concept. As such we are looking for | comments, ideas and suggestions. Is this doable in GHC?, or what is | needed. | | Thanks | | Daniel Gustafsson | Simon Edwardsson | Chalmers University of Technology (Gothenburg, Sweden) | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. From stefan at cs.uu.nl Fri Jan 22 11:57:43 2010 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Fri Jan 22 11:29:49 2010 Subject: Scriptable error messages In-Reply-To: <800e39931001211019u49cd576cia88fa009efc8624e@mail.gmail.com> References: <800e39931001211019u49cd576cia88fa009efc8624e@mail.gmail.com> Message-ID: <5F8B6AC1-075A-4616-8ECF-C2E217578C84@cs.uu.nl> Daniel, > A while ago we were at a presentation of Feldspar, a > Embedded Domain Specific Language, and one of the negative points of > using haskell was that the error messages could be cryptic due to the > various ways it was implemented. Incidentally, but actually by no means surprisingly, this very same issue. amongst others, was once more brought up by Jeremy Siek in his invited talk at PEPM 2010, just a few days ago: http://ecee.colorado.edu/~siek/pepm-keynote.pdf . Cheers, Stefan From fw at deneb.enyo.de Sun Jan 24 07:10:11 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun Jan 24 06:42:14 2010 Subject: Trying to build from the darcs repository Message-ID: <87vderr9ek.fsf@mid.deneb.enyo.de> How much memory does GHC need to build on amd64 GNU/Linux? I'm trying to build from the darcs repository, and this command "inplace/bin/ghc-stage1" -H32m -O -package-name terminfo-0.3.1.1 -hide-all-packages -i ilibraries/terminfo/. --ilibraries/terminfo/dist-install/build -ilibraries/terminfo/dist-install/build/autogen -Ilibraries/terminfo/dist-install/build -Ilibraries/terminfo/dist-install/build/autogen --Ilibraries/terminfo/. optP-include -optPlibraries/terminfo/dist-install/build/autogen/cabal_macros.h -package base-4.2.0.0 -package extensible-exceptions-0.1.1.1 -split-objs -Wall -XForeignFunctionInterface -XDeriveDataTypeable -XEmptyDataDecls -XScopedTypeVariables -XFlexibleInstances -O2 -XGenerics -fno-warn-deprecated-flags -odir -libraries/terminfo/dist-install/build -hidir -libraries/terminfo/dist-install/build -stubdir -libraries/terminfo/dist-install/build -hisuf hi -osuf o -hcsuf hc --c libraries/terminfo/./System/Console/Terminfo/Effects.hs -o -libraries/terminfo/dist-install/build/System/Console/Terminfo/Effects.o needs more than 3.5 GB of RAM. Or is this some sort of miscompilation problem? (I'm trying to bootstrap with GHC 6.12.1, but saw this with GHC 6.8 as well.) The start of the context is this: [Remove an out-of-date comment Ian Lynagh **20100122130853] [fix build on Windows Simon Marlow **20100122121016 Ignore-this: cd690a8eff71ca4f87fe67a41a20f493 ] [fix warning on Windows Simon Marlow **20100122120328 Ignore-this: 507a91e356a667dcecf8bec621fd2b95 ] From marcot at riseup.net Sun Jan 24 08:51:55 2010 From: marcot at riseup.net (Marco =?ISO-8859-1?Q?T=FAlio?= Gontijo e Silva) Date: Sun Jan 24 08:24:00 2010 Subject: Trying to build from the darcs repository In-Reply-To: <87vderr9ek.fsf@mid.deneb.enyo.de> References: <87vderr9ek.fsf@mid.deneb.enyo.de> Message-ID: <1264341115.13345.89.camel@zezinho> Hi Florian. Dom, 2010-01-24 ?s 13:10 +0100, Florian Weimer escreveu: > How much memory does GHC need to build on amd64 GNU/Linux? I'm trying > to build from the darcs repository, and this command > > "inplace/bin/ghc-stage1" -H32m -O -package-name terminfo-0.3.1.1 > -hide-all-packages -i ilibraries/terminfo/. > --ilibraries/terminfo/dist-install/build > -ilibraries/terminfo/dist-install/build/autogen > -Ilibraries/terminfo/dist-install/build > -Ilibraries/terminfo/dist-install/build/autogen > --Ilibraries/terminfo/. optP-include > -optPlibraries/terminfo/dist-install/build/autogen/cabal_macros.h > -package base-4.2.0.0 -package extensible-exceptions-0.1.1.1 > -split-objs -Wall -XForeignFunctionInterface -XDeriveDataTypeable > -XEmptyDataDecls -XScopedTypeVariables -XFlexibleInstances -O2 > -XGenerics -fno-warn-deprecated-flags -odir > -libraries/terminfo/dist-install/build -hidir > -libraries/terminfo/dist-install/build -stubdir > -libraries/terminfo/dist-install/build -hisuf hi -osuf o -hcsuf hc > --c libraries/terminfo/./System/Console/Terminfo/Effects.hs -o > -libraries/terminfo/dist-install/build/System/Console/Terminfo/Effects.o > > needs more than 3.5 GB of RAM. I guess this is related to http://hackage.haskell.org/trac/ghc/ticket/3831 . Greetings. (...) -- marcot http://marcot.iaaeee.org/ From marlowsd at gmail.com Mon Jan 25 07:22:28 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Jan 25 06:54:34 2010 Subject: Trying to build from the darcs repository In-Reply-To: <1264341115.13345.89.camel@zezinho> References: <87vderr9ek.fsf@mid.deneb.enyo.de> <1264341115.13345.89.camel@zezinho> Message-ID: <4B5D8D04.4020900@gmail.com> On 24/01/2010 13:51, Marco T?lio Gontijo e Silva wrote: > Hi Florian. > > Dom, 2010-01-24 ?s 13:10 +0100, Florian Weimer escreveu: >> How much memory does GHC need to build on amd64 GNU/Linux? I'm trying >> to build from the darcs repository, and this command >> >> "inplace/bin/ghc-stage1" -H32m -O -package-name terminfo-0.3.1.1 >> -hide-all-packages -i ilibraries/terminfo/. >> --ilibraries/terminfo/dist-install/build >> -ilibraries/terminfo/dist-install/build/autogen >> -Ilibraries/terminfo/dist-install/build >> -Ilibraries/terminfo/dist-install/build/autogen >> --Ilibraries/terminfo/. optP-include >> -optPlibraries/terminfo/dist-install/build/autogen/cabal_macros.h >> -package base-4.2.0.0 -package extensible-exceptions-0.1.1.1 >> -split-objs -Wall -XForeignFunctionInterface -XDeriveDataTypeable >> -XEmptyDataDecls -XScopedTypeVariables -XFlexibleInstances -O2 >> -XGenerics -fno-warn-deprecated-flags -odir >> -libraries/terminfo/dist-install/build -hidir >> -libraries/terminfo/dist-install/build -stubdir >> -libraries/terminfo/dist-install/build -hisuf hi -osuf o -hcsuf hc >> --c libraries/terminfo/./System/Console/Terminfo/Effects.hs -o >> -libraries/terminfo/dist-install/build/System/Console/Terminfo/Effects.o >> >> needs more than 3.5 GB of RAM. > > I guess this is related to > http://hackage.haskell.org/trac/ghc/ticket/3831 . For now, I think you want to use -O rather than -O2 for building the libraries (GhcLibHcOpts in mk/build.mk) until we can figure out what's going on in #3831. Cheers, Simon From twhitehead at gmail.com Mon Jan 25 14:03:45 2010 From: twhitehead at gmail.com (Tyson Whitehead) Date: Mon Jan 25 13:35:44 2010 Subject: Question regarding the GHC users manual Message-ID: <201001251403.45267.twhitehead@gmail.com> Hi all, Just wondering if there could be a typo in section 7.7.2.1 of the GHC manual (type family declarations) http://www.haskell.org/ghc/docs/latest/html/users_guide/type-families.html Specifically, it says type family F a b :: * -> * -- F's arity is 2, -- although its overall kind is * -> * -> * -> * along with F Char [Int] -- OK! Kind: * -> * F Char [Int] Bool -- OK! Kind: * F IO Bool -- WRONG: kind mismatch in the first argument F Bool -- WRONG: unsaturated application and I'm wondering about the overall kind. Shouldn't that be * -> * -> *, or am I not understanding something? Thanks! -Tyson From batterseapower at hotmail.com Mon Jan 25 14:34:14 2010 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Mon Jan 25 14:06:10 2010 Subject: Question regarding the GHC users manual In-Reply-To: <201001251403.45267.twhitehead@gmail.com> References: <201001251403.45267.twhitehead@gmail.com> Message-ID: <9d4d38821001251134p553d7223q9b8e06432dc2fa1b@mail.gmail.com> Hi Tyson, I don't think this is a bug. > type family F a b :: * -> * ? -- F's arity is 2, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?-- although its overall kind is * -> * -> * -> * > F Char [Int] ? ? ? -- OK! ?Kind: * -> * Char :: * [Int] :: * So we can "fill" in the first two * in the kind * -> * -> * -> * to get * -> *, as reported. > F Char [Int] Bool ?-- OK! ?Kind: * Char :: * [Int] :: * Bool :: * As before, except that we can now fill in another * to get *. > F IO Bool ? ? ? ? ?-- WRONG: kind mismatch in the first argument IO :: * -> * Bool :: * Uh-oh! F has kind: * -> (* -> (* -> *)) And we are trying to do the application: F IO But IO :: * -> * /= * (the kind on the left of the arrow)! So we get a kind error. > F Bool ? ? ? ? ? ? -- WRONG: unsaturated application This is disallowed by the rules of type families. If unsaturated applications were allowed it would be well-kinded though, since Bool :: *. > and I'm wondering about the overall kind. ?Shouldn't that be * -> * -> *, or > am I not understanding something? I'm not sure what you think has gone wrong. * -> * -> * is the kind of something with two type arguments, but F clearly has 3 (two indexed ones, one parametric one). The inference rule you need to think of is something like: t1 :: k1 -> k2 t2 :: k1 -------------- t1 t2 :: k2 With axioms like (glossing over issues of saturation): ------------ Bool :: * --------------- IO :: * -> * -------------------------- F :: * -> * -> * -> * GHC's kind system is actually even more complicated than this due to subkinding, but you usually don't have to worry about that. Cheers, Max From niklas.broberg at gmail.com Mon Jan 25 14:46:09 2010 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Mon Jan 25 14:18:05 2010 Subject: Question regarding the GHC users manual In-Reply-To: <201001251403.45267.twhitehead@gmail.com> References: <201001251403.45267.twhitehead@gmail.com> Message-ID: > type family F a b :: * -> * ? -- F's arity is 2, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?-- although its overall kind is * -> * -> * -> * I believe what you're missing is that with the definition F a b :: * -> *, F needs three arguments (of kind *) in order to become kind *. If F a b :: * -> * as stated, then F a :: * -> * -> * and F :: * -> * -> * -> *, just like reported. Cheers, /Niklas From twhitehead at gmail.com Mon Jan 25 15:43:42 2010 From: twhitehead at gmail.com (Tyson Whitehead) Date: Mon Jan 25 15:15:50 2010 Subject: Question regarding the GHC users manual In-Reply-To: References: <201001251403.45267.twhitehead@gmail.com> Message-ID: <201001251543.48684.twhitehead@gmail.com> Hi Max and Niklas, Thank you both for your answers. I get it now. I didn't read carefully enough to note that the explicit type on F a b was the type of F and the type of F (although, in retrospect, this last interpretation wouldn't have worked as we would have need at least * -> * -> *). Thanks again. Cheers! -Tyson -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100125/d11118bc/attachment.bin From robgreayer at gmail.com Mon Jan 25 18:26:51 2010 From: robgreayer at gmail.com (Robert Greayer) Date: Mon Jan 25 17:58:47 2010 Subject: Splicing types.. should this work? Message-ID: <4ec472cb1001251526j4baf0ee8i1e7c9e1924240dea@mail.gmail.com> Now that type-splicing works in TH, and TH has type-family support, I was wondering if the following example should compile (with 6.12.1): > {-# LANGUAGE TemplateHaskell, MultiParamTypeClasses, TypeFamilies, > FlexibleInstances, OverlappingInstances #-} > module Sample where > import Control.Monad > import Language.Haskell.TH > class Foo a where > type FooType a > createInstance :: Q Type -> Q Dec > createInstance t = instanceD (return []) > (conT ''Foo `appT` t) [ > tySynInstD ''FooType [t] (conT ''String) > ] > createInstance' :: Q Type -> Q Dec > createInstance' t = liftM head [d| > instance Foo $t where > type FooType $t = String|] the function 'createInstance' compiles without a problem, but it's (near) equivalent written using TH quotations + splices fails with the error: Sample.lhs:22:10: Type indexes must match class instance head Found `t_aMn' but expected `t_aMl' In the associated type instance for `FooType' In the instance declaration for `Foo $t' In the Template Haskell quotation [d| instance Foo $t where type instance FooType $t = String |] The compiler seems to not be able to determine that the type spliced in the class instance head will match the type spliced in the type instance. The first version works fine for my purposes, but was curious whether the failure of the 2nd was a bug or a feature. Thanks, Rob From jpm at cs.uu.nl Tue Jan 26 05:47:11 2010 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Tue Jan 26 05:19:26 2010 Subject: GHC core plugins Message-ID: <52f14b211001260247n1767203fv54737acf5f44db4e@mail.gmail.com> Hello all, What's the current status of GHC plugins [1] in HEAD? Can I use them? If not, what's the easiest way to add another core-to-core pass to the compiler? Thanks, Pedro [1] http://hackage.haskell.org/trac/ghc/wiki/Plugins -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100126/1b9685f2/attachment-0001.html From batterseapower at hotmail.com Tue Jan 26 13:37:50 2010 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Tue Jan 26 13:09:50 2010 Subject: GHC core plugins In-Reply-To: <52f14b211001260247n1767203fv54737acf5f44db4e@mail.gmail.com> References: <52f14b211001260247n1767203fv54737acf5f44db4e@mail.gmail.com> Message-ID: <9d4d38821001261037r1ee6e1a9n94c2d7ea20296c75@mail.gmail.com> Hi Jos?, The patch implementing GHC plugins is with Simon PJ and awaiting merge into GHC (and has been for some time - he's a busy guy and its a big patch). However, even once it's merged some more work will need to be done to make sure that it plays nicely with the shared library support (now that has been implemented on all major platforms). In short, the easiest way to add a pass to the compiler right now is to download GHC and build it yourself (http://hackage.haskell.org/trac/ghc/wiki/Building). Sorry! All the best, Max 2010/1/26 Jos? Pedro Magalh?es : > Hello all, > > What's the current status of GHC plugins [1] in HEAD? Can I use them? If > not, what's the easiest way to add another core-to-core pass to the > compiler? > > > Thanks, > Pedro > > [1] http://hackage.haskell.org/trac/ghc/wiki/Plugins > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > From simonpj at microsoft.com Tue Jan 26 20:07:56 2010 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Jan 26 19:37:48 2010 Subject: GHC core plugins In-Reply-To: <9d4d38821001261037r1ee6e1a9n94c2d7ea20296c75@mail.gmail.com> References: <52f14b211001260247n1767203fv54737acf5f44db4e@mail.gmail.com> <9d4d38821001261037r1ee6e1a9n94c2d7ea20296c75@mail.gmail.com> Message-ID: <59543203684B2244980D7E4057D5FBC10AFCAE88@DB3EX14MBXC306.europe.corp.microsoft.com> Yes, I apologise for being slow about this. A good idea would be to create a Trac ticket, so that people can register interest in having the patch by adding themselves to the cc list. The more people that want it, the higher up my priority list... Better still if everyone adds a comment to the ticket to explain what their pass is like, and why they want the plugin feature. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell- | users-bounces@haskell.org] On Behalf Of Max Bolingbroke | Sent: 26 January 2010 18:38 | To: Jos? Pedro Magalh?es | Cc: GHC users | Subject: Re: GHC core plugins | | Hi Jos?, | | The patch implementing GHC plugins is with Simon PJ and awaiting merge | into GHC (and has been for some time - he's a busy guy and its a big | patch). However, even once it's merged some more work will need to be | done to make sure that it plays nicely with the shared library support | (now that has been implemented on all major platforms). | | In short, the easiest way to add a pass to the compiler right now is | to download GHC and build it yourself | (http://hackage.haskell.org/trac/ghc/wiki/Building). Sorry! | | All the best, | Max | | 2010/1/26 Jos? Pedro Magalh?es : | > Hello all, | > | > What's the current status of GHC plugins [1] in HEAD? Can I use them? If | > not, what's the easiest way to add another core-to-core pass to the | > compiler? | > | > | > Thanks, | > Pedro | > | > [1] http://hackage.haskell.org/trac/ghc/wiki/Plugins | > | > _______________________________________________ | > Glasgow-haskell-users mailing list | > Glasgow-haskell-users@haskell.org | > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | > | > | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From vw at volker-wysk.de Tue Jan 26 21:48:47 2010 From: vw at volker-wysk.de (Volker Wysk) Date: Tue Jan 26 21:22:10 2010 Subject: No more ExitException? Message-ID: <20100127034847.6e533eae.vw@volker-wysk.de> Hello I'm porting my HsShellScript library from GHC-6.8 to GHC-6.10. I'm catching an ExitException in the old version. The only occurence of ExitException in the GHC 6.10 libraries is in Control.OldException. So how is this done in GHC 6.10+ ? What replaces the old ExitException? Cheers, Volker -- Volker Wysk From vw at volker-wysk.de Wed Jan 27 00:19:44 2010 From: vw at volker-wysk.de (Volker Wysk) Date: Tue Jan 26 23:53:08 2010 Subject: No more ExitException? <- documentation bug In-Reply-To: <20100127034847.6e533eae.vw@volker-wysk.de> References: <20100127034847.6e533eae.vw@volker-wysk.de> Message-ID: <20100127061944.78dfaed3.vw@volker-wysk.de> On Wed, 27 Jan 2010 03:48:47 +0100 Volker Wysk wrote: > I'm porting my HsShellScript library from GHC-6.8 to GHC-6.10. I'm catching an ExitException in the old version. > > The only occurence of ExitException in the GHC 6.10 libraries is in Control.OldException. So how is this done in GHC 6.10+ ? What replaces the old ExitException? I'm answering my own question: exitWith throws the ExitCode when it is called. This leads to the shutdown of the program, if it isn't caught. Just like ExitException. This isn't documented. Cheers, Volker -- Volker Wysk From bulat.ziganshin at gmail.com Wed Jan 27 04:43:13 2010 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Jan 27 04:19:42 2010 Subject: No more ExitException? <- documentation bug In-Reply-To: <20100127061944.78dfaed3.vw@volker-wysk.de> References: <20100127034847.6e533eae.vw@volker-wysk.de> <20100127061944.78dfaed3.vw@volker-wysk.de> Message-ID: <519858415.20100127124313@gmail.com> Hello Volker, Wednesday, January 27, 2010, 8:19:44 AM, you wrote: > exitWith throws the ExitCode when it is called. This leads to the > shutdown of the program, if it isn't caught. Just like ExitException. > This isn't documented. i've googled for "exitWith throws the ExitCode" and it pointed me to the exitWith docs: "Computation exitWith code throws ExitException code." -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From jpm at cs.uu.nl Wed Jan 27 05:44:00 2010 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Wed Jan 27 05:16:12 2010 Subject: GHC core plugins In-Reply-To: <59543203684B2244980D7E4057D5FBC10AFCAE88@DB3EX14MBXC306.europe.corp.microsoft.com> References: <52f14b211001260247n1767203fv54737acf5f44db4e@mail.gmail.com> <9d4d38821001261037r1ee6e1a9n94c2d7ea20296c75@mail.gmail.com> <59543203684B2244980D7E4057D5FBC10AFCAE88@DB3EX14MBXC306.europe.corp.microsoft.com> Message-ID: <52f14b211001270244qd532b1l6c57b94b71d559c6@mail.gmail.com> Alright, ticket created: http://hackage.haskell.org/trac/ghc/ticket/3843 In any case, for now I am willing to hard-code a new core-to-core pass on the compiler. Any pointers for where I have to look at? Thanks, Pedro 2010/1/27 Simon Peyton-Jones > Yes, I apologise for being slow about this. A good idea would be to create > a Trac ticket, so that people can register interest in having the patch by > adding themselves to the cc list. The more people that want it, the higher > up my priority list... > > Better still if everyone adds a comment to the ticket to explain what their > pass is like, and why they want the plugin feature. > > Simon > > | -----Original Message----- > | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell- > | users-bounces@haskell.org] On Behalf Of Max Bolingbroke > | Sent: 26 January 2010 18:38 > | To: Jos? Pedro Magalh?es > | Cc: GHC users > | Subject: Re: GHC core plugins > | > | Hi Jos?, > | > | The patch implementing GHC plugins is with Simon PJ and awaiting merge > | into GHC (and has been for some time - he's a busy guy and its a big > | patch). However, even once it's merged some more work will need to be > | done to make sure that it plays nicely with the shared library support > | (now that has been implemented on all major platforms). > | > | In short, the easiest way to add a pass to the compiler right now is > | to download GHC and build it yourself > | (http://hackage.haskell.org/trac/ghc/wiki/Building). Sorry! > | > | All the best, > | Max > | > | 2010/1/26 Jos? Pedro Magalh?es : > | > Hello all, > | > > | > What's the current status of GHC plugins [1] in HEAD? Can I use them? > If > | > not, what's the easiest way to add another core-to-core pass to the > | > compiler? > | > > | > > | > Thanks, > | > Pedro > | > > | > [1] http://hackage.haskell.org/trac/ghc/wiki/Plugins > | > > | > _______________________________________________ > | > Glasgow-haskell-users mailing list > | > Glasgow-haskell-users@haskell.org > | > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > | > > | > > | _______________________________________________ > | 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/20100127/1a7e7236/attachment.html From batterseapower at hotmail.com Wed Jan 27 06:31:39 2010 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Wed Jan 27 06:03:34 2010 Subject: GHC core plugins In-Reply-To: <9d4d38821001270331v7b73f6d6gaaa33ae57e0ddcfe@mail.gmail.com> References: <52f14b211001260247n1767203fv54737acf5f44db4e@mail.gmail.com> <9d4d38821001261037r1ee6e1a9n94c2d7ea20296c75@mail.gmail.com> <59543203684B2244980D7E4057D5FBC10AFCAE88@DB3EX14MBXC306.europe.corp.microsoft.com> <52f14b211001270244qd532b1l6c57b94b71d559c6@mail.gmail.com> <9d4d38821001270331v7b73f6d6gaaa33ae57e0ddcfe@mail.gmail.com> Message-ID: <9d4d38821001270331k39ef40bcj4714b693d308a450@mail.gmail.com> 2010/1/27 Jos? Pedro Magalh?es : > Alright, ticket created: http://hackage.haskell.org/trac/ghc/ticket/3843 > > In any case, for now I am willing to hard-code a new core-to-core pass on > the compiler. Any pointers for where I have to look at? I recommend you look at compiler/simplCore/CSE.lhs. It is a simple example of a core-to-core pass. However, in short you'll need to: 1) Create a function which implements your core to core pass, of a type such as [CoreBind] -> [CoreBind] ?*) If that function lives in a new module, edit ghc.cabal.in to tell the build system about the module 2) Add a constructor to the CoreToDo data type in compiler/simplCore/CoreMonad.lhs 3) Add a case for it to the coreDumpFlag and Outputable instance 4) Add that pass to the list returned by getCoreToDo in CoreMonad. The order of the list is the order the passes will be run in. ?*) If you want the pass to be under the control of a new flag, you'll need to add a new dynflag - add a constructor to the DOpt data type in compiler/main/DynFlags.lhs, and add something to build that constructor to one of the lists that get fed to the command line handling code in the same module. It should be fairly obvious how to do this. 5) Add a handler for the new constructor to compiler/simplCore/SimplCore.lhs, in the doCorePass function which calls into the core pass function you wrote Hope that helps, Max From twhitehead at gmail.com Wed Jan 27 10:30:22 2010 From: twhitehead at gmail.com (Tyson Whitehead) Date: Wed Jan 27 10:02:22 2010 Subject: GHC core plugins In-Reply-To: <52f14b211001270244qd532b1l6c57b94b71d559c6@mail.gmail.com> References: <52f14b211001260247n1767203fv54737acf5f44db4e@mail.gmail.com> <59543203684B2244980D7E4057D5FBC10AFCAE88@DB3EX14MBXC306.europe.corp.microsoft.com> <52f14b211001270244qd532b1l6c57b94b71d559c6@mail.gmail.com> Message-ID: <201001271030.28406.twhitehead@gmail.com> On January 27, 2010 05:44:00 Jos? Pedro Magalh?es wrote: > Alright, ticket created: http://hackage.haskell.org/trac/ghc/ticket/3843 > > In any case, for now I am willing to hard-code a new core-to-core pass on > the compiler. Any pointers for where I have to look at? Just wondering a couple of things about core -> core plugins. Is the second use case mentioned by pumpkingod there (tracking which rewrite rules are firing and when) actually possible using a core -> core plugin? (it would be great to have this information fed into some sort of emacs plugin where one could drill down on specific functions to see what is happening) Also, is Hoopl expected to be used on core -> core plugins, and, if so, is the infrastructure in place for this? Thanks! -Tyson -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100127/4e6426c1/attachment-0001.bin From pumpkingod at gmail.com Wed Jan 27 10:37:19 2010 From: pumpkingod at gmail.com (Daniel Peebles) Date: Wed Jan 27 10:09:09 2010 Subject: GHC core plugins In-Reply-To: <201001271030.28406.twhitehead@gmail.com> References: <52f14b211001260247n1767203fv54737acf5f44db4e@mail.gmail.com> <59543203684B2244980D7E4057D5FBC10AFCAE88@DB3EX14MBXC306.europe.corp.microsoft.com> <52f14b211001270244qd532b1l6c57b94b71d559c6@mail.gmail.com> <201001271030.28406.twhitehead@gmail.com> Message-ID: I hope it'll be possible :) I heard a general overview of the plugins infrastructure a few months ago and it sounded like what I'd need, but I was unable to find a very detailed account of how it works and what specific information is available to plugins, so maybe I'm just dreaming. 2010/1/27 Tyson Whitehead > On January 27, 2010 05:44:00 Jos? Pedro Magalh?es wrote: > > Alright, ticket created: http://hackage.haskell.org/trac/ghc/ticket/3843 > > > > In any case, for now I am willing to hard-code a new core-to-core pass on > > the compiler. Any pointers for where I have to look at? > > Just wondering a couple of things about core -> core plugins. > > Is the second use case mentioned by pumpkingod there (tracking which > rewrite > rules are firing and when) actually possible using a core -> core plugin? > > (it would be great to have this information fed into some sort of emacs > plugin > where one could drill down on specific functions to see what is happening) > > Also, is Hoopl expected to be used on core -> core plugins, and, if so, is > the > infrastructure in place for this? > > Thanks! -Tyson > > _______________________________________________ > 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/20100127/51b15c61/attachment.html From simonpj at microsoft.com Wed Jan 27 10:53:33 2010 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Jan 27 10:24:01 2010 Subject: GHC core plugins In-Reply-To: <201001271030.28406.twhitehead@gmail.com> References: <52f14b211001260247n1767203fv54737acf5f44db4e@mail.gmail.com> <59543203684B2244980D7E4057D5FBC10AFCAE88@DB3EX14MBXC306.europe.corp.microsoft.com> <52f14b211001270244qd532b1l6c57b94b71d559c6@mail.gmail.com> <201001271030.28406.twhitehead@gmail.com> Message-ID: <59543203684B2244980D7E4057D5FBC10AFCB683@DB3EX14MBXC306.europe.corp.microsoft.com> | Also, is Hoopl expected to be used on core -> core plugins, and, if so, is | the | infrastructure in place for this? no, Hoopl works on imperative control flow graphs, the C-- part of the back end, not on Core. Simon From as at nijoruj.org Wed Jan 27 11:26:51 2010 From: as at nijoruj.org (austin s) Date: Wed Jan 27 10:58:42 2010 Subject: GHC core plugins In-Reply-To: References: <52f14b211001260247n1767203fv54737acf5f44db4e@mail.gmail.com> <59543203684B2244980D7E4057D5FBC10AFCAE88@DB3EX14MBXC306.europe.corp.microsoft.com> <52f14b211001270244qd532b1l6c57b94b71d559c6@mail.gmail.com> <201001271030.28406.twhitehead@gmail.com> <59543203684B2244980D7E4057D5FBC10AFCB683@DB3EX14MBXC306.europe.corp.microsoft.com> Message-ID: On Wed, Jan 27, 2010 at 10:24 AM, austin s wrote: > 2010/1/27 Simon Peyton-Jones : >> | Also, is Hoopl expected to be used on core -> core plugins, and, if so, is >> | the >> | infrastructure in place for this? >> >> no, Hoopl works on imperative control flow graphs, the C-- part of the back end, not on Core. >> >> Simon >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > > Quick Question, even if it is OT: Is the Hoopl code available anywhere? > > -- > - Austin > Whoops, forgot to add g-h-u to the to: field. ;) -- - Austin From jakewheatmail at googlemail.com Wed Jan 27 15:34:29 2010 From: jakewheatmail at googlemail.com (Jake Wheat) Date: Wed Jan 27 15:06:20 2010 Subject: bug in template haskell (with recursion?) Message-ID: <4b5b53361001271234v46184ed2v3bcdc89cc181051c@mail.gmail.com> Hello All, I'm trying to write a splice to make HList type signatures a bit more concise, I don't know whether this is a good idea or not. I wrote a small function to do '[(Type,Type)] -> Q Type' for this, and got the following from GHC. Should I add this to the bug tracker? Details: THBug1.hs: {-# LANGUAGE TemplateHaskell #-} module THBug1 where import Data.HList import Language.Haskell.TH mhlt :: [(Type,Type)] -> Q Type mhlt x = [t| Record $(foldThing x)|] where foldThing ((f,t):xs) = [t|HCons (LVPair (Proxy $f) $t) $(foldThing xs)|] foldThing [] = [t|HNil|] ---- $ ghc -c THBug1.hs THBug1.hs:12:61: GHC internal error: `foldThing' is not in scope during type checking, but it passed the renamer tcg_type_env of environment: [] In the expression: foldThing xs In the Template Haskell quotation [t| HCons (LVPair (Proxy $f) $t) $(foldThing xs) |] In the expression: [t| HCons (LVPair (Proxy $f) $t) $(foldThing xs) |] I'm using GHC 6.12.1 from debian experimental: $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.12.1 $ ghc-pkg list |grep template template-haskell-2.4.0.0 To get HList to install with GHC 6.12, I downloaded the latest version from http://old-darcs.well-typed.com/HList/ and altered it slightly, updated package here: http://launchpad.net/hssqlppp/prealpha/environment/+download/HList-0.2.tar.gz the changes I made are: diff -rN old-HList/Data/HList/GhcSyntax.hs new-HList/Data/HList/GhcSyntax.hs 2c2 < {-# LANGUAGE FlexibleContexts #-} --- > {-# LANGUAGE FlexibleContexts, TypeOperators #-} diff -rN old-HList/Data/HList/Label2.hs new-HList/Data/HList/Label2.hs 1c1,2 < {-# LANGUAGE FlexibleInstances, MultiParamTypeClasses, UndecidableInstances, EmptyDataDecls #-} --- > {-# LANGUAGE FlexibleInstances, MultiParamTypeClasses, UndecidableInstances, EmptyDataDecls, > ExistentialQuantification #-} 36c37 < data HNat x => Label x ns desc -- labels are exclusively type-level entities --- > data Label x ns desc = HNat x => Label x ns desc -- labels are exclusively type-level entities diff -rN old-HList/Data/HList/Label3.hs new-HList/Data/HList/Label3.hs 1c1,2 < {-# LANGUAGE FlexibleInstances, MultiParamTypeClasses, UndecidableInstances, EmptyDataDecls #-} --- > {-# LANGUAGE FlexibleInstances, MultiParamTypeClasses, UndecidableInstances, EmptyDataDecls, > ExistentialQuantification #-} 37c38 < data HNat x => Label x ns desc -- labels are exclusively type-level entities --- > data Label x ns desc = HNat x => Label x ns desc -- labels are exclusively type-level entities (If it's not obvious, I have no idea what I'm doing..., but my small amount of code which uses HList worked fine with this altered package.) Thanks, Jake Wheat From vw at volker-wysk.de Thu Jan 28 02:32:57 2010 From: vw at volker-wysk.de (Volker Wysk) Date: Thu Jan 28 02:06:21 2010 Subject: Fw: Re: Re[2]: No more ExitException? <- documentation bug Message-ID: <20100128083257.adb53f74.vw@volker-wysk.de> The following message went to Bulat Ziganshin alone. So here it is for the mailing list. Sorry. Begin forwarded message: On Wed, 27 Jan 2010 12:43:13 +0300 Bulat Ziganshin wrote: > > exitWith throws the ExitCode when it is called. This leads to the > > shutdown of the program, if it isn't caught. Just like ExitException. > > > This isn't documented. > > i've googled for "exitWith throws the ExitCode" and it pointed me to > the exitWith docs: "Computation exitWith code throws ExitException code." This is the source code of exitWith: -------------------------snip----------------------------- -- --------------------------------------------------------------------------- -- exitWith -- | Computation 'exitWith' @code@ throws 'ExitException' @code@. -- Normally this terminates the program, returning @code@ to the -- program's caller. Before the program terminates, any open or -- semi-closed handles are first closed. -- -- A program that fails in any other way is treated as if it had -- called 'exitFailure'. -- A program that terminates successfully without calling 'exitWith' -- explicitly is treated as it it had called 'exitWith' 'ExitSuccess'. -- -- As an 'ExitException' is not an 'IOError', 'exitWith' bypasses -- the error handling in the 'IO' monad and cannot be intercepted by -- 'catch' from the "Prelude". However it is an 'Exception', and can -- be caught using the functions of "Control.Exception". This means -- that cleanup computations added with 'Control.Exception.bracket' -- (from "Control.Exception") are also executed properly on 'exitWith'. #ifndef __NHC__ exitWith :: ExitCode -> IO a exitWith ExitSuccess = throwIO ExitSuccess exitWith code@(ExitFailure n) | n /= 0 = throwIO code #ifdef __GLASGOW_HASKELL__ | otherwise = ioError (IOError Nothing InvalidArgument "exitWith" "ExitFailure 0" Nothing) #endif #endif /* ! __NHC__ */ -------------------------snip----------------------------- As you can see, it throws the ExitCode, not an ExitException. The documentation is faulty. Cheers, Volker -- Volker Wysk -- Volker Wysk From simonpj at microsoft.com Thu Jan 28 02:50:43 2010 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Jan 28 02:20:43 2010 Subject: FW: GHC core plugins Message-ID: <59543203684B2244980D7E4057D5FBC10AFCBCD2@DB3EX14MBXC306.europe.corp.microsoft.com> -----Original Message----- From: Simon Peyton-Jones Sent: 28 January 2010 07:50 To: 'austin s' Subject: RE: GHC core plugins compiler/cmm/ZipDataFlow.hs But we have great ideas for making it much simpler and more modular. In progress.. S | -----Original Message----- | From: mad.one@gmail.com [mailto:mad.one@gmail.com] On Behalf Of austin s | Sent: 27 January 2010 16:24 | To: Simon Peyton-Jones | Subject: Re: GHC core plugins | | 2010/1/27 Simon Peyton-Jones : | > | Also, is Hoopl expected to be used on core -> core plugins, and, if so, | is | > | the | > | infrastructure in place for this? | > | > no, Hoopl works on imperative control flow graphs, the C-- part of the back | end, not on Core. | > | > Simon | > _______________________________________________ | > Glasgow-haskell-users mailing list | > Glasgow-haskell-users@haskell.org | > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | > | | Quick Question, even if it is OT: Is the Hoopl code available anywhere? | | -- | - Austin From mechvel at botik.ru Thu Jan 28 09:27:06 2010 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Thu Jan 28 09:01:24 2010 Subject: tracing messages Message-ID: <20100128142706.GA9894@scico.botik.ru> Dear GHC team, this is on tracing in ghc-6.12.1 (made from source on Debian Linux i-386-like machine). I wonder what is the reason for this tracing message (starting with `Step1 ...' ): ---------------------------- ... equations calc = [j < i -> true, m <= p -> true, p <= q -> true, q <= n -> true, (A p) <= (A q) -> false, (X <= Y) | (Y < X) -> true, | {not (Y <= n), not (m <= X), not (X < i), not (j < Y), (A X) <= (A Y)} -> true, | {not (X <= Y), not (Y <= j), not (m <= X), (A X) <= (A Y)} -> true, | {not (XStep 1. Starting mutual pre-reduction. The number of rules is 25. Pre-reduction done. Initial numbers of equations is 9, after reduction: 9, the pre-reduction cost is 484. ... ... ---------------------------- The main program does the following in succession: 1) finds eqs, 2) prints "equations calc =\n", shows eqs "\n\n", "Starting completion.\n", "remaining goals = ", 3) finds res by completion (`complete'), 4) prints shows (completionGoalRem res) "\n" The trace calls are set only in the function `complete'. The above message Step 1. Starting mutual pre-reduction. The number of rules is 25. Pre-reduction done. Initial numbers of equations is 9, occurs the first message of this tracing. But the main program must have printed the full last equation in eqs, and only after this any tracing message could appear. Instead, it breaks the last equation printing with the tracing messages. The further evaluation is long, so I interrupted it, without seeing the final result. But this printing break looks strange, because eqs does not depend on the results of `complete', the reverse holds: the latter applies to eqs. Generally, I often observe an effect of this kind; it is harmless, but I wonder, what might be the reason. Regards, ----------------- Serge Mechveliani mechvel@botik.ru From marlowsd at gmail.com Thu Jan 28 09:39:56 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Jan 28 09:11:49 2010 Subject: tracing messages In-Reply-To: <20100128142706.GA9894@scico.botik.ru> References: <20100128142706.GA9894@scico.botik.ru> Message-ID: <4B61A1BC.8040208@gmail.com> On 28/01/2010 14:27, Serge D. Mechveliani wrote: > Dear GHC team, > > this is on tracing in ghc-6.12.1 > (made from source on Debian Linux i-386-like machine). > > I wonder what is the reason for this tracing message > (starting with `Step1 ...' ): > > ---------------------------- > ... > equations calc = > [j< i -> true, > m<= p -> true, > p<= q -> true, > q<= n -> true, > (A p)<= (A q) -> false, > (X<= Y) | (Y< X) -> true, > | {not (Y<= n), not (m<= X), not (X< i), not (j< Y), (A X)<= (A Y)} -> > true, > | {not (X<= Y), not (Y<= j), not (m<= X), (A X)<= (A Y)} -> true, > | {not (XStep 1. Starting mutual pre-reduction. The number of rules is 25. > Pre-reduction done. Initial numbers of equations is 9, > after reduction: 9, the pre-reduction cost is 484. > ... > ... > ---------------------------- > > The main program does the following in succession: > 1) finds eqs, > 2) prints > "equations calc =\n", shows eqs "\n\n", > "Starting completion.\n", > "remaining goals = ", > 3) finds res by completion (`complete'), > 4) prints > shows (completionGoalRem res) "\n" > > The trace calls are set only in the function `complete'. > The above message > Step 1. Starting mutual pre-reduction. The number of rules is 25. > Pre-reduction done. Initial numbers of equations is 9, > > occurs the first message of this tracing. > But the main program must have printed the full last equation in > eqs, and only after this any tracing message could appear. > Instead, it breaks the last equation printing with the tracing messages. > The further evaluation is long, so I interrupted it, without seeing the > final result. But this printing break looks strange, because eqs > does not depend on the results of `complete', the reverse holds: the > latter applies to eqs. > Generally, I often observe an effect of this kind; it is harmless, but > I wonder, what might be the reason. Perhaps your program output is going to stdout, and the trace messages are going to stderr? Buffering would make them appear out of order. If you're using Debug.trace, I wouldn't recommend that for production use, only debugging. Cheers, Simon From jpm at cs.uu.nl Thu Jan 28 09:44:02 2010 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Thu Jan 28 09:16:10 2010 Subject: GHC core plugins In-Reply-To: <9d4d38821001270331v7b73f6d6gaaa33ae57e0ddcfe@mail.gmail.com> References: <52f14b211001260247n1767203fv54737acf5f44db4e@mail.gmail.com> <9d4d38821001261037r1ee6e1a9n94c2d7ea20296c75@mail.gmail.com> <59543203684B2244980D7E4057D5FBC10AFCAE88@DB3EX14MBXC306.europe.corp.microsoft.com> <52f14b211001270244qd532b1l6c57b94b71d559c6@mail.gmail.com> <9d4d38821001270331v7b73f6d6gaaa33ae57e0ddcfe@mail.gmail.com> Message-ID: <52f14b211001280644o4a7d1b7bw19d4b1790190ac36@mail.gmail.com> Hi Max, 2010/1/27 Max Bolingbroke > 2010/1/27 Jos? Pedro Magalh?es : > > Alright, ticket created: http://hackage.haskell.org/trac/ghc/ticket/3843 > > > > In any case, for now I am willing to hard-code a new core-to-core pass on > > the compiler. Any pointers for where I have to look at? > > I recommend you look at compiler/simplCore/CSE.lhs. It is a simple > example of a core-to-core pass. > > However, in short you'll need to: > 1) Create a function which implements your core to core pass, of a > type such as [CoreBind] -> [CoreBind] > *) If that function lives in a new module, edit ghc.cabal.in to tell > the build system about the module > 2) Add a constructor to the CoreToDo data type in > compiler/simplCore/CoreMonad.lhs > 3) Add a case for it to the coreDumpFlag and Outputable instance > 4) Add that pass to the list returned by getCoreToDo in CoreMonad. The > order of the list is the order the passes will be run in. > *) If you want the pass to be under the control of a new flag, you'll > need to add a new dynflag - add a constructor to the DOpt data type in > compiler/main/DynFlags.lhs, and add something to build that > constructor to one of the lists that get fed to the command line > handling code in the same module. It should be fairly obvious how to > do this. > 5) Add a handler for the new constructor to > compiler/simplCore/SimplCore.lhs, in the doCorePass function which > calls into the core pass function you wrote > > Hope that helps, > Max > Yes, that helped quite a lot. One last thing: currently it takes me about 6 minutes to rebuild the compiler after I change the core pass. Are there any tricks of the build system I can use to speed this up? I'm already using a fast build without optimizations and docs... Thanks, Pedro -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100128/91cb7ac8/attachment.html From batterseapower at hotmail.com Thu Jan 28 11:24:24 2010 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Thu Jan 28 10:56:12 2010 Subject: GHC core plugins In-Reply-To: <52f14b211001280644o4a7d1b7bw19d4b1790190ac36@mail.gmail.com> References: <52f14b211001260247n1767203fv54737acf5f44db4e@mail.gmail.com> <9d4d38821001261037r1ee6e1a9n94c2d7ea20296c75@mail.gmail.com> <59543203684B2244980D7E4057D5FBC10AFCAE88@DB3EX14MBXC306.europe.corp.microsoft.com> <52f14b211001270244qd532b1l6c57b94b71d559c6@mail.gmail.com> <9d4d38821001270331v7b73f6d6gaaa33ae57e0ddcfe@mail.gmail.com> <52f14b211001280644o4a7d1b7bw19d4b1790190ac36@mail.gmail.com> Message-ID: <9d4d38821001280824u49eda6b6kba9c80cb5ae4dc22@mail.gmail.com> 2010/1/28 Jos? Pedro Magalh?es : > Yes, that helped quite a lot. One last thing: currently it takes me about 6 > minutes to rebuild the compiler after I change the core pass. Are there any > tricks of the build system I can use to speed this up? I'm already using a > fast build without optimizations and docs... Hmm. Some things that help with this for me are to: 1) Compile with -j12 (or lower, depending on your hardware spec) 2) Compile with "cd compiler && make stage=2" to only build the stage 2 compiler (if this isn't already happening). Make sure the stage 1 compiler is built with optimisations! (I use the stage2devel configuration, which already does this) This reduces compile times to a few minutes for me. Still tedious, but not too bad. Hope that helps, Max From mechvel at botik.ru Thu Jan 28 11:34:01 2010 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Thu Jan 28 11:08:18 2010 Subject: tracing messages In-Reply-To: <4B61A1BC.8040208@gmail.com> References: <20100128142706.GA9894@scico.botik.ru> <4B61A1BC.8040208@gmail.com> Message-ID: <20100128163401.GA9965@scico.botik.ru> On Thu, Jan 28, 2010 at 02:39:56PM +0000, Simon Marlow wrote: > On 28/01/2010 14:27, Serge D. Mechveliani wrote: > >Dear GHC team, > > > >this is on tracing in ghc-6.12.1 > >(made from source on Debian Linux i-386-like machine). > > > >I wonder what is the reason for this tracing message > >(starting with `Step1 ...' ): > > > >---------------------------- > >... > >equations calc = > >[j< i -> true, > >m<= p -> true, > >p<= q -> true, > >q<= n -> true, > >(A p)<= (A q) -> false, > >(X<= Y) | (Y< X) -> true, > >| {not (Y<= n), not (m<= X), not (X< i), not (j< Y), (A X)<= (A Y)} -> > >true, > >| {not (X<= Y), not (Y<= j), not (m<= X), (A X)<= (A Y)} -> true, > >| {not (XStep 1. Starting mutual pre-reduction. The number of rules is > >25. > >Pre-reduction done. Initial numbers of equations is 9, > >after reduction: 9, the pre-reduction cost is 484. > >... > >... > >---------------------------- > > > >The main program does the following in succession: > >1) finds eqs, > >2) prints > > "equations calc =\n", shows eqs "\n\n", > > "Starting completion.\n", > > "remaining goals = ", > >3) finds res by completion (`complete'), > >4) prints > > shows (completionGoalRem res) "\n" > > > >The trace calls are set only in the function `complete'. > >The above message > > Step 1. Starting mutual pre-reduction. The number of rules is 25. > > Pre-reduction done. Initial numbers of equations is 9, > > > >occurs the first message of this tracing. > >But the main program must have printed the full last equation in > >eqs, and only after this any tracing message could appear. > >Instead, it breaks the last equation printing with the tracing messages. > >The further evaluation is long, so I interrupted it, without seeing the > >final result. But this printing break looks strange, because eqs > >does not depend on the results of `complete', the reverse holds: the > >latter applies to eqs. > >Generally, I often observe an effect of this kind; it is harmless, but > >I wonder, what might be the reason. > > Perhaps your program output is going to stdout, and the trace messages > are going to stderr? Buffering would make them appear out of order. > > If you're using Debug.trace, I wouldn't recommend that for production > use, only debugging. > > Cheers, > Simon Thank you. Probably, this is the matter of stdout+stderr+bufering. I run it by Main > & log, and then, see ./log. ----------------- Serge Mechveliani mechvel@botik.ru From jakewheatmail at googlemail.com Thu Jan 28 12:03:34 2010 From: jakewheatmail at googlemail.com (Jake Wheat) Date: Thu Jan 28 11:35:22 2010 Subject: bug in template haskell (with recursion?) In-Reply-To: <4b5b53361001271234v46184ed2v3bcdc89cc181051c@mail.gmail.com> References: <4b5b53361001271234v46184ed2v3bcdc89cc181051c@mail.gmail.com> Message-ID: <4b5b53361001280903r382b1bcdi6da4536f76745367@mail.gmail.com> Sorry for posting this on the wrong mailing list. I added the bug to the tracker here: http://hackage.haskell.org/trac/ghc/ticket/3845 From ia at stryx.demon.co.uk Thu Jan 28 18:38:27 2010 From: ia at stryx.demon.co.uk (Iain Alexander) Date: Thu Jan 28 18:14:56 2010 Subject: Language extensions - backwards compatibility Message-ID: <4B621FF3.18916.C6275B@ia.stryx.demon.co.uk> I'm looking for a way of specifying language extensions in a way which will work in all versions of GHC from 6.4 onwards. GHC 6.4 does not support the LANGUAGE pragma. Specifying language options in the OPTIONS_GHC pragma starts to produce deprecation warnings in 6.10, and will presumably eventually fail altogether. Any sort of preprocessing at the beginning of a file appears to insert enough noise to inhibit recognition of file-header pragmas. (Cpphs doesn't appear to help here.) Attempting preprocessing inside a leading OPTIONS_GHC pragma fails because it apparently attempts to interpret the pragma *before* invoking the preprocessor. The only remaining option I can see is to have a completely separate version of the file for GHC 6.4. Have I missed anything? -- Iain Alexander ia@stryx.demon.co.uk From dons at galois.com Thu Jan 28 18:45:33 2010 From: dons at galois.com (Don Stewart) Date: Thu Jan 28 18:17:20 2010 Subject: Language extensions - backwards compatibility In-Reply-To: <4B621FF3.18916.C6275B@ia.stryx.demon.co.uk> References: <4B621FF3.18916.C6275B@ia.stryx.demon.co.uk> Message-ID: <20100128234533.GU27572@whirlpool.galois.com> ia: > I'm looking for a way of specifying language extensions in a way which will > work in all versions of GHC from 6.4 onwards. > > GHC 6.4 does not support the LANGUAGE pragma. Specifying language options in > the OPTIONS_GHC pragma starts to produce deprecation warnings in 6.10, and will > presumably eventually fail altogether. > > Any sort of preprocessing at the beginning of a file appears to insert enough > noise to inhibit recognition of file-header pragmas. (Cpphs doesn't appear to > help here.) Attempting preprocessing inside a leading OPTIONS_GHC pragma fails > because it apparently attempts to interpret the pragma *before* invoking the > preprocessor. > > The only remaining option I can see is to have a completely separate version of > the file for GHC 6.4. Have I missed anything? Could you talk a bit about why you need to support 6.4 onwards -- that seems like quite a burden. Is the effort worth it? From jpm at cs.uu.nl Fri Jan 29 04:32:20 2010 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Fri Jan 29 04:04:27 2010 Subject: GHC core plugins In-Reply-To: <9d4d38821001280824u49eda6b6kba9c80cb5ae4dc22@mail.gmail.com> References: <52f14b211001260247n1767203fv54737acf5f44db4e@mail.gmail.com> <9d4d38821001261037r1ee6e1a9n94c2d7ea20296c75@mail.gmail.com> <59543203684B2244980D7E4057D5FBC10AFCAE88@DB3EX14MBXC306.europe.corp.microsoft.com> <52f14b211001270244qd532b1l6c57b94b71d559c6@mail.gmail.com> <9d4d38821001270331v7b73f6d6gaaa33ae57e0ddcfe@mail.gmail.com> <52f14b211001280644o4a7d1b7bw19d4b1790190ac36@mail.gmail.com> <9d4d38821001280824u49eda6b6kba9c80cb5ae4dc22@mail.gmail.com> Message-ID: <52f14b211001290132j7dd6965bnca2331a7ad2ed621@mail.gmail.com> Hi, 2010/1/28 Max Bolingbroke > 2010/1/28 Jos? Pedro Magalh?es : > > Yes, that helped quite a lot. One last thing: currently it takes me about > 6 > > minutes to rebuild the compiler after I change the core pass. Are there > any > > tricks of the build system I can use to speed this up? I'm already using > a > > fast build without optimizations and docs... > > Hmm. Some things that help with this for me are to: > 1) Compile with -j12 (or lower, depending on your hardware spec) > 2) Compile with "cd compiler && make stage=2" to only build the stage > 2 compiler (if this isn't already happening). Make sure the stage 1 > compiler is built with optimisations! (I use the stage2devel > configuration, which already does this) > > This reduces compile times to a few minutes for me. Still tedious, but > not too bad. > Thanks. Doing this reduces compilation time to about 30s, but unfortunately my pass is not updated (even though it is compiled). I have to do 'make stage=2' at the root directory, not inside compiler. This brings compilation time to 1m10s (which is still better than what I was doing), but I really don't know what would need building outside the compiler directory... As an aside, is there any hope of using SYB in the core pass? As a generic programmer I quickly get tired of traversing the entire AST when I want just a few changes in specific places... Thanks, Pedro > > Hope that helps, > Max > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100129/6ce1e6bc/attachment-0001.html From marlowsd at gmail.com Fri Jan 29 04:46:18 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Jan 29 04:18:06 2010 Subject: Language extensions - backwards compatibility In-Reply-To: <4B621FF3.18916.C6275B@ia.stryx.demon.co.uk> References: <4B621FF3.18916.C6275B@ia.stryx.demon.co.uk> Message-ID: <4B62AE6A.9040303@gmail.com> On 28/01/10 23:38, Iain Alexander wrote: > I'm looking for a way of specifying language extensions in a way which will > work in all versions of GHC from 6.4 onwards. > > GHC 6.4 does not support the LANGUAGE pragma. Specifying language options in > the OPTIONS_GHC pragma starts to produce deprecation warnings in 6.10, and will > presumably eventually fail altogether. > > Any sort of preprocessing at the beginning of a file appears to insert enough > noise to inhibit recognition of file-header pragmas. (Cpphs doesn't appear to > help here.) Attempting preprocessing inside a leading OPTIONS_GHC pragma fails > because it apparently attempts to interpret the pragma *before* invoking the > preprocessor. > > The only remaining option I can see is to have a completely separate version of > the file for GHC 6.4. Have I missed anything? There are a little cluster of bugs to do with this, see http://hackage.haskell.org/trac/ghc/ticket/3457 We need to re-read the pragmas after preprocessing. Ironically though, you will only be able to use this facility with a GHC that supports it, so we'll see a lot of source files like {-# LANGUAGE ... #-} #if __GLASGOW_HASKELL__ >= 614 {-# LANGUAGE .. more .. #-} #endif because GHC before 6.14 will stop at the first #if. (that's assuming we implement this for 6.14, it hasn't been done yet) Cheers, Simon From marlowsd at gmail.com Fri Jan 29 04:52:03 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Jan 29 04:23:50 2010 Subject: GHC core plugins In-Reply-To: <52f14b211001290132j7dd6965bnca2331a7ad2ed621@mail.gmail.com> References: <52f14b211001260247n1767203fv54737acf5f44db4e@mail.gmail.com> <9d4d38821001261037r1ee6e1a9n94c2d7ea20296c75@mail.gmail.com> <59543203684B2244980D7E4057D5FBC10AFCAE88@DB3EX14MBXC306.europe.corp.microsoft.com> <52f14b211001270244qd532b1l6c57b94b71d559c6@mail.gmail.com> <9d4d38821001270331v7b73f6d6gaaa33ae57e0ddcfe@mail.gmail.com> <52f14b211001280644o4a7d1b7bw19d4b1790190ac36@mail.gmail.com> <9d4d38821001280824u49eda6b6kba9c80cb5ae4dc22@mail.gmail.com> <52f14b211001290132j7dd6965bnca2331a7ad2ed621@mail.gmail.com> Message-ID: <4B62AFC3.4000707@gmail.com> On 29/01/10 09:32, Jos? Pedro Magalh?es wrote: > Hi, > > 2010/1/28 Max Bolingbroke > > > 2010/1/28 Jos? Pedro Magalh?es >: > > Yes, that helped quite a lot. One last thing: currently it takes > me about 6 > > minutes to rebuild the compiler after I change the core pass. Are > there any > > tricks of the build system I can use to speed this up? I'm > already using a > > fast build without optimizations and docs... > > Hmm. Some things that help with this for me are to: > 1) Compile with -j12 (or lower, depending on your hardware spec) > 2) Compile with "cd compiler && make stage=2" to only build the stage > 2 compiler (if this isn't already happening). Make sure the stage 1 > compiler is built with optimisations! (I use the stage2devel > configuration, which already does this) > > This reduces compile times to a few minutes for me. Still tedious, but > not too bad. > > > Thanks. Doing this reduces compilation time to about 30s, but > unfortunately my pass is not updated (even though it is compiled). I > have to do 'make stage=2' at the root directory, not inside compiler. > This brings compilation time to 1m10s (which is still better than what I > was doing), but I really don't know what would need building outside the > compiler directory... The correct way to update your stage 2 compiler without rebuilding extraneous dependencies is: $ cd ghc $ make 2 for more info, see http://hackage.haskell.org/trac/ghc/wiki/Building/Using#RebuildingtheGHCbinaryaftermakingchanges > As an aside, is there any hope of using SYB in the core pass? As a > generic programmer I quickly get tired of traversing the entire AST when > I want just a few changes in specific places... That's a discussion we ought to have at some point. Note however that Core is actually a very deep data type (Ids contain unfoldings, which contain more expressions, which contain Ids, which contain types, and so on), and is also cyclic. Simply traversing the whole thing would be a very bad idea. There is a ghc-syb package which has SYB instances for HsSyn I think. HsSyn is not as deep or cyclic as Core. Cheers, Simon From Malcolm.Wallace at cs.york.ac.uk Fri Jan 29 05:58:47 2010 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Fri Jan 29 05:30:52 2010 Subject: Language extensions - backwards compatibility In-Reply-To: <4B621FF3.18916.C6275B@ia.stryx.demon.co.uk> References: <4B621FF3.18916.C6275B@ia.stryx.demon.co.uk> Message-ID: > Any sort of preprocessing at the beginning of a file appears to > insert enough noise to inhibit recognition of file-header pragmas. > (Cpphs doesn't appear to help here.) The flag -P for traditional gnu cpp (or --noline for stand-alone cpphs) should suppress the initial #line noise. Does ghc still fail to recognise a module-start pragma, even if the only characters preceding it are whitespace? Regards, Malcolm From bulat.ziganshin at gmail.com Fri Jan 29 05:50:04 2010 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Jan 29 05:31:59 2010 Subject: Language extensions - backwards compatibility In-Reply-To: <4B621FF3.18916.C6275B@ia.stryx.demon.co.uk> References: <4B621FF3.18916.C6275B@ia.stryx.demon.co.uk> Message-ID: <1327991892.20100129135004@gmail.com> Hello Iain, Friday, January 29, 2010, 2:38:27 AM, you wrote: > I'm looking for a way of specifying language extensions in a way which will > work in all versions of GHC from 6.4 onwards. you can use compiler options or preprocess source before feeding it to ghc -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From Malcolm.Wallace at cs.york.ac.uk Fri Jan 29 06:10:03 2010 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Fri Jan 29 05:42:41 2010 Subject: Language extensions - backwards compatibility In-Reply-To: References: <4B621FF3.18916.C6275B@ia.stryx.demon.co.uk> Message-ID: <28AF86C2-8609-40F9-9855-A067F2F83EF1@cs.york.ac.uk> > The flag -P for traditional gnu cpp (or --noline for stand-alone > cpphs) should suppress the initial #line noise. > > Does ghc still fail to recognise a module-start pragma, even if the > only characters preceding it are whitespace? I intended to give an example. ---- file foo.h ---- #if __GLASGOW_HASKELL__ == 604 #define PRAGMA(foo) {-# OPTIONS_GHC -X foo #-} #else #define PRAGMA(foo) {-# LANGUAGE foo #-} ---- file Bar.hs ---- #include "foo.h" PRAGMA(MyLanguageOption) module Bar where ---- result ---- $ ghc-6.8.2 -E -cpp -optP-P Bar.hs $ cat Bar.hspp {-# LINE 1 "Bar.hs" #-} {-# LANGUAGE MyLanguageOption #-} module Bar where $ ghc-6.4.1 -E -cpp -optP-P Bar.hs $ cat Bar.hspp {-# OPTIONS_GHC -X MyLanguageOption #-} module Bar where From khaelin at gmail.com Fri Jan 29 12:10:52 2010 From: khaelin at gmail.com (Nicolas Martyanoff) Date: Fri Jan 29 11:42:39 2010 Subject: cross-compiling ghc to openbsd Message-ID: <20100129171052.GA753@valhala.home> Hi, I'm trying to cross-compile GHC as follows: Host: Linux, x86_64, GHC 6.12.1 Target: OpenBSD 4.6 stable, i386 I follow the guide at: http://hackage.haskell.org/trac/ghc/wiki/Building/Porting I downloaded the last stable source tarball (ghc-6.12.1-src.tar.bz2), then ran the following commands: export AUTOCONF_VERSION=2.62 export AUTOMAKE_VERSION=1.9 cp /bin/pwd utils/ghc-pwd/ghc-pwd sh boot ./configure --enable-hc-boot --build=i386-unknown-openbsd --host=i386-unknown-openbsd --target=i386-unknown-openbsd gmake bootstrapping-files The latest fails, with the following trace: http://pastebin.ca/1770926 The following errors are quite interesting: includes/stg/Types.h:103:2: #error GHC untested on this architecture: sizeof(void *) != 4 or 8 includes/rts/Constants.h:156:2: #error unknown SIZEOF_VOID_P Does someone what's going on with this build ? Is there something I can to to help on these issues ? Regards, -- Nicolas Martyanoff http://codemore.org khaelin@gmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100129/8f1d6524/attachment.bin From kili at outback.escape.de Fri Jan 29 14:23:38 2010 From: kili at outback.escape.de (Matthias Kilian) Date: Fri Jan 29 13:55:48 2010 Subject: cross-compiling ghc to openbsd In-Reply-To: <20100129171052.GA753@valhala.home> References: <20100129171052.GA753@valhala.home> Message-ID: <20100129192337.GA8649@nutty.outback.escape.de> On Fri, Jan 29, 2010 at 06:10:52PM +0100, Nicolas Martyanoff wrote: > I'm trying to cross-compile GHC as follows: > > Host: Linux, x86_64, GHC 6.12.1 > Target: OpenBSD 4.6 stable, i386 IMHO, you shouldn't go that way, because it adds much more complexity than you already have with OpenBSD as host *adn* target. During my last tests back in december, not even OpenBSD/i386 -> OpenBSD/i386 worked with .hc files. That should be fixed first. Then, something like OpenBSD/i386 -> OpenBSD-amd64 (and vice versa) should be done. And if this works, it's questionable wether one should work on cross building with .hc files using differen host an target operating systems or wether it would be more useful to start getting GHC running on other OpenBSD archs. > I follow the guide at: > http://hackage.haskell.org/trac/ghc/wiki/Building/Porting > > I downloaded the last stable source tarball (ghc-6.12.1-src.tar.bz2), then ran > the following commands: > > export AUTOCONF_VERSION=2.62 > export AUTOMAKE_VERSION=1.9 > cp /bin/pwd utils/ghc-pwd/ghc-pwd > sh boot > ./configure --enable-hc-boot --build=i386-unknown-openbsd --host=i386-unknown-openbsd --target=i386-unknown-openbsd [...] IIRC there where some discussions (or even patches pushed?) about the build/host/target combo, so you may try to pull ghc sources with darcs (head or the 6.12 branch). > The latest fails, with the following trace: > http://pastebin.ca/1770926 > > The following errors are quite interesting: > includes/stg/Types.h:103:2: #error GHC untested on this architecture: sizeof(void *) != 4 or 8 > includes/rts/Constants.h:156:2: #error unknown SIZEOF_VOID_P Your build is (re)creating includes/ghcautoconf.h -- this looks very wrong to me, since ghcautoconf.h is supposed to be created by a former configure / make bootstrapping-files on the target platform and then used on the host for creating the .hc files. Ciao, Kili From donn at avvanta.com Fri Jan 29 14:54:47 2010 From: donn at avvanta.com (Donn Cave) Date: Fri Jan 29 14:26:31 2010 Subject: cross-compiling ghc to openbsd References: <20100129171052.GA753@valhala.home> Message-ID: <20100129195447.D499B276C61@mail.avvanta.com> Quoth Nicolas Martyanoff , ... > The latest fails, with the following trace: > http://pastebin.ca/1770926 Can you look at the include files, at the locations where all these errors crop up? like, includes/stg/Types.h:118: error: syntax error before '*' token This probably means some type identifier used at that point hasn't been declared, or macro defined or whatever. You'd have to see what it is, and maybe it will be more obvious what went wrong. But of course Matthias is right, the configuration of build and target hosts you propose to use probably isn't going to work. The idea is that you do this configure step on the OpenBSD host, right? and then transplant this configuration (a couple of .h files, etc.) to the build host and proceed to build the .hc files. That means the build host has to be a lot like the target host, or that build will be radically misconfigured. Same hardware architecture, at a minimum. Donn From khaelin at gmail.com Fri Jan 29 15:42:27 2010 From: khaelin at gmail.com (Nicolas Martyanoff) Date: Fri Jan 29 15:14:12 2010 Subject: cross-compiling ghc to openbsd In-Reply-To: <20100129195447.D499B276C61@mail.avvanta.com> References: <20100129171052.GA753@valhala.home> <20100129195447.D499B276C61@mail.avvanta.com> Message-ID: <20100129204227.GC753@valhala.home> On 10-01-29 11:54, Donn Cave wrote: > Quoth Nicolas Martyanoff , > ... > > The latest fails, with the following trace: > > http://pastebin.ca/1770926 > > Can you look at the include files, at the locations where all these > errors crop up? like, > includes/stg/Types.h:118: error: syntax error before '*' token > > This probably means some type identifier used at that point hasn't > been declared, or macro defined or whatever. You'd have to see > what it is, and maybe it will be more obvious what went wrong. It seems that SIZEOF_VOID_P isn't defined anywhere. > But of course Matthias is right, the configuration of build and > target hosts you propose to use probably isn't going to work. The > idea is that you do this configure step on the OpenBSD host, right? > and then transplant this configuration (a couple of .h files, etc.) > to the build host and proceed to build the .hc files. That means > the build host has to be a lot like the target host, or that build > will be radically misconfigured. Same hardware architecture, at a > minimum. All right, I'll try again with the last darcs version when I get access to a i386 Linux machine. In the mean time, I'll try to run a GHC 6.6 -> 6.10 -> 6.12 build chain, 6.6 being the latest version available in OpenBSD's ports. Thank you for your help ! Regards, -- Nicolas Martyanoff http://codemore.org khaelin@gmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100129/651f44f2/attachment-0001.bin From twhitehead at gmail.com Fri Jan 29 16:02:19 2010 From: twhitehead at gmail.com (Tyson Whitehead) Date: Fri Jan 29 15:34:13 2010 Subject: Question regarding combinator call convention Message-ID: <201001291602.26275.twhitehead@gmail.com> I was looking through the code for 6.12.1 and am a bit confused about 11.1.3 in the runtime system documentation docs/rts/rts.tex. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.79.641&rep=rep1&type=pdf It says the arguments passing convention to a known combinator differs from that of the others in that it starts the arguments with R1 instead of R2 (R1 points to the associated memory data structure for non-combinators). The thing I'm confused with is I would expect this would require treating combinators special, and yet I don't see an combinator specific stuff (in either ClosureTypes.h or the generated AutoApply.cmm) to treat them special. Ive also looking at functions like plusInt and a few of my own, but, apart from internal functions like stg_app_*, I'm not finding any code using the the combinator passing convention. Am I missing something? Thanks! -Tyson -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100129/a68c6897/attachment.bin From donn at avvanta.com Fri Jan 29 16:03:40 2010 From: donn at avvanta.com (Donn Cave) Date: Fri Jan 29 15:35:24 2010 Subject: cross-compiling ghc to openbsd References: <20100129171052.GA753@valhala.home> <20100129195447.D499B276C61@mail.avvanta.com><20100129204227.GC753@valhala.home> Message-ID: <20100129210340.75F92276D6A@mail.avvanta.com> Quoth Nicolas Martyanoff , > It seems that SIZEOF_VOID_P isn't defined anywhere. I guess it's immaterial if you aren't going to pursue the port strategy any farther, but from a cursory look, this would happen at the point where the configuration log says "checking size of void *". That's failing because of an autoconf error, or a C compiler configuration issue, I would guess. Donn From kili at outback.escape.de Fri Jan 29 16:36:06 2010 From: kili at outback.escape.de (Matthias Kilian) Date: Fri Jan 29 16:08:54 2010 Subject: cross-compiling ghc to openbsd In-Reply-To: <20100129204227.GC753@valhala.home> References: <20100129171052.GA753@valhala.home> <20100129195447.D499B276C61@mail.avvanta.com> <20100129204227.GC753@valhala.home> Message-ID: <20100129213606.GB11193@nutty.outback.escape.de> On Fri, Jan 29, 2010 at 09:42:27PM +0100, Nicolas Martyanoff wrote: > > This probably means some type identifier used at that point hasn't > > been declared, or macro defined or whatever. You'd have to see > > what it is, and maybe it will be more obvious what went wrong. > It seems that SIZEOF_VOID_P isn't defined anywhere. It's defined in includes/ghcautoconf.h (which is created during configure and make bootstrapping-files on the target platform). > All right, I'll try again with the last darcs version when I get access to a > i386 Linux machine. You don't need any linux machine for this. The current darcs port for OpenBSD may be a little bit outdated, but it still works. > In the mean time, I'll try to run a GHC 6.6 -> 6.10 -> 6.12 build chain, 6.6 > being the latest version available in OpenBSD's ports. I sent you a (admittedly horrible) script to do this chain. Use it. If it doesn't work, sent complaints. From dons at galois.com Fri Jan 29 19:34:04 2010 From: dons at galois.com (Don Stewart) Date: Fri Jan 29 19:05:49 2010 Subject: cross-compiling ghc to openbsd In-Reply-To: <20100129171052.GA753@valhala.home> References: <20100129171052.GA753@valhala.home> Message-ID: <20100130003404.GU32539@whirlpool.galois.com> Why cross compile when we already have a native GHC on OpenBSD/x86_64 .. use that to build the source directly. khaelin: > Hi, > > I'm trying to cross-compile GHC as follows: > > Host: Linux, x86_64, GHC 6.12.1 > Target: OpenBSD 4.6 stable, i386 > > I follow the guide at: > http://hackage.haskell.org/trac/ghc/wiki/Building/Porting > > I downloaded the last stable source tarball (ghc-6.12.1-src.tar.bz2), then ran > the following commands: > > export AUTOCONF_VERSION=2.62 > export AUTOMAKE_VERSION=1.9 > cp /bin/pwd utils/ghc-pwd/ghc-pwd > sh boot > ./configure --enable-hc-boot --build=i386-unknown-openbsd --host=i386-unknown-openbsd --target=i386-unknown-openbsd > gmake bootstrapping-files > > The latest fails, with the following trace: > http://pastebin.ca/1770926 > > The following errors are quite interesting: > includes/stg/Types.h:103:2: #error GHC untested on this architecture: sizeof(void *) != 4 or 8 > includes/rts/Constants.h:156:2: #error unknown SIZEOF_VOID_P > > Does someone what's going on with this build ? > Is there something I can to to help on these issues ? > > Regards, > > -- > Nicolas Martyanoff > http://codemore.org > khaelin@gmail.com > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From ia at stryx.demon.co.uk Fri Jan 29 20:32:56 2010 From: ia at stryx.demon.co.uk (Iain Alexander) Date: Fri Jan 29 20:11:28 2010 Subject: Language extensions - backwards compatibility In-Reply-To: <28AF86C2-8609-40F9-9855-A067F2F83EF1@cs.york.ac.uk> Message-ID: <4B638C48.21045.E5B7CC@ia.stryx.demon.co.uk> On 29 Jan 2010 at 15:14, Malcolm Wallace wrote: > > The flag -P for traditional gnu cpp (or --noline for stand-alone > > cpphs) should suppress the initial #line noise. > > > > Does ghc still fail to recognise a module-start pragma, even if the > > only characters preceding it are whitespace? I'm not sure, but ghci apparently fails to recognise a file-header pragma if it is preceded by a {-# LINE ... #-} pragma. > > I intended to give an example. > > ---- file foo.h ---- > #if __GLASGOW_HASKELL__ == 604 > #define PRAGMA(foo) {-# OPTIONS_GHC -X foo #-} > #else > #define PRAGMA(foo) {-# LANGUAGE foo #-} > > ---- file Bar.hs ---- > #include "foo.h" > PRAGMA(MyLanguageOption) > module Bar where > > ---- result ---- > $ ghc-6.8.2 -E -cpp -optP-P Bar.hs > $ cat Bar.hspp > {-# LINE 1 "Bar.hs" #-} How on earth does the *C* preprocessor manage to insert a *Haskell* {-# LINE ... #-} pragma? (I see that myself as well in some configurations, some cpphs (which I could understand), but some not.) > > > > {-# LANGUAGE MyLanguageOption #-} > module Bar where > > $ ghc-6.4.1 -E -cpp -optP-P Bar.hs > $ cat Bar.hspp > > {-# OPTIONS_GHC -X MyLanguageOption #-} > module Bar where > -- Iain Alexander ia@stryx.demon.co.uk From ia at stryx.demon.co.uk Fri Jan 29 20:13:41 2010 From: ia at stryx.demon.co.uk (Iain Alexander) Date: Fri Jan 29 20:11:42 2010 Subject: Language extensions - backwards compatibility In-Reply-To: <1327991892.20100129135004@gmail.com> References: <4B621FF3.18916.C6275B@ia.stryx.demon.co.uk> Message-ID: <4B6387C5.4610.D41546@ia.stryx.demon.co.uk> On 29 Jan 2010 at 13:50, Bulat Ziganshin wrote: > you can use compiler options or preprocess source before feeding it to ghc Separate preprocessing: If there were a preprocessor which was readily available in a typical Haskell installation and could be simply persuaded to do the job (e.g. as a -F "Haskell" preprocessor), that might fit my requirements. I can't think of anything off-hand, but thanks for the suggestion. Compiler options: I want to use Cabal, so this would mean feeding the same options to all the source files, which isn't ideal. On the other hand, this would only apply to the earlier releases, perhaps only 6.4, and the detailed breakdown would be there in the LANGUAGE pragma for later releases, so this might actually be the most practical solution. -- Iain Alexander ia@stryx.demon.co.uk From ia at stryx.demon.co.uk Fri Jan 29 19:50:58 2010 From: ia at stryx.demon.co.uk (Iain Alexander) Date: Fri Jan 29 20:11:50 2010 Subject: Language extensions - backwards compatibility In-Reply-To: <20100128234533.GU27572@whirlpool.galois.com> References: <4B621FF3.18916.C6275B@ia.stryx.demon.co.uk> Message-ID: <4B638272.31296.BF4AB4@ia.stryx.demon.co.uk> On 28 Jan 2010 at 15:45, Don Stewart wrote: > Could you talk a bit about why you need to support 6.4 onwards -- that > seems like quite a burden. Is the effort worth it? Good question. The code was developed on 6.4, and I would really quite like to continue 6.4 support for personal reasons, if nothing else. But I would like to release it on Hackage eventually, so I really need to consider support for later releases. :-) In principle, I don't anticipate any portability problems, other than this practical one of managing the way the various versions of the compiler handle language extensions. Obviously, there may come a point where I cut 6.4 loose, and to some extent this depends on what sort of solution (if any) to this problem arises. -- Iain Alexander ia@stryx.demon.co.uk From khaelin at gmail.com Sun Jan 31 08:28:32 2010 From: khaelin at gmail.com (Nicolas Martyanoff) Date: Sun Jan 31 07:59:54 2010 Subject: building 6.12.1 with itself Message-ID: <20100131132832.GC7536@valhala.home> Hi, By reading Matthias Kilian's scripts (thank you !), I successfully builded GHC 6.12.1. GHC 6.10.4 didn't build: g Lexer.x gmake[2]: g: Command not found gmake[2]: [Lexer.hs] Error 127 (ignored) RTS -K2m -RTS -agc --strict Parser.y gmake[2]: RTS: Command not found gmake[2]: *** [Parser.hs] Error 127 Failed making boot in genprimopcode: 1 gmake[1]: *** [boot] Error 1 gmake: *** [stage1] Error 1 But GHC 6.8.3 did. I then built GHC 6.12.1. The only problem was that the build process doesn't find the iconv lib when it's installed in /usr/local, so the lib/include paths have to be specified when running ./configure. I then installed Cabal 1.9 from darcs, and cabal-install, still from darcs. I used cabal to install hscolour, xmonad and xmonad-contrib, it worked perfectly. I thought it might be good to build GHC 6.12.1 with itself just to be sure it's working fine before make a dist, but I now get the following error: "/usr/local/bin/ghc" -H32m -O -package-conf libraries/bootstrapping.conf -package-name ghc-6.12.1 -hide-all-packages -i -icompiler/nativeGen -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/cprAnalysis -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/main -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage1/build -icompiler/stage1/build/autogen -Icompiler/stage1/build -Icompiler/stage1/build/autogen -Icompiler/stage1 -Icompiler/../libraries/base/cbits -Icompiler/../libraries/base/include -Icompiler/. -Icompiler/parser -Icompiler/utils -optP-include -optPcompiler/stage1/build/autogen/cabal_macros.h -package Cabal-1.9.0 -package array-0.3.0.0 -package base-4.2.0.0 -package bin-package-db-0.0.0.0 -package bytestring-0.9.1.5 -package containers-0.3.0.0 -package directory-1.0.1.0 -package filepath-1.1.0.3 -package hpc-0.5.0.4 -package old-time-1.0.0.3 -package process-1.0.1.2 -package unix-2.4.0.0 -DSTAGE=1 -Wall -fno-warn-name-shadowing -fno-warn-orphans -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRank2Types -XScopedTypeVariables -XDeriveDataTypeable -XRelaxedPolyRec -odir compiler/stage1/build -hidir compiler/stage1/build -stubdir compiler/stage1/build -hisuf hi -osuf o -hcsuf hc -c compiler/main/Packages.lhs -o compiler/stage1/build/Packages.o compiler/main/Packages.lhs:233:63: Couldn't match expected type `InstalledPackageInfo_ String' against inferred type `Cabal-1.8.0.2:Distribution.InstalledPackageInfo.InstalledPackageInfo_ m' Expected type: [InstalledPackageInfo_ String] Inferred type: [Cabal-1.8.0.2:Distribution.InstalledPackageInfo.InstalledPackageInfo_ m] In the second argument of `map', namely `conf' In the first argument of `return', namely `(map installedPackageInfoToPackageConfig conf)' gmake[1]: *** [compiler/stage1/build/Packages.o] Error 1 gmake: *** [all] Error 2 I tried to "ghc-pkg mask" Cabal-1.8.0.2, then Cabal-1.9.0, didn't change anything. Does someone know what's going on here, and what can be done to fix it ? Regards, -- Nicolas Martyanoff http://codemore.org khaelin@gmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100131/52e219a7/attachment.bin From mechvel at botik.ru Sun Jan 31 14:09:42 2010 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Sun Jan 31 13:44:00 2010 Subject: forgetting SCC Message-ID: <20100131190942.GA15572@scico.botik.ru> I have a suggestion: is it better for GHC to report an error on the source of kind {-# "foo" #-} (entered by a typo instead of {-# SCC "foo" #-}) ? Currently, GHC makes the program under (-prof) in which, the "foo" center occurs skipped. This misleads the user: "foo is not in the profiling head, so it takes zero cost". Regards, ----------------- Serge Mechveliani mechvel@botik.ru