From duncan.coutts at worc.ox.ac.uk Sat Nov 1 11:12:07 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Nov 1 11:07:21 2008 Subject: darcs patch: Added list operations for arrows In-Reply-To: <3c6288ab0810310817g4c6b15feqfcf78853df70a80d@mail.gmail.com> References: <200810311326.55357.g9ks157k@acme.softbase.org> <1225459300.8437.79.camel@localhost> <200810311545.17419.g9ks157k@acme.softbase.org> <3c6288ab0810310817g4c6b15feqfcf78853df70a80d@mail.gmail.com> Message-ID: <1225552327.8437.103.camel@localhost> On Fri, 2008-10-31 at 16:17 +0100, Sean Leather wrote: > > > Here here! > > > > 'A.filter' rather than 'filterA' (with a suitable qualified > import). > > > > Duncan > > > Hmm, is this meant ironically or seriously? Sorry, I just > don't know. > > I believe this is a Duncan-esque form of agreement with your > recommendation. Indeed :-) Sorry for the ambiguity. I kind of accept some of the fooM functions since they've been there for so long, but new ones make me itch to fix them. Duncan From duncan.coutts at worc.ox.ac.uk Sat Nov 1 16:58:39 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Nov 1 16:53:45 2008 Subject: HUnit in Hackage In-Reply-To: <1224711921.21116.205.camel@dell.linuxdev.us.dell.com> References: <48FE6B5E.9000804@moonloop.net> <1224711921.21116.205.camel@dell.linuxdev.us.dell.com> Message-ID: <1225573119.8437.153.camel@localhost> On Wed, 2008-10-22 at 14:45 -0700, Duncan Coutts wrote: > On Tue, 2008-10-21 at 16:53 -0700, Jon Strait wrote: > > Just some quick user feedback/questions. > > > > The current HUnit in Hackage depends on base (==4.*). I'm running GHC > > 6.8.3 with base 3.0.2.0. Is there an easier way to upgrade base > > without rebuilding GHC? Otherwise, the Cabal upgrade refuses to work > > unless I uninstall my older HUnit completely, do the Cabal upgrade, then > > re-install the older HUnit. I have other packages which depend on > > HUnit, so this must be done every time. Or is there a way to tell Cabal > > Install that I want to mask off HUnit for upgrading when I do a Cabal > > upgrade? > > I've updated the hunit package so that the latest version will build > with either base 3 or 4 (ie with ghc-6.8 or 6.10). > > I'll upload that to hackage soon. Now done, it should work with all recent versions of ghc (since 6.6). Duncan From dons at galois.com Sun Nov 2 23:47:50 2008 From: dons at galois.com (Don Stewart) Date: Sun Nov 2 23:42:31 2008 Subject: Arch Haskell News: Nov 02 2008 Message-ID: <20081103044750.GA21021@scytale.galois.com> News about the Haskell packages for Arch Linux. Highlights, * 672 Haskell packages now supported in Arch Linux, up 33 from two weeks ago. Noteworthy, * haskell-tcache-0.5.3: ?A Transactional data cache with configurable persistence? * haskell-yampa-0.9.2.3: ?Library for programming hybrid systems.? * haskell-network-bytestring-0.1.1.3: ?Fast and memory efficient low-level networking? * haskell-checkers-0.1.1: ?Check properties on standard classes and data structures.? * haskell-coreerlang-0.0.1: ?Facilities for manipulating Core Erlang source code: an abstract syntax, parser and pretty-printer.? Full update list, http://archhaskell.wordpress.com/2008/11/03/arch-haskell-news-nov-02-2008/ -- Don How's your favourite distro doing? If its not up to scratch, talk to someone. From jules at jellybean.co.uk Wed Nov 5 04:48:17 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Wed Nov 5 04:43:08 2008 Subject: darcs patch: Added list operations for arrows In-Reply-To: <200810311545.17419.g9ks157k@acme.softbase.org> References: <200810311326.55357.g9ks157k@acme.softbase.org> <1225459300.8437.79.camel@localhost> <200810311545.17419.g9ks157k@acme.softbase.org> Message-ID: <49116BE1.9070405@jellybean.co.uk> Wolfgang Jeltsch wrote: > Another point is that filterA uses just a single letter for ?arrow?. This > concept quickly leads to ambiguities. For example, in mappend, the ?m? > stands for ?monoid? while in msum, it stands for ?monad?. Something like > filterArrow would have the disadvantage that it is longer. With qualified > imports, the user of the library can decide whether to use a single letter > (A.filter) or something more descriptive (Arrow.filter). I would not like this. Let me first say that I *do* understand your point. It is certainly ugly to use these funny adhoc namespacing techniques. But I think it's less ugly than the alternatives we have, because: Our module system - or at least our module import/export system - is not sufficiently expressive. I would definitely not like to have to use Monoid.append Arrow.filter Monad.filter Monad.map ...just on grounds of verbosity. Too many characters = ugly code. But the alternative - to use short module aliases - does not scale well. I need to add appropriately qualified import statements to every single module in my project. We can't reexport qualifications. ;-( I'm interested in suggestions on how we could make our namespace management better so that this problem is more manageable. Jules From waldmann at imn.htwk-leipzig.de Wed Nov 5 16:34:52 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Wed Nov 5 16:29:52 2008 Subject: System[.Posix].Process question Message-ID: <4912117C.1090706@imn.htwk-leipzig.de> Hello. I am looking for something like System.Process.runInteractiveProcess (which gives me the in/out/err handles, which I like) but instead of ProcessHandle, I want a System.Posix.Types.ProcessID because I want to send a specific signal later. It seems that to a ProcessHandle I can only send SIGKILL (via System.Process.terminateProcess), and this is bad because the target process cannot intercept and handle it. In my case, it needs to cleanup (namely, kill its children). Thanks, J.W. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/libraries/attachments/20081105/86b7e747/signature.bin From qdunkan at gmail.com Wed Nov 5 18:08:58 2008 From: qdunkan at gmail.com (Evan Laforge) Date: Wed Nov 5 18:03:47 2008 Subject: darcs patch: Added list operations for arrows In-Reply-To: <49116BE1.9070405@jellybean.co.uk> References: <200810311326.55357.g9ks157k@acme.softbase.org> <1225459300.8437.79.camel@localhost> <200810311545.17419.g9ks157k@acme.softbase.org> <49116BE1.9070405@jellybean.co.uk> Message-ID: <2518b95d0811051508p7aaf271etef76dead07dd0577@mail.gmail.com> > I would definitely not like to have to use > > Monoid.append > Arrow.filter > Monad.filter > Monad.map > > ...just on grounds of verbosity. Too many characters = ugly code. I think that depends a lot on individual taste and what you're used to. The above looks fine to me (and I use that style exclusively in my own code, except infix operators). It would also probably look normal to any python programmer. Even though python supports both qualified and unqualified, the default is qualified, and it's what people are used to. > But the alternative - to use short module aliases - does not scale well. I > need to add appropriately qualified import statements to every single module > in my project. We can't reexport qualifications. Well, you do have to explicitly import every module you use, but that's true of unqualified import too, so I'm not sure what the not scaling part here is. Do you object to the idea that you have to give each module a name by hand and nothing stops you from being inconsistent about the names you give one module? I use the complete module name with a few exceptions, but even with that I sometimes have to put a bit of redundancy in module names to not conflict with a similar name in a neighbor package. Re-exporting qualified names doesn't seem like it would help... you'd still get name clashes unless it was done python style like Mod1.Mod2.f, but that's even more verbose. However, in a module that pulls together a lot of other modules using just one or two functions from each (which is the one likely to do lots of intra package imports and get clashes), I like the extra verbosity. The wider the scope of a name the longer it can be. It seems to scale just fine for me, and I have modules that import 40 or so other modules... in fact the more you import the more I appreciate qualified names. From dukedave at gmail.com Fri Nov 7 11:25:26 2008 From: dukedave at gmail.com (Dave Tapley) Date: Fri Nov 7 11:20:13 2008 Subject: Hello Message-ID: <1226075126.6364.4.camel@rubix.office.last.fm> Hi everyone, Just signed up to the list having attended the London HUG meet yesterday. You'll see me in #haskell as DukeDave. Looking forwards to helping with any menial non-expert tasks to help get some a Haskell platform up :) Dave, From duncan.coutts at worc.ox.ac.uk Fri Nov 7 12:04:02 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Nov 7 11:58:52 2008 Subject: Hello In-Reply-To: <1226075126.6364.4.camel@rubix.office.last.fm> References: <1226075126.6364.4.camel@rubix.office.last.fm> Message-ID: <1226077442.8437.359.camel@localhost> On Fri, 2008-11-07 at 16:25 +0000, Dave Tapley wrote: > Hi everyone, > > Just signed up to the list having attended the London HUG meet > yesterday. You'll see me in #haskell as DukeDave. Great. > Looking forwards to helping with any menial non-expert tasks to help get > some a Haskell platform up :) I guess we should start by listing the open questions on the wiki page. That'll help us with our discussion and gives us a place to record decisions. Duncan From waldmann at imn.htwk-leipzig.de Mon Nov 10 04:09:28 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Mon Nov 10 04:04:09 2008 Subject: parsec 3 vs. 2 - what's the deal? Message-ID: <4917FA48.4070308@imn.htwk-leipzig.de> Hello. Should I migrate from parsec-2 to parsec-3? Why? And if yes, then how? The hackage description (of version 3) says "it's well documented ... on the home page", but when I go there, I find docs for version 2 only. If I'm still using parsec-2 for teaching, will this harm my students? J.W. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/libraries/attachments/20081110/3c833ee6/signature-0001.bin From duncan.coutts at worc.ox.ac.uk Mon Nov 10 06:31:08 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Nov 10 06:25:55 2008 Subject: parsec 3 vs. 2 - what's the deal? In-Reply-To: <4917FA48.4070308@imn.htwk-leipzig.de> References: <4917FA48.4070308@imn.htwk-leipzig.de> Message-ID: <1226316668.17214.11.camel@localhost> On Mon, 2008-11-10 at 10:09 +0100, Johannes Waldmann wrote: > Hello. > > Should I migrate from parsec-2 to parsec-3? Why? And if yes, then how? I don't think there is any need to do so unless you need the extra features. The parsec-3 package is a somewhat experimental generalisation to a monad transformer that can be layered on top of other monadic input layers with state, effects etc. It has not yet had much optimisation and the performance for [Char] is reported to be slower. On the other hand it can now work with bytestring input or lexers which gives the potential for improved performance. > The hackage description (of version 3) says "it's well documented ... on > the home page", but when I go there, I find docs for version 2 only. The api is mostly compatible for parsers that stick to the Char subset and do not use the parsec-2 state feature. > If I'm still using parsec-2 for teaching, will this harm my students? No. GHC and the Haskell Platform will ship with parsec-2 until such a time as the community decides (via this mailing list) that we should all switch. The people proposing that change will have to make a convincing argument. Duncan From conal at conal.net Mon Nov 10 15:58:50 2008 From: conal at conal.net (Conal Elliott) Date: Mon Nov 10 15:53:23 2008 Subject: URL for latest package version? Message-ID: Now that hackage has caught up with ghc versions, I'd like my HaskellWiki project pages to link to hackage-based haddock docs instead of the docs I generate myself. (Hooray for inter-package doc links!) However, I don't know how to link to the latest version, rather than a specific one, such as http://hackage.haskell.org/packages/archive/vector-space/0.5/doc/html/Data-LinearMap.html Is there a trick that will help me out? Thanks, - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20081110/e25c90cf/attachment.htm From leather at cs.uu.nl Mon Nov 10 16:54:48 2008 From: leather at cs.uu.nl (Sean Leather) Date: Mon Nov 10 16:49:22 2008 Subject: URL for latest package version? In-Reply-To: References: Message-ID: <3c6288ab0811101354q2355110em89b5a3883fb39cf7@mail.gmail.com> > Now that hackage has caught up with ghc versions, I'd like my HaskellWiki > project pages to link to hackage-based haddock docs instead of the docs I > generate myself. (Hooray for inter-package doc links!) However, I don't > know how to link to the latest version, rather than a specific one > This is not really an answer to your question, but rather a suggestion of a different policy. I think it would be useful to have links to the docs for each version. Not everyone wants or needs the latest. You might also consider have a list or table with related links for each version, e.g. API, release announcement, and changes. IMHO, it's nice to have a perspective on the history of a project, not just the latest status. Regards, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20081110/06b80669/attachment.htm From waldmann at imn.htwk-leipzig.de Mon Nov 10 17:37:03 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Mon Nov 10 17:31:42 2008 Subject: Language.{Java,JVM} ? Message-ID: <4918B78F.1040501@imn.htwk-leipzig.de> We have Language.Haskell and Language.C - is there something similar for Java as well? For JVM Bytecode? Any hints appreciated - J.W. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/libraries/attachments/20081110/956bf6a7/signature.bin From david.maciver at gmail.com Mon Nov 10 20:33:33 2008 From: david.maciver at gmail.com (David MacIver) Date: Mon Nov 10 20:28:06 2008 Subject: Language.{Java,JVM} ? In-Reply-To: <4918B78F.1040501@imn.htwk-leipzig.de> References: <4918B78F.1040501@imn.htwk-leipzig.de> Message-ID: On 11/10/08, Johannes Waldmann wrote: > We have Language.Haskell and Language.C - is there > something similar for Java as well? For JVM Bytecode? > Any hints appreciated - J.W. There's some code for manipulating JVM bytecode in lambdavm. http://www.cs.rit.edu/~bja8464/lambdavm/ It is inconveniently licensed (GPL) and depends on a massive great big utils package by the author, so probably not the most useful of references, but maybe it's a suitable start. :-) From brian at brianweb.net Mon Nov 10 22:11:23 2008 From: brian at brianweb.net (Brian Alliet) Date: Mon Nov 10 22:05:55 2008 Subject: Language.{Java,JVM} ? In-Reply-To: References: <4918B78F.1040501@imn.htwk-leipzig.de> Message-ID: <20081111031123.GC41989@charger.brianweb.net> On Tue, Nov 11, 2008 at 01:33:33AM +0000, David MacIver wrote: > http://www.cs.rit.edu/~bja8464/lambdavm/ > > It is inconveniently licensed (GPL) and depends on a massive great big > utils package by the author, so probably not the most useful of > references, but maybe it's a suitable start. :-) Hey, I like my massive utils package. :) Here is the darcs repo: http://darcs.brianweb.net/hsjava/ (and the masstive utils repo: http://darcs.brianweb.net/hsutils/) I wouldn't mind relicensing it under the BSD license if necessary. -Brian From waldmann at imn.htwk-leipzig.de Tue Nov 11 05:35:48 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Tue Nov 11 05:33:45 2008 Subject: Language.{Java,JVM} ? In-Reply-To: <20081111031123.GC41989@charger.brianweb.net> References: <4918B78F.1040501@imn.htwk-leipzig.de> <20081111031123.GC41989@charger.brianweb.net> Message-ID: <49196004.6070703@imn.htwk-leipzig.de> > Here is the darcs repo: http://darcs.brianweb.net/hsjava/ Thanks, will look into it. I just need some AST representation of JVM code (as the target language for a toy/educational compiler) with a way to emit spec-conformant .class files. J.W. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/libraries/attachments/20081111/22810919/signature.bin From matti.niemenmaa+news at iki.fi Tue Nov 11 16:14:25 2008 From: matti.niemenmaa+news at iki.fi (Matti Niemenmaa) Date: Tue Nov 11 16:09:14 2008 Subject: Proposal #2769: Export mapAccumR from Data.Map, Data.IntMap Message-ID: Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2769 Discussion period: 1 week The `mapAccumR` function has been written in both the Data.Map and IntMap sources but it's commented out and not exported. This seems to be an error and I propose that it be simply uncommented. The issue can be worked around by using Data.List.mapAccumL on the descending list representation of the Map, but that's hardly optimal. Seems like a no-brainer to me, hence the short discussion period. From jpm at cs.uu.nl Thu Nov 13 04:18:16 2008 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Thu Nov 13 04:12:45 2008 Subject: Splitting SYB from the base package in GHC 6.10 In-Reply-To: <20081012103911.GA18317@matrix.chaos.earth.li> References: <638ABD0A29C8884A91BC5FB5C349B1C32AE88093CD@EA-EXMSG-C334.europe.corp.microsoft.com> <20080916084133.GA2878@soi.city.ac.uk> <20080922195449.GA22526@matrix.chaos.earth.li> <52f14b210809230603n5d7c2fa5ga6a791e48a27bcad@mail.gmail.com> <20080925155836.GA30388@matrix.chaos.earth.li> <52f14b210810040817p30893bb9vdb04aa6d57bc3702@mail.gmail.com> <52f14b210810060100w40f91dd3i27a63e2b10bc9ff5@mail.gmail.com> <52f14b210810100531q309ddc04v5d9e1f039d40db77@mail.gmail.com> <20081012103911.GA18317@matrix.chaos.earth.li> Message-ID: <52f14b210811130118k555388e2tb9d955905b461e19@mail.gmail.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: patchTypeable Type: application/octet-stream Size: 2592 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20081113/8afa23e5/patchTypeable-0001.obj From bart at cs.pdx.edu Fri Nov 14 20:25:50 2008 From: bart at cs.pdx.edu (Bart Massey) Date: Fri Nov 14 20:20:21 2008 Subject: More on Proposal #2717: Add nubWith, nubOrd Message-ID: As those who follow this list know, the consensus after discussion of Proposal #2717 was to just add nubOrd to Data.Set. Final question: should we add nubInt to Data.IntSet as well? It seems to me like the right thing to do, given the existence of Data.IntSet in the first place. Once this last question is answered, I will start a new proposal round with a "final" set of proposed patches. Bart Massey bart cs.pdx.edu From lane at downstairspeople.org Fri Nov 14 22:58:13 2008 From: lane at downstairspeople.org (Christopher Lane Hinson) Date: Fri Nov 14 22:52:33 2008 Subject: What to do about divMod'. In-Reply-To: References: Message-ID: Data.Fixed contains divMod' :: (Real a, Integral b) => a -> a -> (b, a) as well as div' and mod'. There are two problems: 1) Implementation of this type signature requires conversion to Rational, which is extremely slow. It really isn't usable in any kind of significant loop at all. 2) This has nothing specific to do with fixed precision arithmetic despite being in the Data.Fixed module. I played with writing a patch but I think this requires discussion. I believe the original author was aware of the problems and didn't consider them urgent. Should there be a RULES to address the performance issues? Should this be based on RealFrac or specific to Float, Double, etc? Alternately OR additionally should there be a separate set of functions created based on RealFrac? Another possibility is to change the signature of the divMod' family itself to use RealFrac instead of Real. This might break at compile time, but Rational is still an instance of RealFrac, so the fix would easy, and the performance penalty of calling to/fromRational would be visible in the calling code instead of hidden away. If we use RULES, this may make programs that depend on it effectively unusable without the optimizer. Whatever we do will probably change the semantics a bit in terms of infinite/NaN, but I don't think that is likely to matter. I personally prefer changing the signature of the divMod' family, but I anticipate objections. I also think that we should make sure that the divMod' family gets inlined as my understanding is this will avoid dictionary lookups and aid the strictness analyzer, but I'm not 100% certain on this point. Does a module (Data.Num?) need to be created to keep these? Thanks, --Lane From dons at galois.com Fri Nov 14 23:00:42 2008 From: dons at galois.com (Don Stewart) Date: Fri Nov 14 22:55:08 2008 Subject: What to do about divMod'. In-Reply-To: References: Message-ID: <20081115040042.GA13019@scytale.galois.com> lane: > > Data.Fixed contains divMod' :: (Real a, Integral b) => a -> a -> (b, a) > as well as div' and mod'. > > There are two problems: > > 1) Implementation of this type signature requires conversion to Rational, > which is extremely slow. It really isn't usable in any kind of > significant loop at all. > > 2) This has nothing specific to do with fixed precision arithmetic > despite being in the Data.Fixed module. > > I played with writing a patch but I think this requires discussion. I > believe the original author was aware of the problems and didn't consider > them urgent. > > Should there be a RULES to address the performance issues? Should this be > based on RealFrac or specific to Float, Double, etc? Alternately OR > additionally should there be a separate set of functions created based on > RealFrac? Almost certainly. Things like fromIntegral and truncate already have extensive type-based rules. > If we use RULES, this may make programs that depend on it effectively > unusable without the optimizer. Whatever we do will probably change the > semantics a bit in terms of infinite/NaN, but I don't think that is likely > to matter. Well, we make them the same as they currently are. > I personally prefer changing the signature of the divMod' family, but I > anticipate objections. > > I also think that we should make sure that the divMod' family gets inlined > as my understanding is this will avoid dictionary lookups and aid > the strictness analyzer, but I'm not 100% certain on this point. Check the core! -- Donn From allbery at ece.cmu.edu Sat Nov 15 00:20:27 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sat Nov 15 00:14:49 2008 Subject: What to do about divMod'. In-Reply-To: References: Message-ID: <35E81F9A-3F89-4F1E-81AD-60AFE75B02F3@ece.cmu.edu> On 2008 Nov 14, at 22:58, Christopher Lane Hinson wrote: > Data.Fixed contains divMod' :: (Real a, Integral b) => a -> a -> (b, > a) > as well as div' and mod'. > > There are two problems: > > 1) Implementation of this type signature requires conversion to > Rational, which is extremely slow. It really isn't usable in any > kind of significant loop at all. I dunno, Data.Fixed seems to me to be Rational's cousin, and I can also see how divMod' would be needed to implement Fixed. > 2) This has nothing specific to do with fixed precision arithmetic > despite being in the Data.Fixed module. Last I checked the Haddock noted that it has wider use than Data.Fixed. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From rfhayes at reillyhayes.com Sat Nov 15 10:25:03 2008 From: rfhayes at reillyhayes.com (R Hayes) Date: Sat Nov 15 10:19:23 2008 Subject: HsOpenSSL Build Failure Message-ID: I'm trying to build HsOpenSSL-0.4.2 under 6.10.1. The build fails out of the box due to GHC.Prim now being in package ghc-prim. I added ghc- prim to the Cabal file and ran the build. It fails as follows: [12 of 29] Compiling OpenSSL.BN ( dist/build/OpenSSL/BN.hs, dist/ build/OpenSSL/BN.o ) OpenSSL/BN.hsc:172:29: Not in scope: data constructor `S#' OpenSSL/BN.hsc:173:34: Not in scope: data constructor `S#' OpenSSL/BN.hsc:183:23: Not in scope: data constructor `J#' OpenSSL/BN.hsc:184:28: Not in scope: data constructor `J#' OpenSSL/BN.hsc:203:13: Not in scope: data constructor `S#' OpenSSL/BN.hsc:218:15: Not in scope: data constructor `J#' Any advice? From dons at galois.com Sat Nov 15 14:34:45 2008 From: dons at galois.com (Don Stewart) Date: Sat Nov 15 14:29:01 2008 Subject: Arch Haskell News: Nov 2 - Nov 15, 2008 Message-ID: <20081115193445.GF15077@scytale.galois.com> News about Haskell on Arch Linux http://archhaskell.wordpress.com/2008/11/15/arch-haskell-news-nov-15-2008/ Arch now has 705 Haskell packages in AUR. That?s an increase of (again) 33 new packages in the last 14 days. Growth appears to be holding steady at just over 2 new packages a day on Hackage in the first part of November. Noteworthy * haskell-icalendar-0.0: ?Parser for iCalendar format (RFC2445)? * haskell-hmatrix-0.5.0.1: ?Linear algebra and numerical computations? * haskell-flickr-0.2.2: ?Haskell binding to the Flickr API? * gitit-0.2.2.1: ?Wiki using HAppS, git, and pandoc.? * haskell-happs-server-0.9.3: ?Web related tools and services.? * haddock-2.4.1: ?A documentation-generation tool for Haskell libraries? And lots of others. From dons at galois.com Sat Nov 15 14:46:16 2008 From: dons at galois.com (Don Stewart) Date: Sat Nov 15 14:40:33 2008 Subject: HsOpenSSL Build Failure In-Reply-To: References: Message-ID: <20081115194616.GI15077@scytale.galois.com> rfhayes: > > > I'm trying to build HsOpenSSL-0.4.2 under 6.10.1. The build fails out > of the box due to GHC.Prim now being in package ghc-prim. I added ghc- > prim to the Cabal file and ran the build. It fails as follows: > > [12 of 29] Compiling OpenSSL.BN ( dist/build/OpenSSL/BN.hs, dist/ > build/OpenSSL/BN.o ) > > OpenSSL/BN.hsc:172:29: Not in scope: data constructor `S#' > > OpenSSL/BN.hsc:173:34: Not in scope: data constructor `S#' > > OpenSSL/BN.hsc:183:23: Not in scope: data constructor `J#' > > OpenSSL/BN.hsc:184:28: Not in scope: data constructor `J#' > > OpenSSL/BN.hsc:203:13: Not in scope: data constructor `S#' > > OpenSSL/BN.hsc:218:15: Not in scope: data constructor `J#' Needs to import GHC/Integer/Internals.hs from the integer package. From haskell at list.mightyreason.com Sat Nov 15 18:02:21 2008 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Sat Nov 15 17:56:45 2008 Subject: Version 1.0.0 of Haskell "port" of Google Protocol-Buffers Message-ID: <491F54FD.1090605@list.mightyreason.com> Hello one and all, Amid much editing, my Haskell version of protocol-buffer is now released at version 1.0.0. This version supports the feaures of Google's version 2.0.2 including the new extensible options. What is this for? What does it do? Why? It generates Haskell data types that can be converted back and forth to lazy ByteStrings that interoperate with Google's generated code in C++/Java/python. The data types are defined in a ".proto" text file which is translated into the target language. My code is a pure Haskell re-implementation of the Google code at http://code.Google.com/apis/protocolbuffers/docs/overview.html which is "...a language-neutral, platform-neutral, extensible way of serializing structured data for use in communications protocols, data storage, and more." Google's project produces C++, Java, and Python code. This one produces Haskell code. Where is the code? http://hackage.haskell.org/cgi-bin/hackage-scripts/package/protocol-buffers http://hackage.haskell.org/cgi-bin/hackage-scripts/package/protocol-buffers-descriptor http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hprotoc-1.0.0 And it needs to be build and installed in the above order. The first is the support library (Text.ProtocolBuffers). The second is the self-describing descriptor library (Text.DescriptorProtos[.Options]). The third is the 'hprotoc' executable which translates the ".proto" files into Haskell code. This works similarly to the "protoc" program from the original Google project. Cheers, Chris From ross at soi.city.ac.uk Sat Nov 15 19:01:54 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sat Nov 15 18:56:13 2008 Subject: Proposal #2769: Export mapAccumR from Data.Map, Data.IntMap In-Reply-To: References: Message-ID: <20081116000154.GB11142@soi.city.ac.uk> On Tue, Nov 11, 2008 at 11:14:25PM +0200, Matti Niemenmaa wrote: > Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2769 > Discussion period: 1 week > > The `mapAccumR` function has been written in both the Data.Map and > IntMap sources but it's commented out and not exported. This seems to > be an error and I propose that it be simply uncommented. > > The issue can be worked around by using Data.List.mapAccumL on the > descending list representation of the Map, but that's hardly optimal. Data.Traversable.mapAccumR also works on maps, but has a different type (matching the one on lists, and Data.Map.mapAccum). I would suggest that mapAccumRWithKey would be a consistent name for this one. > Seems like a no-brainer to me, hence the short discussion period. I think a week is too short, even for no-brainers. People take breaks. From ndmitchell at gmail.com Sun Nov 16 04:03:28 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sun Nov 16 03:57:44 2008 Subject: More on Proposal #2717: Add nubWith, nubOrd In-Reply-To: References: Message-ID: <404396ef0811160103r2f0d6e5dg8a66581b0e21ca1b@mail.gmail.com> Hi Bart, > As those who follow this list know, the consensus after discussion of Proposal > #2717 was to just add nubOrd to Data.Set. Final question: should we add nubInt > to Data.IntSet as well? It seems to me like the right thing to do, given the > existence of Data.IntSet in the first place. Yes, seems very sensible! Thanks Neil From matti.niemenmaa+news at iki.fi Sun Nov 16 04:24:54 2008 From: matti.niemenmaa+news at iki.fi (Matti Niemenmaa) Date: Sun Nov 16 04:19:24 2008 Subject: Proposal #2769: Export mapAccumR from Data.Map, Data.IntMap In-Reply-To: <20081116000154.GB11142@soi.city.ac.uk> References: <20081116000154.GB11142@soi.city.ac.uk> Message-ID: Ross Paterson wrote: > Data.Traversable.mapAccumR also works on maps, but has a different type > (matching the one on lists, and Data.Map.mapAccum). I would suggest > that mapAccumRWithKey would be a consistent name for this one. Handy, I didn't know that. In that light I agree with you on the name. > I think a week is too short, even for no-brainers. People take breaks. I'm not in any particular hurry: let's then say two weeks, for now. From igloo at earth.li Sun Nov 16 11:23:29 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Nov 16 11:17:44 2008 Subject: Splitting SYB from the base package in GHC 6.10 In-Reply-To: <52f14b210811130118k555388e2tb9d955905b461e19@mail.gmail.com> References: <20080916084133.GA2878@soi.city.ac.uk> <20080922195449.GA22526@matrix.chaos.earth.li> <52f14b210809230603n5d7c2fa5ga6a791e48a27bcad@mail.gmail.com> <20080925155836.GA30388@matrix.chaos.earth.li> <52f14b210810040817p30893bb9vdb04aa6d57bc3702@mail.gmail.com> <52f14b210810060100w40f91dd3i27a63e2b10bc9ff5@mail.gmail.com> <52f14b210810100531q309ddc04v5d9e1f039d40db77@mail.gmail.com> <20081012103911.GA18317@matrix.chaos.earth.li> <52f14b210811130118k555388e2tb9d955905b461e19@mail.gmail.com> Message-ID: <20081116162329.GA2574@matrix.chaos.earth.li> Hi Pedro, On Thu, Nov 13, 2008 at 10:18:16AM +0100, Jos? Pedro Magalh?es wrote: > > Yet another haddock documentation fix: the link from Data.Typeable was > broken (went to Data.Generics, which is no longer in base; corrected to > Data.Data). Applied, thanks! Thanks Ian From judah.jacobson at gmail.com Sun Nov 16 13:27:10 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Sun Nov 16 13:21:26 2008 Subject: darcs patch: filling out the extensible exceptions library Message-ID: <6d74b0d20811161027w65f4e2ceseb97676a31a7f309@mail.gmail.com> Hi all, Attached are some patches for the extensible-exceptions library, which lets packages use the new exceptions API portably on all versions of ghc (well, at least as far back as 6.6.1, from my tests). To summarize: I filled out the API by copying all of the missing functions from base4:Control.Exception, and edited the .cabal file to make 'cabal install extensible-exceptions' do the right thing. Also, I'm eager to have this package on hackage so that I can start using it in my own libraries; let me know if there's anything else I could do to work towards that goal. Thanks, -Judah Sun Nov 16 09:52:02 PST 2008 Judah Jacobson * Bump the library version to 0.1.1.0. M ./extensible-exceptions.cabal -1 +1 Sat Nov 15 16:49:25 PST 2008 Judah Jacobson * Copy all of the missing functionality/documentation from base4:Control.Exception. M ./Control/Exception/Extensible.hs -21 +358 Sat Nov 15 16:47:04 PST 2008 Judah Jacobson * Update the package description in the .cabal file. M ./extensible-exceptions.cabal -4 +2 Sat Nov 15 10:59:27 PST 2008 Judah Jacobson * Hide some functions which are not possible to implement under the old API. M ./Control/Exception/Extensible.hs -1 +1 Sat Nov 15 10:52:57 PST 2008 Judah Jacobson * Use Cabal flags to select which version of Control.Exception to build on top of. This ensures that cabal-install will use the correct version of base. M ./Control/Exception/Extensible.hs -1 +1 M ./extensible-exceptions.cabal -1 +5 -------------- next part -------------- A non-text attachment was scrubbed... Name: exceptions.patch Type: application/octet-stream Size: 19718 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20081116/7d5e40f2/exceptions-0001.obj From igloo at earth.li Sun Nov 16 16:01:50 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Nov 16 15:56:11 2008 Subject: darcs patch: filling out the extensible exceptions library In-Reply-To: <6d74b0d20811161027w65f4e2ceseb97676a31a7f309@mail.gmail.com> References: <6d74b0d20811161027w65f4e2ceseb97676a31a7f309@mail.gmail.com> Message-ID: <20081116210150.GA23627@matrix.chaos.earth.li> On Sun, Nov 16, 2008 at 10:27:10AM -0800, Judah Jacobson wrote: > > Attached are some patches for the extensible-exceptions library Thanks, all applied. > Also, I'm eager to have this package on hackage I've uploaded it. Thanks Ian From leegys at gmail.com Tue Nov 18 00:27:05 2008 From: leegys at gmail.com (Gyesik Lee) Date: Tue Nov 18 00:21:14 2008 Subject: problem in installing readline Message-ID: Hello, I am really sorry for bothering you with this kind of question, but I here have no one to ask about readline. Indeed I am trying to install Agda which requires readline 1.0.1.0. But I can neither use cabal nor install it manually. Here are the error messages. It would be really nice if you could give some advices. Thank you very much in advance. Best regards, Gyesik ============= dhcpa11098:Agda leegy$ sudo cabal install readline Password: Resolving dependencies... 'readline-1.0.1.0' is cached. Configuring readline-1.0.1.0... checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for GNUreadline.framework... checking for readline... no checking for tputs in -lncurses... yes checking for readline in -lreadline... yes checking for rl_readline_version... yes checking for rl_begin_undo_group... no configure: error: readline not found, so this package cannot be built See `config.log' for more details. cabal: Error: some packages failed to install: readline-1.0.1.0 failed during the configure step. The exception was: exit: ExitFailure 1 From allbery at ece.cmu.edu Tue Nov 18 01:01:46 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue Nov 18 00:56:04 2008 Subject: problem in installing readline In-Reply-To: References: Message-ID: On 2008 Nov 18, at 0:27, Gyesik Lee wrote: > I am really sorry for bothering you with this kind of question, but I > here have no one to ask about readline. > > Indeed I am trying to install Agda which requires readline 1.0.1.0. > But I can neither use cabal nor install it manually. The Haskell readline package is a wrapper around the GNU readline library. If you're running Linux, you need to install readline and readline-devel (or readline-dev) packages. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From judah.jacobson at gmail.com Tue Nov 18 01:16:27 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Tue Nov 18 01:10:38 2008 Subject: problem in installing readline In-Reply-To: References: Message-ID: <6d74b0d20811172216w3e03dabficf642da920fe7204@mail.gmail.com> On Mon, Nov 17, 2008 at 9:27 PM, Gyesik Lee wrote: > Hello, > > I am really sorry for bothering you with this kind of question, but I > here have no one to ask about readline. > > Indeed I am trying to install Agda which requires readline 1.0.1.0. > But I can neither use cabal nor install it manually. > > Here are the error messages. > > It would be really nice if you could give some advices. > Thank you very much in advance. > > Best regards, > > Gyesik > >From your configure log, I'm guessing you might be running on OS X. If that's the case: The issue is that OS X ships with a version of libreadline (really, a wrapper around the libedit library) which is not useable by the Haskell readline package. You can fix this by installing a "real" version of readline; either download and install from ftp://ftp.cwru.edu/pub/bash/readline-5.2.tar.gz , or else install GNUreadline.framework from: http://www.haskell.org/ghc/dist/mac_frameworks/mac_e.htm -Judah From gyesik.lee at aist.go.jp Tue Nov 18 01:35:49 2008 From: gyesik.lee at aist.go.jp (Gyesik Lee) Date: Tue Nov 18 01:30:08 2008 Subject: problem in installing readline In-Reply-To: <6d74b0d20811172216w3e03dabficf642da920fe7204@mail.gmail.com> References: <6d74b0d20811172216w3e03dabficf642da920fe7204@mail.gmail.com> Message-ID: Thank you very much Judah and Brandon. And sorry for not having mentioned that I am using mac OS X. I followed the Judah's suggestions. The second one is successful while the first one stops with the error message below. (during building) It seems that mac OS X is not so compatible. Anyway, I installed readline. Thank you very for your great help. Gyesik ============ dhcpa11098:readline-5.2 leegy$ make test -d shlib || mkdir shlib ( cd shlib ; make all ) rm -f libreadline.5.2.dylib gcc -dynamic -arch_only `/usr/bin/arch` -install_name /usr/local/lib/libreadline.5.2.dylib -current_version 5.2 -compatibility_version 5 -v -o libreadline.5.2.dylib readline.so vi_mode.so funmap.so keymaps.so parens.so search.so rltty.so complete.so bind.so isearch.so display.so signals.so util.so kill.so undo.so macro.so input.so callback.so terminal.so text.so nls.so misc.so xmalloc.so history.so histexpand.so histfile.so histsearch.so shell.so mbutil.so tilde.so compat.so -lncurses Using built-in specs. Target: i686-apple-darwin9 Configured with: /var/tmp/gcc/gcc-5465~16/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic --host=i686-apple-darwin9 --target=i686-apple-darwin9 Thread model: posix gcc version 4.0.1 (Apple Inc. build 5465) i686-apple-darwin9-gcc-4.0.1: -compatibility_version only allowed with -dynamiclib make[1]: *** [libreadline.5.2.dylib] Error 1 make: [shared] Error 2 (ignored) On Tue, Nov 18, 2008 at 3:16 PM, Judah Jacobson wrote: > On Mon, Nov 17, 2008 at 9:27 PM, Gyesik Lee wrote: >> Hello, >> >> I am really sorry for bothering you with this kind of question, but I >> here have no one to ask about readline. >> >> Indeed I am trying to install Agda which requires readline 1.0.1.0. >> But I can neither use cabal nor install it manually. >> >> Here are the error messages. >> >> It would be really nice if you could give some advices. >> Thank you very much in advance. >> >> Best regards, >> >> Gyesik >> > > From your configure log, I'm guessing you might be running on OS X. > If that's the case: The issue is that OS X ships with a version of > libreadline (really, a wrapper around the libedit library) which is > not useable by the Haskell readline package. > > You can fix this by installing a "real" version of readline; either > download and install from > ftp://ftp.cwru.edu/pub/bash/readline-5.2.tar.gz , or else install > GNUreadline.framework from: > > http://www.haskell.org/ghc/dist/mac_frameworks/mac_e.htm > > -Judah > From stefan at cs.uu.nl Wed Nov 19 09:06:04 2008 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Wed Nov 19 09:00:10 2008 Subject: base-3.0.3.0 not backwards compatible with base-3.0.2.0 Message-ID: <785D3E0E-FDBD-4E12-B84D-1CD3742B9D91@cs.uu.nl> Hi all, Could anyone confirm the following claims? * base-3.0.3.0 (shipped with GHC 6.10.1) is supposed to be backwards compatible with base-3.0.2.0 (shipped with GHC 6.8.3) ... * ... but it isn't! (For example, the Arrow class from Control.Arrow is a subclass of Category from Control.Category in base-3.0.3.0, but not in base-3.0.2.0.) Do we know of any similar issues? What's the recommended workaround when shipping code that is to support both GHC 6.8.* and GHC 6.10.*?) Thanks, Stefan From igloo at earth.li Wed Nov 19 09:21:10 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Nov 19 09:15:15 2008 Subject: base-3.0.3.0 not backwards compatible with base-3.0.2.0 In-Reply-To: <785D3E0E-FDBD-4E12-B84D-1CD3742B9D91@cs.uu.nl> References: <785D3E0E-FDBD-4E12-B84D-1CD3742B9D91@cs.uu.nl> Message-ID: <20081119142110.GA27828@matrix.chaos.earth.li> On Wed, Nov 19, 2008 at 03:06:04PM +0100, Stefan Holdermans wrote: > > Could anyone confirm the following claims? > > * base-3.0.3.0 (shipped with GHC 6.10.1) is supposed to be backwards > compatible with base-3.0.2.0 (shipped with GHC 6.8.3) ... Yes. > * ... but it isn't! (For example, the Arrow class from Control.Arrow > is a subclass of Category from Control.Category in base-3.0.3.0, but > not in base-3.0.2.0.) Yes. It wasn't possible to handle this change in a compatible way, I'm afraid. > Do we know of any similar issues? I think the Arrow/Category changes are the only issue. I think one of the methods moved from one class to the other as well. > What's the recommended workaround > when shipping code that is to support both GHC 6.8.* and GHC 6.10.*?) CPP is the best solution I can think of. Thanks Ian From simonpj at microsoft.com Fri Nov 21 07:34:42 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Nov 21 07:28:47 2008 Subject: Generics Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33192419C62@EA-EXMSG-C334.europe.corp.microsoft.com> Jose As part of your work on the SYB library, could you spare the time to look into these two library bug reports? http://hackage.haskell.org/trac/ghc/ticket/2759 http://hackage.haskell.org/trac/ghc/ticket/2760 Many thanks Simon From jpm at cs.uu.nl Fri Nov 21 10:29:39 2008 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Fri Nov 21 10:23:40 2008 Subject: Generics In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C33192419C62@EA-EXMSG-C334.europe.corp.microsoft.com> References: <638ABD0A29C8884A91BC5FB5C349B1C33192419C62@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <52f14b210811210729g5c80afbam93d2b7a7f0ccbca5@mail.gmail.com> Hello Simon, Thanks for pointing these out to me. I won't be able to look into this for the next week, but from what I could see so far, #2760 seems easy: copy mkNorepType to mkNoRepType, mark mkNorepType as deprecated and replace usage everywhere to avoid warnings and pass validation. I can submit the patch for this. #2759 has some deeper implications, though. Replacing the FloatConstr Double by FloatConstr Rational might break existing client code (even though it probably wouldn't be too hard to fix it). Additionally, I see that the serializer code in compiler/utils/Serialized.hs would also need changes (it's no longer serializing a Double). But I guess this is also not too problematic... Cheers, Pedro On Fri, Nov 21, 2008 at 13:34, Simon Peyton-Jones wrote: > Jose > > As part of your work on the SYB library, could you spare the time to look > into these two library bug reports? > > http://hackage.haskell.org/trac/ghc/ticket/2759 > http://hackage.haskell.org/trac/ghc/ticket/2760 > > Many thanks > > Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20081121/2f9cc1dd/attachment-0001.htm From simonpj at microsoft.com Fri Nov 21 12:28:57 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Nov 21 12:23:00 2008 Subject: Generics In-Reply-To: <52f14b210811210729g5c80afbam93d2b7a7f0ccbca5@mail.gmail.com> References: <638ABD0A29C8884A91BC5FB5C349B1C33192419C62@EA-EXMSG-C334.europe.corp.microsoft.com> <52f14b210811210729g5c80afbam93d2b7a7f0ccbca5@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33192419EAE@EA-EXMSG-C334.europe.corp.microsoft.com> Thanks. And here is one more http://hackage.haskell.org/trac/ghc/ticket/2750 For potentially-breaking changes the right thing to do is to announce (and justify) the proposed change using the usual library-change protocol, with a discussion period. The important thing is that someone is driving the discussion -- thank you very much for that. I'll assign these tickets to you. Simon From: josepedromagalhaes@gmail.com [mailto:josepedromagalhaes@gmail.com] On Behalf Of Jos? Pedro Magalh?es Sent: 21 November 2008 15:30 To: Simon Peyton-Jones Cc: libraries@haskell.org; Generics Mailing List Subject: Re: Generics Hello Simon, Thanks for pointing these out to me. I won't be able to look into this for the next week, but from what I could see so far, #2760 seems easy: copy mkNorepType to mkNoRepType, mark mkNorepType as deprecated and replace usage everywhere to avoid warnings and pass validation. I can submit the patch for this. #2759 has some deeper implications, though. Replacing the FloatConstr Double by FloatConstr Rational might break existing client code (even though it probably wouldn't be too hard to fix it). Additionally, I see that the serializer code in compiler/utils/Serialized.hs would also need changes (it's no longer serializing a Double). But I guess this is also not too problematic... Cheers, Pedro On Fri, Nov 21, 2008 at 13:34, Simon Peyton-Jones > wrote: Jose As part of your work on the SYB library, could you spare the time to look into these two library bug reports? http://hackage.haskell.org/trac/ghc/ticket/2759 http://hackage.haskell.org/trac/ghc/ticket/2760 Many thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20081121/8547647c/attachment.htm From gwern0 at gmail.com Sun Nov 23 22:53:34 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Sun Nov 23 22:47:24 2008 Subject: template-haskell depends on packedstring Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 So I was trying to compile lambdabot with cabal-install. Lambdabot uses Template Haskell for generating some boilerplate, and it was a failed dependency. Template Haskell uses packedstring for... something... and packedstring was a failed dependency: Data/PackedString.hs:83:7: Could not find module `Data.Data': it is a member of package base, which is hidden Now this is a problem, but it's not the problem I am interested in. I am interested in: why is template-haskell using packedstring? Wasn't packedstring obsoleted years ago? I downloaded the TH tarball to see what fascinating things it was using packedstring for, and I found that it's hardly doing anything - it apparently is just encoding module (ModName) and OccName (whatever that is), and then the other functions shift back from PackedString/ModName-OccName to String. (This is all in Language/Haskell/TH/Syntax.hs) I replaced all the PackedString stuff with normal ol' String and compiled fine, and indeed seems to work fine at Template-Haskelly stuff. So here's my suggestions: 1) Remove the packedstring dep and calls from the TH code. It is useless, it shackles the package to a long obsolete one, and so on. Even if we assume that the packedstring code is still faster than native String, and that there's no performance penalty for the conversions back and forth from String to PackedString, and that the possible size increase from linking in PackedString code is not worth worrying about, and we also assume that PackedString is being used on Names large enough to make up for any overhead - even if we assume all that, TH is a compile-time process and so it doesn't matter all that much if we shave a few microseconds off one small part of the compilation process. Installability and cleaner code would be worth that price. 2) If just String is not acceptable, then I understand from dons that the reason we can't use just plain ol' ByteString is because the Names may well be in UTF-8, and ByteString's [Word8]s apparently don't treat that well. Given that, we need some sort of UTF8 bytestring. As it happens, we do in fact have such a thing: Data.ByteString.UTF8 . It looks a bit incomplete, but utf8-string in general is pretty widely-used and reliable (also builds on 6.10): just about every XMonad user uses XMonadContrib which uses utf8-string, and I can count the number of complaints because utf8-string on one hand. Thoughts? I searched thoroughly through various bug-trackers and mailing lists, but this doesn't seem to've come up before. - -- gwern -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREKAAYFAkkqJTsACgkQvpDo5Pfl1oLYoQCgjRSqno+DtyZiLbAS5Pk4l8Ao sqkAn15sBq+alBy5ZVLHIMthjZ6eU6E6 =N8Qj -----END PGP SIGNATURE----- From dons at galois.com Sun Nov 23 23:25:13 2008 From: dons at galois.com (Don Stewart) Date: Sun Nov 23 23:19:09 2008 Subject: Arch Haskell News: Nov 23 2008 Message-ID: <20081124042513.GA23604@scytale.galois.com> News about Haskell on Arch Linux * Arch now has 734 Haskell packages now * That?s an increase of 29 new packages in the last 8 days! * 3.6 new Haskell releases are occuring each day. Noteworthy, * haskell-hledger-0.2: ?A ledger-compatible text-based accounting tool.? * gitit-0.3.1: ?Wiki using HAppS, git, and pandoc.? * lhc-20081121: ?Lhc Haskell Compiler? * haskell-hosc-0.6: ?Haskell Open Sound Control? * haskell-flickr-0.3.2: ?Haskell binding to the Flickr API? * haskell-delicious-0.3.2: ?Accessing the del.icio.us APIs from Haskell (v2)? * haskell-mediawiki 0.2.3: ?Interfacing with the MediaWiki API? * darcs-2.1.2.2: ?a distributed, interactive, smart revision control system? Full update list, http://archhaskell.wordpress.com/2008/11/24/arch-haskell-news-nov-23-2008/ -- Don From simons at cryp.to Mon Nov 24 06:33:22 2008 From: simons at cryp.to (Peter Simons) Date: Mon Nov 24 06:27:22 2008 Subject: How to expose cabal-generated installation paths? Message-ID: <87hc5xe4u5.fsf@write-only.cryp.to> Hi, please pardon me if this question is not appropriate for this forum or if there is a document that answers my question already. I had no better idea but to ask here and I'd be happy to receive pointers into the right direction. Recently, I received a patch for the FuncMP package [1] that exposes the Cabal-generated "Paths_funcmp" module. It appears, however, that Cabal doesn't find that module when running the 'haddock' target: | Creating dist/doc/html/funcmp (and its parents) | Preprocessing library funcmp-1.2... | Running hscolour for funcmp-1.2... | Creating dist/doc/html/funcmp/src (and its parents) | /usr/local/bin/HsColour -print-css -odist/doc/html/funcmp/src/hscolour.css | cabal-setup: can't find source for module Paths_funcmp The complete log is available at [2]. Does anyone know, by any chance, a simple way to remedy that problem? Peter [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/funcmp [2] http://hackage.haskell.org/packages/archive/funcmp/1.2/logs/failure/ghc-6.10 From james.swaine at gmail.com Tue Nov 25 04:24:53 2008 From: james.swaine at gmail.com (James Swaine) Date: Tue Nov 25 04:18:41 2008 Subject: Data Parallel Haskell Message-ID: <5195fdde0811250124hd6d6111l34b5e3c0afb7f534@mail.gmail.com> Does anyone know if this library is being actively maintained? We had some trouble getting it to build with the 6.10 sources, and it didn't look it had been updated in a while, so I guess I just wanted to check and see if anyone knew about it. Thanks all! James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20081125/93019f0d/attachment.htm From simonpj at microsoft.com Tue Nov 25 05:07:16 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Nov 25 05:01:06 2008 Subject: Data Parallel Haskell In-Reply-To: <5195fdde0811250124hd6d6111l34b5e3c0afb7f534@mail.gmail.com> References: <5195fdde0811250124hd6d6111l34b5e3c0afb7f534@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C331927EEA39@EA-EXMSG-C334.europe.corp.microsoft.com> Very much actively! Roman is working hard on the library right now. I'm ccing him. Simon From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of James Swaine Sent: 25 November 2008 09:25 To: libraries@haskell.org Subject: Data Parallel Haskell Does anyone know if this library is being actively maintained? We had some trouble getting it to build with the 6.10 sources, and it didn't look it had been updated in a while, so I guess I just wanted to check and see if anyone knew about it. Thanks all! James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20081125/e529314b/attachment.htm From james.swaine at gmail.com Tue Nov 25 12:23:29 2008 From: james.swaine at gmail.com (James Swaine) Date: Tue Nov 25 12:17:35 2008 Subject: Data Parallel Haskell In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C331927EEA39@EA-EXMSG-C334.europe.corp.microsoft.com> References: <5195fdde0811250124hd6d6111l34b5e3c0afb7f534@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C331927EEA39@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <5195fdde0811250923t1eb34d79y779f99433e8912a4@mail.gmail.com> are any of you guys able to get it to compile (with 6.10 or 6.8.3)? we get what looks like some build errors coming from the ndp source. just wanted to check and see if it's something we're doing wrong or not. thanks all, james On Tue, Nov 25, 2008 at 4:07 AM, Simon Peyton-Jones wrote: > Very much actively! Roman is working hard on the library right now. > I'm ccing him. > > > > Simon > > > > *From:* libraries-bounces@haskell.org [mailto: > libraries-bounces@haskell.org] *On Behalf Of *James Swaine > *Sent:* 25 November 2008 09:25 > *To:* libraries@haskell.org > *Subject:* Data Parallel Haskell > > > > Does anyone know if this library is being actively maintained? We had some > trouble getting it to build with the 6.10 sources, and it didn't look it had > been updated in a while, so I guess I just wanted to check and see if anyone > knew about it. > > Thanks all! > James > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20081125/53bf4c55/attachment-0001.htm From james.swaine at gmail.com Tue Nov 25 12:24:45 2008 From: james.swaine at gmail.com (James Swaine) Date: Tue Nov 25 12:18:44 2008 Subject: Data Parallel Haskell In-Reply-To: <5195fdde0811250923t1eb34d79y779f99433e8912a4@mail.gmail.com> References: <5195fdde0811250124hd6d6111l34b5e3c0afb7f534@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C331927EEA39@EA-EXMSG-C334.europe.corp.microsoft.com> <5195fdde0811250923t1eb34d79y779f99433e8912a4@mail.gmail.com> Message-ID: <5195fdde0811250924i3fa6a0ahe6c21b92cde4c6d7@mail.gmail.com> specifically - the errors have to do with the interface for a type 'BBArr'. it also looks like some deprecated flags are being passed to ghc to enable the parallel extensions, when -XPArr should be used. i thought maybe we didn't have the latest version of the source, but darcs tells us that it's current...weird. thanks, james On Tue, Nov 25, 2008 at 11:23 AM, James Swaine wrote: > are any of you guys able to get it to compile (with 6.10 or 6.8.3)? we get > what looks like some build errors coming from the ndp source. just wanted > to check and see if it's something we're doing wrong or not. > > thanks all, > james > > On Tue, Nov 25, 2008 at 4:07 AM, Simon Peyton-Jones < > simonpj@microsoft.com> wrote: > >> Very much actively! Roman is working hard on the library right now. >> I'm ccing him. >> >> >> >> Simon >> >> >> >> *From:* libraries-bounces@haskell.org [mailto: >> libraries-bounces@haskell.org] *On Behalf Of *James Swaine >> *Sent:* 25 November 2008 09:25 >> *To:* libraries@haskell.org >> *Subject:* Data Parallel Haskell >> >> >> >> Does anyone know if this library is being actively maintained? We had >> some trouble getting it to build with the 6.10 sources, and it didn't look >> it had been updated in a while, so I guess I just wanted to check and see if >> anyone knew about it. >> >> Thanks all! >> James >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20081125/580b736f/attachment.htm From duncan.coutts at worc.ox.ac.uk Tue Nov 25 15:21:51 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Nov 25 15:15:42 2008 Subject: template-haskell depends on packedstring In-Reply-To: References: Message-ID: <1227644511.19577.24.camel@localhost> On Sun, 2008-11-23 at 22:53 -0500, Gwern Branwen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > So I was trying to compile lambdabot with cabal-install. Lambdabot > uses Template Haskell for generating some boilerplate, and it was a > failed dependency. Template Haskell uses packedstring for... > something... and packedstring was a failed dependency: > Data/PackedString.hs:83:7: > Could not find module `Data.Data': > it is a member of package base, which is hidden > > Now this is a problem, but it's not the problem I am interested in. I > am interested in: why is template-haskell using packedstring? Wasn't > packedstring obsoleted years ago? Yes. The question is if one should break the TH api just to remove this deprecated dependency. Especially when it is slated to be replaced with an improved unicode packed string type in the future. So either we break it once, or twice. Duncan From duncan.coutts at worc.ox.ac.uk Tue Nov 25 15:25:24 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Nov 25 15:19:14 2008 Subject: How to expose cabal-generated installation paths? In-Reply-To: <87hc5xe4u5.fsf@write-only.cryp.to> References: <87hc5xe4u5.fsf@write-only.cryp.to> Message-ID: <1227644724.19577.28.camel@localhost> On Mon, 2008-11-24 at 12:33 +0100, Peter Simons wrote: > Hi, > > please pardon me if this question is not appropriate for this forum or > if there is a document that answers my question already. I had no better > idea but to ask here and I'd be happy to receive pointers into the right > direction. > > Recently, I received a patch for the FuncMP package [1] that exposes the > Cabal-generated "Paths_funcmp" module. It appears, however, that Cabal > doesn't find that module when running the 'haddock' target: > > | Creating dist/doc/html/funcmp (and its parents) > | Preprocessing library funcmp-1.2... > | Running hscolour for funcmp-1.2... > | Creating dist/doc/html/funcmp/src (and its parents) > | /usr/local/bin/HsColour -print-css -odist/doc/html/funcmp/src/hscolour.css > | cabal-setup: can't find source for module Paths_funcmp > > The complete log is available at [2]. > > Does anyone know, by any chance, a simple way to remedy that problem? Do cabal build first. It's filed as ticket: http://hackage.haskell.org/trac/hackage/ticket/396 It should not be hard to fix if you're looking for a task to get started in Cabal hacking. Duncan From dons at galois.com Tue Nov 25 17:05:56 2008 From: dons at galois.com (Don Stewart) Date: Tue Nov 25 16:59:37 2008 Subject: Data Parallel Haskell In-Reply-To: <5195fdde0811250124hd6d6111l34b5e3c0afb7f534@mail.gmail.com> References: <5195fdde0811250124hd6d6111l34b5e3c0afb7f534@mail.gmail.com> Message-ID: <20081125220556.GJ14812@scytale.galois.com> james.swaine: > Does anyone know if this library is being actively maintained? We had > some trouble getting it to build with the 6.10 sources, and it didn't look > it had been updated in a while, so I guess I just wanted to check and see > if anyone knew about it. > DPH ships with GHC 6.10 -- you shouldn't need to rebuild it? -- Don From james.swaine at gmail.com Tue Nov 25 18:18:18 2008 From: james.swaine at gmail.com (James Swaine) Date: Tue Nov 25 18:12:03 2008 Subject: Data Parallel Haskell In-Reply-To: <20081125220556.GJ14812@scytale.galois.com> References: <5195fdde0811250124hd6d6111l34b5e3c0afb7f534@mail.gmail.com> <20081125220556.GJ14812@scytale.galois.com> Message-ID: <5195fdde0811251518g4688c321o2056677f8a99cb97@mail.gmail.com> dph does ship with 6.10, but only part of it - DPH is essentially split into two libraries (at the moment). the library that ships with the main distributable is labeled 'convenience without the speed', and has language extensions for nested data parallelism - but the code actually always executes sequentially! (this is not according to me, but rather to the official website for DPH). we're trying to get a working build of the other part of DPH, labeled 'speed without the convenience' - our goal here is rudimentary performance testing - which doesn't ship with the main distribution of ghc. this is the part that we're having such trouble compiling. i've tried contacting roman about this but haven't been able to get a response from him. thanks, james On Tue, Nov 25, 2008 at 4:05 PM, Don Stewart wrote: > james.swaine: > > Does anyone know if this library is being actively maintained? We had > > some trouble getting it to build with the 6.10 sources, and it didn't > look > > it had been updated in a while, so I guess I just wanted to check and > see > > if anyone knew about it. > > > > > DPH ships with GHC 6.10 -- you shouldn't need to rebuild it? > > -- Don > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20081125/2fd68b34/attachment.htm From chak at cse.unsw.edu.au Tue Nov 25 19:07:07 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue Nov 25 19:00:58 2008 Subject: Data Parallel Haskell In-Reply-To: <5195fdde0811250923t1eb34d79y779f99433e8912a4@mail.gmail.com> References: <5195fdde0811250124hd6d6111l34b5e3c0afb7f534@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C331927EEA39@EA-EXMSG-C334.europe.corp.microsoft.com> <5195fdde0811250923t1eb34d79y779f99433e8912a4@mail.gmail.com> Message-ID: <42C62C9D-FAE3-412C-99BC-45585797F16B@cse.unsw.edu.au> James Swaine: > are any of you guys able to get it to compile (with 6.10 or 6.8.3)? > we get what looks like some build errors coming from the ndp > source. just wanted to check and see if it's something we're doing > wrong or not. It surely build. It is part of the standard distribution of GHC 6.10.1. However, you haven't told us what you are exactly using. If you just get the standard 6.10.1 tarball together with the extralibs tarball from http://haskell.org/ghc/download_ghc_6_10_1.html#sources will that not compile for you? Manuel From james.swaine at gmail.com Tue Nov 25 19:18:47 2008 From: james.swaine at gmail.com (James Swaine) Date: Tue Nov 25 19:12:34 2008 Subject: Data Parallel Haskell In-Reply-To: <42C62C9D-FAE3-412C-99BC-45585797F16B@cse.unsw.edu.au> References: <5195fdde0811250124hd6d6111l34b5e3c0afb7f534@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C331927EEA39@EA-EXMSG-C334.europe.corp.microsoft.com> <5195fdde0811250923t1eb34d79y779f99433e8912a4@mail.gmail.com> <42C62C9D-FAE3-412C-99BC-45585797F16B@cse.unsw.edu.au> Message-ID: <5195fdde0811251618r1208d83dv4057216a6de5d96d@mail.gmail.com> now i see, i think this is what i'm looking for...though i'm a little confused. the website says that the 'speed without convenience' stuff is in a separate package called 'ndp' (so libraries/ndp), which is what we pulled from darcs and will not compile. but this stuff under libraries/dph looks awfully similar. has everything been moved? thanks, james On Tue, Nov 25, 2008 at 6:07 PM, Manuel M T Chakravarty < chak@cse.unsw.edu.au> wrote: > James Swaine: > >> are any of you guys able to get it to compile (with 6.10 or 6.8.3)? we >> get what looks like some build errors coming from the ndp source. just >> wanted to check and see if it's something we're doing wrong or not. >> > > It surely build. It is part of the standard distribution of GHC 6.10.1. However, you haven't told us what you are exactly using. > > If you just get the standard 6.10.1 tarball together with the extralibs > tarball from > > http://haskell.org/ghc/download_ghc_6_10_1.html#sources > > will that not compile for you? > > Manuel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20081125/65164a67/attachment-0001.htm From chak at cse.unsw.edu.au Tue Nov 25 21:43:29 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue Nov 25 21:39:53 2008 Subject: Data Parallel Haskell In-Reply-To: <5195fdde0811251618r1208d83dv4057216a6de5d96d@mail.gmail.com> References: <5195fdde0811250124hd6d6111l34b5e3c0afb7f534@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C331927EEA39@EA-EXMSG-C334.europe.corp.microsoft.com> <5195fdde0811250923t1eb34d79y779f99433e8912a4@mail.gmail.com> <42C62C9D-FAE3-412C-99BC-45585797F16B@cse.unsw.edu.au> <5195fdde0811251618r1208d83dv4057216a6de5d96d@mail.gmail.com> Message-ID: > now i see, i think this is what i'm looking for...though i'm a > little confused. the website says that the 'speed without > convenience' stuff is in a separate package called 'ndp' (so > libraries/ndp), which is what we pulled from darcs and will not > compile. but this stuff under libraries/dph looks awfully similar. > has everything been moved? Yes, it has been moved and we need to update the wiki page. Sorry, I didn't realise that this was what you were looking at. Manuel > On Tue, Nov 25, 2008 at 6:07 PM, Manuel M T Chakravarty > wrote: > James Swaine: > > are any of you guys able to get it to compile (with 6.10 or 6.8.3)? > we get what looks like some build errors coming from the ndp > source. just wanted to check and see if it's something we're doing > wrong or not. > > It surely build. It is part of the standard distribution of GHC > 6.10.1. However, you haven't told us what you are exactly using. > > If you just get the standard 6.10.1 tarball together with the > extralibs tarball from > > http://haskell.org/ghc/download_ghc_6_10_1.html#sources > > will that not compile for you? > > Manuel > > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20081126/8e4e4c3d/attachment.htm From g9ks157k at acme.softbase.org Wed Nov 26 09:38:24 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Wed Nov 26 09:32:11 2008 Subject: Why =?utf-8?b?aXNu4oCZdA==?= (>>>) a method? Message-ID: <200811261538.24889.g9ks157k@acme.softbase.org> Hello, I wonder why (>>>) is an ordinary function instead of a method with a default implementation based on (.). The latter would make life easier in two ways. First, it would be easier to write code which works with the old Arrow class and the new Category/Arrow solution (fewer CPP stuff). Second, I often find it easier to ?think forwards? and use (>>>) instead of ?thinking backwards? and using (.). So it would be nicer for me to use (>>>) in a method implementation instead of (.). Best wishes, Wolfgang From nhn at Cs.Nott.AC.UK Wed Nov 26 10:54:50 2008 From: nhn at Cs.Nott.AC.UK (Henrik Nilsson) Date: Wed Nov 26 10:53:56 2008 Subject: Why =?utf-8?b?aXNu4oCZdCAoPj4+KSBhIG1ldGhvZD8=?= In-Reply-To: <200811261538.24889.g9ks157k@acme.softbase.org> References: <200811261538.24889.g9ks157k@acme.softbase.org> Message-ID: <492D714A.6040505@cs.nott.ac.uk> Hi all, I just want to support Wolfgang here. These changes (the new Category/Arrow solution) passed me by completely (too many other things to do). But I can't really see any strong reason for breaking backwards compatibility here by not sticking with (>>>) as a method? In fact, given that Category interferes with the standard prelude, I wonder if it was considered making (<<<) and (>>>) and "identity" methods of Category, leaving (.) and "id" alone? Such a design would have been beneficial for a library like Yampa, would have minimized backwards compatibility issues, and would have simplified life for end users (saves them from hiding the prelude "id" and (.). Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn@cs.nott.ac.uk This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From isaacdupree at charter.net Wed Nov 26 15:25:37 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Wed Nov 26 15:19:21 2008 Subject: Why =?utf-8?b?aXNu4oCZdCAoPj4+KSBhIG1ldGhvZD8=?= In-Reply-To: <200811261538.24889.g9ks157k@acme.softbase.org> References: <200811261538.24889.g9ks157k@acme.softbase.org> Message-ID: <492DB0C1.8020508@charter.net> Wolfgang Jeltsch wrote: > Hello, > > I wonder why (>>>) is an ordinary function instead of a method with a default > implementation based on (.). The latter would make life easier in two ways. But if you don't add some "instance Category...where (.)=...; id=...", then there are still problems! so compatibility is still an issue. and I have to say that your suggestion twists my mind a little bit. after all, Category is the super-class now. -Isaac From haskell at list.mightyreason.com Wed Nov 26 15:42:16 2008 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Wed Nov 26 15:36:01 2008 Subject: Ann: Version 1.2.1 of Protocol-Buffers for Haskell In-Reply-To: <396556a20811251533g2b0316efn575a58a74c2bf22c@mail.gmail.com> References: <492AE655.4050508@personal.mightyreason.com> <396556a20811251533g2b0316efn575a58a74c2bf22c@mail.gmail.com> Message-ID: <492DB4A8.6090103@list.mightyreason.com> This is to announce version 1.2.1 of my protocol-buffers, protocol-buffers-descriptor, and hprotoc packages. Note: Code generated by the previous versions of hprotoc will not work with this new version of the library, and vice-versa. These improve on the previous version 1.0.1 in a few ways: * The Enum modules have a new "toMaybe'Enum :: Int -> Maybe TYPE" function which allows for better error handling. * The generated Enum instances have better error messages. * The wireGet deserialization operation on Messages and Groups has better error handling: ** Unrecognized enum value call throwError instead of calling error. ** Incoming strings are checked for valid utf8 encoding, or will call throwError. ** For messages generated with "unknown" support, all field error are caught and then the data is loaded into the unknown map (which might also fail, which won't be caught). * wireGet now uses explicitly generated "Set WireTag" instead of using reflection. This is saner, and might even have helped performance. * A bug inside an error reporting function in hprotoc was fixed (it caused a hang due to lazy self-dependence when showing error information). The main upside to these changes is to remove a the "error" call from 1.0.1's used of toEnum and make the deserialization more robust and predictable. In the future there will be support for the changes in google's upcoming version 2.0.3 of protoc (mainly custom EnumValue options). Cheers, Chris From dave at zednenem.com Wed Nov 26 16:02:36 2008 From: dave at zednenem.com (David Menendez) Date: Wed Nov 26 15:56:19 2008 Subject: =?windows-1252?q?Re=3A_Why_isn=92t_=28=3E=3E=3E=29_a_method=3F?= In-Reply-To: <200811261538.24889.g9ks157k@acme.softbase.org> References: <200811261538.24889.g9ks157k@acme.softbase.org> Message-ID: <49a77b7a0811261302x9471067o20e0e85bfd2849df@mail.gmail.com> On Wed, Nov 26, 2008 at 9:38 AM, Wolfgang Jeltsch wrote: > I wonder why (>>>) is an ordinary function instead of a method with a default > implementation based on (.). It's easier to explain and provides fewer chances for mistakes. It's the same reason Arrow no longer has both "arr" and "pure". I'm not sure why they chose the name (.) for Category, rather than (>>>) or (<<<). I also think trying to shoe-horn a new, incompatible definition for Arrow into a base-3.0.* release was a mistake. The whole point of having a versioning policy is lost if you don't follow it. Given how isolated Arrow is in the standard libraries, they could have just created a new class and deprecated the old one without causing much fuss. -- Dave Menendez From ross at soi.city.ac.uk Wed Nov 26 16:38:34 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Nov 26 16:32:17 2008 Subject: Why isn?t (>>>) a method? In-Reply-To: <49a77b7a0811261302x9471067o20e0e85bfd2849df@mail.gmail.com> References: <200811261538.24889.g9ks157k@acme.softbase.org> <49a77b7a0811261302x9471067o20e0e85bfd2849df@mail.gmail.com> Message-ID: <20081126213833.GA7941@soi.city.ac.uk> On Wed, Nov 26, 2008 at 04:02:36PM -0500, David Menendez wrote: > I also think trying to shoe-horn a new, incompatible definition for > Arrow into a base-3.0.* release was a mistake. The whole point of > having a versioning policy is lost if you don't follow it. Given how > isolated Arrow is in the standard libraries, they could have just > created a new class and deprecated the old one without causing much > fuss. It is isolated in base, but it's also wired into GHC. The whole point of base-compat is to present a different view of the same entities, so that packages using the base-3 interface and those using the base-4 interface can be combined. There was no way that could work with a changed Arrow class. From dave at zednenem.com Wed Nov 26 17:12:30 2008 From: dave at zednenem.com (David Menendez) Date: Wed Nov 26 17:06:12 2008 Subject: Why isn?t (>>>) a method? In-Reply-To: <20081126213833.GA7941@soi.city.ac.uk> References: <200811261538.24889.g9ks157k@acme.softbase.org> <49a77b7a0811261302x9471067o20e0e85bfd2849df@mail.gmail.com> <20081126213833.GA7941@soi.city.ac.uk> Message-ID: <49a77b7a0811261412q3dfaacddv27dace22b75e0705@mail.gmail.com> On Wed, Nov 26, 2008 at 4:38 PM, Ross Paterson wrote: > On Wed, Nov 26, 2008 at 04:02:36PM -0500, David Menendez wrote: >> I also think trying to shoe-horn a new, incompatible definition for >> Arrow into a base-3.0.* release was a mistake. The whole point of >> having a versioning policy is lost if you don't follow it. Given how >> isolated Arrow is in the standard libraries, they could have just >> created a new class and deprecated the old one without causing much >> fuss. > > It is isolated in base, but it's also wired into GHC. The whole point > of base-compat is to present a different view of the same entities, > so that packages using the base-3 interface and those using the base-4 > interface can be combined. There was no way that could work with a > changed Arrow class. But now base-3 isn't compatible with *itself*. I see no reason why GHC couldn't use a mechanism like rebindable syntax to support two Arrow classes. I'm free to define my own version of Monad and use the do-synax with it. Besides, the arrow syntax already requires a language extension; we could just provide a different pragma for neo-Arrows. The old and new Arrow classes could coexist perfectly fine. Of course, Arrow libraries would end up needing a bunch of boilerplate to provide instances for both classes. Whether that's preferable to conditional compilation may be a matter of taste. -- Dave Menendez From ndmitchell at gmail.com Thu Nov 27 07:17:21 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Nov 27 07:11:03 2008 Subject: [Hs-Generics] RE: Generics In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C33192419EAE@EA-EXMSG-C334.europe.corp.microsoft.com> References: <638ABD0A29C8884A91BC5FB5C349B1C33192419C62@EA-EXMSG-C334.europe.corp.microsoft.com> <52f14b210811210729g5c80afbam93d2b7a7f0ccbca5@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33192419EAE@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <404396ef0811270417k5cf4ab93kd12e40b52ccc0f12@mail.gmail.com> Hi Jos?, You may also want to weigh in on this issue: http://hackage.haskell.org/trac/ghc/ticket/2782 The instance of Ratio changed between 6.10 and 6.8 in a way that means a program can't reflect on the fields contained within the :% constructor using the value undefined. The reason is that :% is marked as strict in both arguments, so _|_ :% _|_ == _|_. This breaks Uniplate, and I've had to explicitly make a test for a type of Rational in the Uniplate code - which is ugly. I'm not sure how many other programs this might break - or if the impact was well understood when the change was made. This change is made massively worse by giving the error message "undefined" when it fails! If an SYB using program goes from working in GHC 6.8 to failing in GHC 6.10 with "undefined", this may be a culprit. I'm not sure there is a nice solution - reflection at the type level (using _|_ at the value level), combined with strictness at the value level, has limitations. It may be that the reflection machinery in SYB can be tweaked to either alert the user in advance (i.e. by getting the strictness of various fields), or providing some operation combining gmapQ and fromConstr which isn't strict. To see my use case take a look at "contains" in: http://www.cs.york.ac.uk/fp/darcs/uniplate/Data/Generics/PlateData.hs Thanks Neil On Fri, Nov 21, 2008 at 5:28 PM, Simon Peyton-Jones wrote: > Thanks. And here is one more > > > > http://hackage.haskell.org/trac/ghc/ticket/2750 > > > > For potentially-breaking changes the right thing to do is to announce (and > justify) the proposed change using the usual library-change protocol, with a > discussion period. The important thing is that someone is driving the > discussion -- thank you very much for that. I'll assign these tickets to > you. > > > > Simon > > > > From: josepedromagalhaes@gmail.com [mailto:josepedromagalhaes@gmail.com] On > Behalf Of Jos? Pedro Magalh?es > Sent: 21 November 2008 15:30 > To: Simon Peyton-Jones > Cc: libraries@haskell.org; Generics Mailing List > Subject: Re: Generics > > > > Hello Simon, > > Thanks for pointing these out to me. I won't be able to look into this for > the next week, but from what I could see so far, #2760 seems easy: copy > mkNorepType to mkNoRepType, mark mkNorepType as deprecated and replace usage > everywhere to avoid warnings and pass validation. I can submit the patch for > this. > > #2759 has some deeper implications, though. Replacing the FloatConstr Double > by FloatConstr Rational might break existing client code (even though it > probably wouldn't be too hard to fix it). Additionally, I see that the > serializer code in compiler/utils/Serialized.hs would also need changes > (it's no longer serializing a Double). But I guess this is also not too > problematic... > > > Cheers, > Pedro > > On Fri, Nov 21, 2008 at 13:34, Simon Peyton-Jones > wrote: > > Jose > > As part of your work on the SYB library, could you spare the time to look > into these two library bug reports? > > http://hackage.haskell.org/trac/ghc/ticket/2759 > http://hackage.haskell.org/trac/ghc/ticket/2760 > > Many thanks > > Simon > > > > _______________________________________________ > Generics mailing list > Generics@haskell.org > http://www.haskell.org/mailman/listinfo/generics > > From mboes at tweag.net Thu Nov 27 09:08:09 2008 From: mboes at tweag.net (Mathieu Boespflug) Date: Thu Nov 27 09:01:50 2008 Subject: ByteString, foldr and lazyness In-Reply-To: <63c0799b0811270605r6a7f97e3s3b7e79660bb20053@mail.gmail.com> References: <63c0799b0811270605r6a7f97e3s3b7e79660bb20053@mail.gmail.com> Message-ID: <63c0799b0811270608t442ac88esb6b5ef7475228f0a@mail.gmail.com> Hi all, Here's a ghci session, using bytestring-0.9.1.4 and ghc-6.10: Prelude> :m Data.ByteString.Lazy.Char8 Prelude Data.ByteString.Lazy.Char8> :m -Prelude Data.ByteString.Lazy.Char8> foldr (:) [] (concat (Prelude.repeat "a")) Loading package bytestring-0.9.1.4 ... linking ... done. "*** Exception: stack overflow By contrast, using Prelude's foldr and concat: Prelude> foldr (:) [] (concat (repeat "a")) :: String Each bytestring chunk only contains one letter, so I would expect the foldr of bytestring to behave just like that of the Prelude. Is this a bug? A feature? From looking at the bytestring source code I don't see why the code behaves this way. Many thanks, Mathieu From hpacheco at gmail.com Fri Nov 28 06:59:49 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Fri Nov 28 06:53:26 2008 Subject: Building haddock when accessing data files from package code Message-ID: <7b92c2840811280359q34327a09k80d6ee6663c763ca@mail.gmail.com> Hi all, When creating a cabal package that contains module that import Paths_ (as tutored in http://www.haskell.org/cabal/release/latest/doc/users-guide/authors.html#paths-module), haddock complains that it cannot find such module, since it is generated automatically by cabal: $ runhaskell Setup.lhs haddock ... Setup.lhs: can't find source for module Paths_GHood How do I tell haddock to ignore such module? Should this be handled in the Setup.lhs file? I am using the default Simple file. Thanks in advance, hugo -- www.di.uminho.pt/~hpacheco -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20081128/0145cae2/attachment.htm From duncan.coutts at worc.ox.ac.uk Fri Nov 28 09:14:46 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Nov 28 09:08:28 2008 Subject: ByteString, foldr and lazyness In-Reply-To: <63c0799b0811270608t442ac88esb6b5ef7475228f0a@mail.gmail.com> References: <63c0799b0811270605r6a7f97e3s3b7e79660bb20053@mail.gmail.com> <63c0799b0811270608t442ac88esb6b5ef7475228f0a@mail.gmail.com> Message-ID: <1227881686.10115.26.camel@localhost> On Thu, 2008-11-27 at 15:08 +0100, Mathieu Boespflug wrote: > Hi all, > > Here's a ghci session, using bytestring-0.9.1.4 and ghc-6.10: > > Prelude> :m Data.ByteString.Lazy.Char8 > Prelude Data.ByteString.Lazy.Char8> :m -Prelude > Data.ByteString.Lazy.Char8> foldr (:) [] (concat (Prelude.repeat "a")) This does not typecheck. Prelude.repeat "a" :: [String] concat :: [ByteString] -> ByteString hence concat (Prelude.repeat "a") is not well typed. Duncan From duncan.coutts at worc.ox.ac.uk Fri Nov 28 09:17:50 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Nov 28 09:11:29 2008 Subject: Building haddock when accessing data files from package code In-Reply-To: <7b92c2840811280359q34327a09k80d6ee6663c763ca@mail.gmail.com> References: <7b92c2840811280359q34327a09k80d6ee6663c763ca@mail.gmail.com> Message-ID: <1227881870.10115.29.camel@localhost> On Fri, 2008-11-28 at 11:59 +0000, Hugo Pacheco wrote: > Hi all, > > > When creating a cabal package that contains module that import > Paths_ (as tutored > in http://www.haskell.org/cabal/release/latest/doc/users-guide/authors.html#paths-module), haddock complains that it cannot find such module, since it is generated automatically by cabal: > > > $ runhaskell Setup.lhs haddock > ... > Setup.lhs: can't find source for module Paths_GHood > How do I tell haddock to ignore such module? > Should this be handled in the Setup.lhs file? I am using the default > Simple file. The bug is that these auto-generated modules are not generated as part of the haddock command. The workaround is to build first. The ticket is: http://hackage.haskell.org/trac/hackage/ticket/396 It should be a simple fix for a new Cabal hacker. Now is a good chance to get involved! :-) Duncan From hpacheco at gmail.com Fri Nov 28 09:25:24 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Fri Nov 28 09:19:00 2008 Subject: Building haddock when accessing data files from package code In-Reply-To: <1227881870.10115.29.camel@localhost> References: <7b92c2840811280359q34327a09k80d6ee6663c763ca@mail.gmail.com> <1227881870.10115.29.camel@localhost> Message-ID: <7b92c2840811280625t1a086d24jd2e6f6ccf3ec7045@mail.gmail.com> I don't know if I got the ideia.I have always built before and always got the error: $ runhaskell Setup.lhs configure $ runhaskell Setup.lhs build $ runhaskell Setup.lhs haddock .. Setup.lhs: can't find source for module Paths_module Thanks, hugo On Fri, Nov 28, 2008 at 2:17 PM, Duncan Coutts wrote: > On Fri, 2008-11-28 at 11:59 +0000, Hugo Pacheco wrote: > > Hi all, > > > > > > When creating a cabal package that contains module that import > > Paths_ (as tutored > > in > http://www.haskell.org/cabal/release/latest/doc/users-guide/authors.html#paths-module), > haddock complains that it cannot find such module, since it is generated > automatically by cabal: > > > > > > $ runhaskell Setup.lhs haddock > > ... > > Setup.lhs: can't find source for module Paths_GHood > > > How do I tell haddock to ignore such module? > > Should this be handled in the Setup.lhs file? I am using the default > > Simple file. > > The bug is that these auto-generated modules are not generated as part > of the haddock command. The workaround is to build first. The ticket is: > > http://hackage.haskell.org/trac/hackage/ticket/396 > > It should be a simple fix for a new Cabal hacker. Now is a good chance > to get involved! :-) > > Duncan > > -- www.di.uminho.pt/~hpacheco -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20081128/bce0dc56/attachment.htm From nicolas.pouillard at gmail.com Fri Nov 28 09:24:38 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Fri Nov 28 09:19:12 2008 Subject: ByteString, foldr and lazyness In-Reply-To: <1227881686.10115.26.camel@localhost> References: <63c0799b0811270605r6a7f97e3s3b7e79660bb20053@mail.gmail.com> <63c0799b0811270608t442ac88esb6b5ef7475228f0a@mail.gmail.com> <1227881686.10115.26.camel@localhost> Message-ID: <1227882148-sup-9814@ausone.inria.fr> Excerpts from Duncan Coutts's message of Fri Nov 28 15:14:46 +0100 2008: > On Thu, 2008-11-27 at 15:08 +0100, Mathieu Boespflug wrote: > > Hi all, > > > > Here's a ghci session, using bytestring-0.9.1.4 and ghc-6.10: > > > > Prelude> :m Data.ByteString.Lazy.Char8 > > Prelude Data.ByteString.Lazy.Char8> :m -Prelude > > Data.ByteString.Lazy.Char8> foldr (:) [] (concat (Prelude.repeat "a")) > > This does not typecheck. That's a matter of packing, maybe he has the overloaded strings extension. -- Nicolas Pouillard aka Ertai From duncan.coutts at worc.ox.ac.uk Fri Nov 28 10:18:56 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Nov 28 10:12:38 2008 Subject: ByteString, foldr and lazyness In-Reply-To: <1227882148-sup-9814@ausone.inria.fr> References: <63c0799b0811270605r6a7f97e3s3b7e79660bb20053@mail.gmail.com> <63c0799b0811270608t442ac88esb6b5ef7475228f0a@mail.gmail.com> <1227881686.10115.26.camel@localhost> <1227882148-sup-9814@ausone.inria.fr> Message-ID: <1227885536.10115.36.camel@localhost> On Fri, 2008-11-28 at 15:24 +0100, Nicolas Pouillard wrote: > Excerpts from Duncan Coutts's message of Fri Nov 28 15:14:46 +0100 2008: > > On Thu, 2008-11-27 at 15:08 +0100, Mathieu Boespflug wrote: > > > Hi all, > > > > > > Here's a ghci session, using bytestring-0.9.1.4 and ghc-6.10: > > > > > > Prelude> :m Data.ByteString.Lazy.Char8 > > > Prelude Data.ByteString.Lazy.Char8> :m -Prelude > > > Data.ByteString.Lazy.Char8> foldr (:) [] (concat (Prelude.repeat "a")) > > > > This does not typecheck. > > That's a matter of packing, maybe he has the overloaded strings extension. Ah yes, quite right. Turns out the bug is in Data.ByteString.foldr: Prelude.head (foldr (:) Prelude.undefined (singleton 3)) *** Exception: Prelude.undefined of course the result should be 3:_|_ not _|_ the cause is excessive strictness in the definition of foldr's inner loop: foldr :: (Word8 -> a -> a) -> a -> ByteString -> a foldr k v (PS x s l) = inlinePerformIO $ withForeignPtr x $ \ptr -> go v (ptr `plusPtr` (s+l-1)) (ptr `plusPtr` (s-1)) where STRICT3(go) go z p q | p == q = return z | otherwise = do c <- peek p go (c `k` z) (p `plusPtr` (-1)) q The STRICT3(go) macro expands to add strictness on all three parameters. In this function it should only be strict in p and q, not z. The go function is already strict in p and q so simply dropping the STRICT3 macro fixes the bug. Unfortunately that also means we build up a chain of thunks, since this foldr is implemented as a foldl' but going from high indexes to low. One more example to show that we should be specifying and testing the strictness properties of our functions. Duncan From duncan.coutts at worc.ox.ac.uk Fri Nov 28 10:37:45 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Nov 28 10:31:26 2008 Subject: Building haddock when accessing data files from package code In-Reply-To: <7b92c2840811280625t1a086d24jd2e6f6ccf3ec7045@mail.gmail.com> References: <7b92c2840811280359q34327a09k80d6ee6663c763ca@mail.gmail.com> <1227881870.10115.29.camel@localhost> <7b92c2840811280625t1a086d24jd2e6f6ccf3ec7045@mail.gmail.com> Message-ID: <1227886665.10115.44.camel@localhost> On Fri, 2008-11-28 at 14:25 +0000, Hugo Pacheco wrote: > I don't know if I got the ideia. > I have always built before and always got the error: > > > $ runhaskell Setup.lhs configure > $ runhaskell Setup.lhs build > $ runhaskell Setup.lhs haddock > .. > Setup.lhs: can't find source for module Paths_module Ok, that is supposed to work. We'll need more details, eg the Cabal lib version and the .cabal file you're using. There was a bug in this area in Cabal-1.4.x: http://hackage.haskell.org/trac/hackage/ticket/187 Duncan From shelarcy at gmail.com Fri Nov 28 21:50:58 2008 From: shelarcy at gmail.com (shelarcy) Date: Fri Nov 28 21:44:38 2008 Subject: darcs patch: Fix typo (or out of date reference) in throwTo documen... Message-ID: A non-text attachment was scrubbed... Name: darcs3852 Type: application/octet-stream Size: 26882 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20081128/1a814c2b/darcs3852.obj From coeus at gmx.de Sat Nov 29 03:49:03 2008 From: coeus at gmx.de (Marc A. Ziegert) Date: Sat Nov 29 03:42:51 2008 Subject: arrows-0.4/0.4.1 + Stream: Monoid instances Message-ID: <200811290949.13965.coeus@gmx.de> hi i've just had serious problems with too many (or too strange) Monoid instances in the arrows library. {- i tried to install/patch Conal Elliott's bot package, which reinterprets some arrow types, i.e. type StreamBot = StreamArrow (->) and then tries to derive the Monoid instance with deriving instance Monoid o => Monoid (StreamBot i o). -} the main problem is the circumstance, that the instance of StreamArrow as Monoid depends strangely on ArrowPlus, but (->) is no instance of the ArrowPlus class. instance ArrowPlus a => Monoid (StreamArrow a b c) instance ArrowPlus a => Monoid (XyzArrow a b c) (->) makes only sense to be in MonadPlus, iff (a->b) is a Monoid -- which is, iff b is a Monoid; and that dependency does not work: instance Monoid b => ArrowPlus (->) where...?! INHO it does not make any sense at all to derive the Monoid instance from ArrowPlus instead of other Monoids. so, is it possible to remove them? anyway, they are only copies of MonadPlus. additionally, if it is possible and does not cause too many problems in other packages, i suggest to generalize the Monoid instance for (->), which is located at Data.Monoid. i.e. like this: instance (Arrow (~>),Monoid c) => Monoid ((~>) b c) where mempty = arr (const mempty) mappend f g = (f &&& g) >>> arr (uncurry mappend) besides that, i miss a Monoid instance for Streams, which should be located in the corresponding library: instance Monoid x => Monoid (Stream x) where mempty = Cons mempty mempty mappend (Cons a as) (Cons b bs) = mappend a b `Cons` mappend as bs greetings - marc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://www.haskell.org/pipermail/libraries/attachments/20081129/e62ae10d/attachment.bin From igloo at earth.li Sun Nov 30 13:32:32 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Nov 30 13:26:04 2008 Subject: darcs patch: Fix typo (or out of date reference) in throwTo documen... In-Reply-To: References: Message-ID: <20081130183232.GA1232@matrix.chaos.earth.li> Applied, thanks! Thanks Ian From gwern0 at gmail.com Sun Nov 30 16:07:15 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Sun Nov 30 16:00:45 2008 Subject: template-haskell depends on packedstring In-Reply-To: <1227644511.19577.24.camel@localhost> References: <1227644511.19577.24.camel@localhost> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Tue, Nov 25, 2008 at 3:21 PM, Duncan Coutts wrote: > On Sun, 2008-11-23 at 22:53 -0500, Gwern Branwen wrote: >> So I was trying to compile lambdabot with cabal-install. Lambdabot >> uses Template Haskell for generating some boilerplate, and it was a >> failed dependency. Template Haskell uses packedstring for... >> something... and packedstring was a failed dependency: >> Data/PackedString.hs:83:7: >> Could not find module `Data.Data': >> it is a member of package base, which is hidden >> >> Now this is a problem, but it's not the problem I am interested in. I >> am interested in: why is template-haskell using packedstring? Wasn't >> packedstring obsoleted years ago? > > Yes. > > The question is if one should break the TH api just to remove this > deprecated dependency. Especially when it is slated to be replaced with > an improved unicode packed string type in the future. > > So either we break it once, or twice. > > Duncan I don't really see why we would need to change the API; let's just make the types = String, and the conversion functions null-ops. Unless there's some sort of low-level binary API compatibility you are referring to? - -- gwern -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREKAAYFAkkzAIMACgkQvpDo5Pfl1oIbkwCfb1Bx87CqVolvdWL0ZFOwclCa x5kAnjg+EAqUJuE+mR0KLclMS1fQPn67 =d5hQ -----END PGP SIGNATURE----- From duncan.coutts at worc.ox.ac.uk Sun Nov 30 17:56:05 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Nov 30 17:49:37 2008 Subject: template-haskell depends on packedstring In-Reply-To: References: <1227644511.19577.24.camel@localhost> Message-ID: <1228085765.10115.120.camel@localhost> On Sun, 2008-11-30 at 16:07 -0500, Gwern Branwen wrote: > > The question is if one should break the TH api just to remove this > > deprecated dependency. Especially when it is slated to be replaced with > > an improved unicode packed string type in the future. > > > > So either we break it once, or twice. > I don't really see why we would need to change the API; let's just > make the types = String, and the conversion functions null-ops. Ah, I see. I'd not looked that closely. It's this bit you're referring to: type OccName = PackedString mkOccName :: String -> OccName occString :: OccName -> String type ModName = PackedString mkModName :: String -> ModName modString :: ModName -> String type PkgName = PackedString mkPkgName :: String -> PkgName pkgString :: PkgName -> String Technically that's not an abstract api so changing the type alias could break programs, though I agree that it may be unlikely. > Unless there's some sort of low-level binary API compatibility you are > referring to? No, just the source level API. Duncan From gwern0 at gmail.com Sun Nov 30 18:37:27 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Sun Nov 30 18:30:57 2008 Subject: template-haskell depends on packedstring In-Reply-To: <1228085765.10115.120.camel@localhost> References: <1227644511.19577.24.camel@localhost> <1228085765.10115.120.camel@localhost> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Sun, Nov 30, 2008 at 5:56 PM, Duncan Coutts wrote: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREKAAYFAkkzI7cACgkQvpDo5Pfl1oKiKQCghkRpR7vRjyTezciI9Hv/HUFX FygAmwdCS57mUfqUc2N8Dm5ceFNC2CNn =ABN1 -----END PGP SIGNATURE----- ... > Ah, I see. I'd not looked that closely. It's this bit you're referring > to: > > type OccName = PackedString > mkOccName :: String -> OccName > occString :: OccName -> String > > type ModName = PackedString > mkModName :: String -> ModName > modString :: ModName -> String > > type PkgName = PackedString > mkPkgName :: String -> PkgName > pkgString :: PkgName -> String > > Technically that's not an abstract api so changing the type alias could > break programs, though I agree that it may be unlikely. I would argue that it's less unlikely than richly deserved. :) (I find it difficult to imagine why a TH hacker would deliberately tunnel through the alias, personally.) >> Unless there's some sort of low-level binary API compatibility you are >> referring to? > > No, just the source level API. > > Duncan OK. Is the previous issue a fatal objection or can we just make the change and upload a new TH? -- gwern From duncan.coutts at worc.ox.ac.uk Sun Nov 30 19:04:04 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Nov 30 18:57:36 2008 Subject: template-haskell depends on packedstring In-Reply-To: References: <1227644511.19577.24.camel@localhost> <1228085765.10115.120.camel@localhost> Message-ID: <1228089844.10115.133.camel@localhost> On Sun, 2008-11-30 at 18:37 -0500, Gwern Branwen wrote: > > Ah, I see. I'd not looked that closely. It's this bit you're referring > > to: > > > > type OccName = PackedString > > mkOccName :: String -> OccName > > occString :: OccName -> String > > > > type ModName = PackedString > > mkModName :: String -> ModName > > modString :: ModName -> String > > > > type PkgName = PackedString > > mkPkgName :: String -> PkgName > > pkgString :: PkgName -> String > > > > Technically that's not an abstract api so changing the type alias could > > break programs, though I agree that it may be unlikely. > > I would argue that it's less unlikely than richly deserved. :) (I find > it difficult to imagine why a TH hacker would deliberately tunnel > through the alias, personally.) > > >> Unless there's some sort of low-level binary API compatibility you are > >> referring to? > > > > No, just the source level API. > OK. Is the previous issue a fatal objection or can we just make the > change and upload a new TH? How about making a library proposal to change them to abstract newtypes, then we can change the internal representation at will. I would not object to that, but then I'm not a TH hacker and they deserve the chance to comment. Duncan