From lemming at henning-thielemann.de Mon Oct 1 09:29:32 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Oct 1 09:28:32 2007 Subject: Fwd: Suitable new name for Dimensional library In-Reply-To: <8b2a1a960709281327i2d32012bjde176763937db398@mail.gmail.com> References: <8b2a1a960709271940x2a09b797wbdc95afff221db61@mail.gmail.com> <8b2a1a960709281324x2bd4e28bs454923c20d8dbd29@mail.gmail.com> <8b2a1a960709281327i2d32012bjde176763937db398@mail.gmail.com> Message-ID: On Fri, 28 Sep 2007, Bj?rn Buckwalter wrote: > Taken further though, if someone develops another "static" unit > library where should they put it? An arbitrarily complex tree of > namespaces could be built trying to distinguish libraries to > anticipate future clashes. > > This leads me to wonder -- is it better for a library to have a more > or less arbitrary differentiating name rather than a descriptive name? > Examples are 'Text.ParserCombinators.Parsec', 'Text.Parsers.Frisby'. >> From their names it's not obvious what distinguishes them from other > parsers in the same namespace but at least the tree is fairly flat and > hopefully narrowed down enough to permit investigating each > alternative. In the units case I imagine > 'Numeric.Units.SomethingArbitrary' would be appropriate. Indeed, someone might implement static unit checking by a different approach. We cannot predict this. So actually it seems to be better to use an arbitrary differentiating name, say Numeric.Units.Bucky Numeric.Units.Lemming Using module names which describe only the module function might work if there is consensus on its relevance and its API. That is, only for very basic modules of a 'standard library'. From lemming at henning-thielemann.de Mon Oct 1 10:06:00 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Oct 1 10:05:00 2007 Subject: Control.Monad, Control.Applicative vs. Data.Foldable, Data.Traversable Message-ID: What is the reason for some of the standard type classes being in 'Data' folder and some in 'Control'? Since, say 'Reader' is a monad, an applicative thing, an arrow and an instance of other classes - why is it located in Control.Monad? Why not Data.Reader? I find it reasonable to have a directory for concrete data types and one directory for classes. Currently I cannot see, why the Reader data type is in Monad, Monad is in Control, but Foldable class is in Data, together with List, Tree and other concrete data types. From kolmodin at dtek.chalmers.se Fri Oct 5 12:09:52 2007 From: kolmodin at dtek.chalmers.se (Lennart Kolmodin) Date: Fri Oct 5 12:08:40 2007 Subject: Proposal: Fix abstract unix sockets (#1699) In-Reply-To: <20070917115225.GA3777@matrix.chaos.earth.li> References: <46ECF478.8010905@dtek.chalmers.se> <20070917115225.GA3777@matrix.chaos.earth.li> Message-ID: <470661D0.8080503@dtek.chalmers.se> Ian Lynagh wrote: > Hi Lennart, > > On Sun, Sep 16, 2007 at 10:16:40AM +0100, Lennart Kolmodin wrote: >> I've added proposal #1699 to fix abstract unix sockets on Linux for the >> network library. > > You haven't suggested a deadline; between the GHC release and ICFP et al, > perhaps 15 Oct would make sense? Sounds excellent. >> The patch is so far only tested under Linux (2.6.15), but should not >> affect Windows or other OSes which does not have AUS. > > So if I understand correctly, with this patch certain paths would be > treated differently, but only on Linux machines? If someone tries to use > AUS on a non-Linux system, will things break horribly? i.e. would it be > better to have a separate package/module for this Linux-specific > behaviour? I expect an exception will be thrown by 'connect' if you try to use a AUS on a non-linux box. The user only difference for the users is that they can now prefix their UnixPath with a zero. So no change of the API, iirc. A technique previously used is to create a new constructor for AUS and simply not expose it on systems that doesn't support it. This requires the portability-aware devs to #ifdef on the target platform. >> Also, due to much more socklen usage: >> * Switch Network.Socket to use CSockLen instead of CInt. >> * Cleanup surrounding code. > > It would be better for code fixes and cleanup to be in a separate patch > from new functionality; this part sounds like it should definitely be > applied. Right, yes. The reason I didn't was because I discovered things needed to be fixed once I already had changed other stuff... aye, lazy, yes... Cheers, Lennart Kolmodin -- "The only thing that interferes with my learning is my education." -- Albert Einstein From dons at galois.com Sun Oct 7 08:54:13 2007 From: dons at galois.com (Don Stewart) Date: Sun Oct 7 08:53:01 2007 Subject: X11 package Message-ID: <20071007125413.GD13126@scytale.galois.com> I've taken over maintainership of the X11 package, as we need it for xmonad. The previous maintainer was libraries@. Let me know if you've any problems with this. -- Don From bringert at cs.chalmers.se Mon Oct 8 17:10:02 2007 From: bringert at cs.chalmers.se (Bjorn Bringert) Date: Mon Oct 8 17:07:55 2007 Subject: Hackage and GHC 6.8 In-Reply-To: <20070925083848.GA2551@soi.city.ac.uk> References: <20070924010213.GF27284@liouville.galois.com> <20070925083848.GA2551@soi.city.ac.uk> Message-ID: <075FF7F4-02AC-44EB-ABDD-5D511ED90006@cs.chalmers.se> On Sep 25, 2007, at 10:38 , Ross Paterson wrote: > On Sun, Sep 23, 2007 at 06:02:13PM -0700, Don Stewart wrote: >> Neil Davies wrote: >>> Given that GHC 6.8 is just around the corner and, given how it has >>> re-organised the libraries so that the dependencies in many (most/ >>> all) >>> the packages in the hackage DB are now not correct. >>> >>> Is there a plan of how to get hackage DB up to speed with GHC 6.8 ? >> >> Ian, GHC HQ, can you elaborate on what the plan is on fixing the >> hackage >> libraries for ghc 6.8 -- should everyone be springing into action to >> update .cabal files and fix api changes? > > I'm a bit confused about the version numbering for the boot libraries. > The versions bundled with various versions of GHC are: > > ghc-6.6: base-2.0 template-haskell-2.0 unix-1.0 > ghc-6.6.1: base-2.1.1 template-haskell-2.1 unix-2.1 > ghc-6.8 RC: base-2.1 template-haskell-0.1 unix-2.0 > > What versions are planned for the release? This seems quite broken. It makes writing Cabal configurations messy. base <= 2.0 and == 2.1.1 are the monolithic base. base == 2.1 (and presumably >= 2.2) are the split up base. Add to this that bytestring was in base == 2.0 (not <=2.0) and in == 2.1.1. Is there any reason not to bump the base that comes with GHC 6.8 to base-2.2? /Bj?rn From dons at galois.com Mon Oct 8 18:02:53 2007 From: dons at galois.com (Don Stewart) Date: Mon Oct 8 18:01:51 2007 Subject: Hackage and GHC 6.8 In-Reply-To: <075FF7F4-02AC-44EB-ABDD-5D511ED90006@cs.chalmers.se> References: <20070924010213.GF27284@liouville.galois.com> <20070925083848.GA2551@soi.city.ac.uk> <075FF7F4-02AC-44EB-ABDD-5D511ED90006@cs.chalmers.se> Message-ID: <20071008220253.GB17279@scytale.galois.com> bringert: > On Sep 25, 2007, at 10:38 , Ross Paterson wrote: > > >On Sun, Sep 23, 2007 at 06:02:13PM -0700, Don Stewart wrote: > >>Neil Davies wrote: > >>>Given that GHC 6.8 is just around the corner and, given how it has > >>>re-organised the libraries so that the dependencies in many (most/ > >>>all) > >>>the packages in the hackage DB are now not correct. > >>> > >>>Is there a plan of how to get hackage DB up to speed with GHC 6.8 ? > >> > >>Ian, GHC HQ, can you elaborate on what the plan is on fixing the > >>hackage > >>libraries for ghc 6.8 -- should everyone be springing into action to > >>update .cabal files and fix api changes? > > > >I'm a bit confused about the version numbering for the boot libraries. > >The versions bundled with various versions of GHC are: > > > >ghc-6.6: base-2.0 template-haskell-2.0 unix-1.0 > >ghc-6.6.1: base-2.1.1 template-haskell-2.1 unix-2.1 > >ghc-6.8 RC: base-2.1 template-haskell-0.1 unix-2.0 > > > >What versions are planned for the release? > > This seems quite broken. It makes writing Cabal configurations messy. > base <= 2.0 and == 2.1.1 are the monolithic base. base == 2.1 (and > presumably >= 2.2) are the split up base. Add to this that bytestring > was in base == 2.0 (not <=2.0) and in == 2.1.1. > > Is there any reason not to bump the base that comes with GHC 6.8 to > base-2.2? > or 3.0 From ross at soi.city.ac.uk Mon Oct 8 18:56:00 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Mon Oct 8 18:54:46 2007 Subject: Hackage and GHC 6.8 In-Reply-To: <075FF7F4-02AC-44EB-ABDD-5D511ED90006@cs.chalmers.se> References: <20070924010213.GF27284@liouville.galois.com> <20070925083848.GA2551@soi.city.ac.uk> <075FF7F4-02AC-44EB-ABDD-5D511ED90006@cs.chalmers.se> Message-ID: <20071008225600.GA5458@soi.city.ac.uk> On Mon, Oct 08, 2007 at 11:10:02PM +0200, Bjorn Bringert wrote: > On Sep 25, 2007, at 10:38 , Ross Paterson wrote: >> I'm a bit confused about the version numbering for the boot libraries. >> The versions bundled with various versions of GHC are: >> >> ghc-6.6: base-2.0 template-haskell-2.0 unix-1.0 >> ghc-6.6.1: base-2.1.1 template-haskell-2.1 unix-2.1 >> ghc-6.8 RC: base-2.1 template-haskell-0.1 unix-2.0 >> >> What versions are planned for the release? > > This seems quite broken. It makes writing Cabal configurations messy. base > <= 2.0 and == 2.1.1 are the monolithic base. base == 2.1 (and presumably >= > 2.2) are the split up base. Add to this that bytestring was in base == 2.0 > (not <=2.0) and in == 2.1.1. > > Is there any reason not to bump the base that comes with GHC 6.8 to > base-2.2? To allow specifying conservative dependencies, it is also necessary to specify for each boot package the range of version numbers that can ship with GHC 6.8.x (all guaranteed to have the same interface). And, when GHC 6.8.1 is released, to advance the version numbers of these packages in the HEAD beyond these ranges. From bjorn.buckwalter at gmail.com Tue Oct 9 13:46:14 2007 From: bjorn.buckwalter at gmail.com (=?ISO-8859-1?Q?Bj=F6rn_Buckwalter?=) Date: Tue Oct 9 13:44:49 2007 Subject: Fwd: Suitable new name for Dimensional library In-Reply-To: References: <8b2a1a960709271940x2a09b797wbdc95afff221db61@mail.gmail.com> <8b2a1a960709281324x2bd4e28bs454923c20d8dbd29@mail.gmail.com> <8b2a1a960709281327i2d32012bjde176763937db398@mail.gmail.com> Message-ID: <8b2a1a960710091046w400160ebhda0a779383498439@mail.gmail.com> Henning, all, I decided to go with 'Numeric.Units.Dimensional'. I feel that 'Dimensional' provides sufficient differentiation as unit libraries go and the preceding 'Numeric.Units' takes care of my concern of 'Dimensional' being too vague. Thanks all for your inputs! I've released dimensional-0.7 with the new module name space and a few small additions w.r.t. version 0.6. It can be downloaded from the project homepage[1] or hackage. Regards, Bjorn Buckwalter [1] http://dimensional.googlecode.com/ On 10/1/07, Henning Thielemann wrote: > > On Fri, 28 Sep 2007, Bj?rn Buckwalter wrote: > > > Taken further though, if someone develops another "static" unit > > library where should they put it? An arbitrarily complex tree of > > namespaces could be built trying to distinguish libraries to > > anticipate future clashes. > > > > This leads me to wonder -- is it better for a library to have a more > > or less arbitrary differentiating name rather than a descriptive name? > > Examples are 'Text.ParserCombinators.Parsec', 'Text.Parsers.Frisby'. > >> From their names it's not obvious what distinguishes them from other > > parsers in the same namespace but at least the tree is fairly flat and > > hopefully narrowed down enough to permit investigating each > > alternative. In the units case I imagine > > 'Numeric.Units.SomethingArbitrary' would be appropriate. > > Indeed, someone might implement static unit checking by a different > approach. We cannot predict this. So actually it seems to be better to use > an arbitrary differentiating name, say > > Numeric.Units.Bucky > Numeric.Units.Lemming > > Using module names which describe only the module function might work if > there is consensus on its relevance and its API. That is, only for very > basic modules of a 'standard library'. From paul at cogito.org.uk Wed Oct 10 08:51:57 2007 From: paul at cogito.org.uk (Paul Johnson) Date: Wed Oct 10 08:50:32 2007 Subject: Trying to install binary-0.4 Message-ID: <470CCAED.4010702@cogito.org.uk> In my copious free time I'm putting together a client-side library for AMQP. This needs efficient packing of bytestrings, so I downloaded Dons' bytestring 0.4. Unfortunately it won't install: I get [paj@eiffel binary-0.4]$ ./Setup.lhs configure Configuring binary-0.4... configure: Dependency base-any: using base-2.1.1 Setup.lhs: cannot satisfy dependency containers-any Should this be "collections" not "containers"? I can't find a "containers" package in Hackage. Paul. From johan.tibell at gmail.com Wed Oct 10 09:03:28 2007 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed Oct 10 09:02:01 2007 Subject: Trying to install binary-0.4 In-Reply-To: <470CCAED.4010702@cogito.org.uk> References: <470CCAED.4010702@cogito.org.uk> Message-ID: <90889fe70710100603p495f0cf7ua00be0c0360a8600@mail.gmail.com> In the latest version of GHC (6.8) the base library was split up into many smaller libraries. Among them containers. Your problem is probably related to that. I don't have my Haskell setup nearby unfortunately so I can't tell you exactly what the problem is. -- Johan On 10/10/07, Paul Johnson wrote: > In my copious free time I'm putting together a client-side library for > AMQP. This needs efficient packing of bytestrings, so I downloaded > Dons' bytestring 0.4. Unfortunately it won't install: I get > > [paj@eiffel binary-0.4]$ ./Setup.lhs configure > Configuring binary-0.4... > configure: Dependency base-any: using base-2.1.1 > Setup.lhs: cannot satisfy dependency containers-any > > > Should this be "collections" not "containers"? I can't find a > "containers" package in Hackage. > > Paul. > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From mdanish at andrew.cmu.edu Wed Oct 10 09:00:47 2007 From: mdanish at andrew.cmu.edu (Matthew Danish) Date: Wed Oct 10 09:02:22 2007 Subject: Trying to install binary-0.4 In-Reply-To: <470CCAED.4010702@cogito.org.uk> References: <470CCAED.4010702@cogito.org.uk> Message-ID: <20071010130047.GJ29000@mapcar.org> On Wed, Oct 10, 2007 at 01:51:57PM +0100, Paul Johnson wrote: > In my copious free time I'm putting together a client-side library for > AMQP. This needs efficient packing of bytestrings, so I downloaded > Dons' bytestring 0.4. Unfortunately it won't install: I get > > [paj@eiffel binary-0.4]$ ./Setup.lhs configure > Configuring binary-0.4... > configure: Dependency base-any: using base-2.1.1 > Setup.lhs: cannot satisfy dependency containers-any > > > Should this be "collections" not "containers"? I can't find a > "containers" package in Hackage. My guess would be that binary-0.4 is packaged for the new Cabal and GHC, which has split base into many packages like "containers." Either install the release candidate, or, eliminate the unsatisfied dependencies from the .cabal file and hope it compiles. -- -- Matthew Danish -- user: mrd domain: cmu.edu -- OpenPGP public key: C24B6010 on keyring.debian.org From dons at galois.com Wed Oct 10 10:22:29 2007 From: dons at galois.com (Don Stewart) Date: Wed Oct 10 10:21:16 2007 Subject: Trying to install binary-0.4 In-Reply-To: <470CCAED.4010702@cogito.org.uk> References: <470CCAED.4010702@cogito.org.uk> Message-ID: <20071010142229.GA30114@scytale.galois.com> paul: > In my copious free time I'm putting together a client-side library for > AMQP. This needs efficient packing of bytestrings, so I downloaded > Dons' bytestring 0.4. Unfortunately it won't install: I get > > [paj@eiffel binary-0.4]$ ./Setup.lhs configure > Configuring binary-0.4... > configure: Dependency base-any: using base-2.1.1 > Setup.lhs: cannot satisfy dependency containers-any > > > Should this be "collections" not "containers"? I can't find a > "containers" package in Hackage. Since you're not using ghc 6.8, you should use binary 0.3 :) -- Don From paul at cogito.org.uk Wed Oct 10 10:36:45 2007 From: paul at cogito.org.uk (Paul Johnson) Date: Wed Oct 10 10:35:19 2007 Subject: Trying to install binary-0.4 In-Reply-To: <90889fe70710100603p495f0cf7ua00be0c0360a8600@mail.gmail.com> References: <470CCAED.4010702@cogito.org.uk> <90889fe70710100603p495f0cf7ua00be0c0360a8600@mail.gmail.com> Message-ID: <470CE37D.7020403@cogito.org.uk> Johan Tibell wrote: > In the latest version of GHC (6.8) the base library was split up into > many smaller libraries. Among them containers. Your problem is > probably related to that. I don't have my Haskell setup nearby > unfortunately so I can't tell you exactly what the problem is. Looks like I'm going to be upgrading to GHC 6.8 then. Paul. From dons at galois.com Thu Oct 11 19:21:49 2007 From: dons at galois.com (Don Stewart) Date: Thu Oct 11 19:20:19 2007 Subject: X11 package In-Reply-To: <87wstwhanj.fsf@malde.org> References: <20071007125413.GD13126@scytale.galois.com> <87wstwhanj.fsf@malde.org> Message-ID: <20071011232149.GQ25356@scytale.galois.com> ketil: > Don Stewart writes: > > > I've taken over maintainership of the X11 package, as we need it for > > xmonad. The previous maintainer was libraries@. Let me know if you've > > any problems with this. > > Absolutely not! Thanks for doing this. Mind taking over Parsec as > well? :-) > Overwhelming support :) Consider X11 owned. -- Don From dons at galois.com Fri Oct 12 14:35:22 2007 From: dons at galois.com (Don Stewart) Date: Fri Oct 12 14:33:51 2007 Subject: X11 1.2.3 released Message-ID: <20071012183522.GB22287@scytale.galois.com> A new release of X11, ready for ghc 6.8, (and the upcoming xmonad release), is on hackage, and tagged in darcs: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/X11-1.2.3 Main change is Ross fixed the Setup.hs file to not use wacky hooks. Future plans are to merge the X11-extras (aka Xinerama bindings) into X11, for the next release. -- Don From lemming at henning-thielemann.de Fri Oct 12 16:17:01 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Oct 12 16:15:24 2007 Subject: runInteractiveProcess and buffering Message-ID: It looks like my problem has to do with buffering, but I don't know how to solve it. main :: IO () main = do (inp,out,err,pid) <- runInteractiveProcess "aseqdump" ["-p", "72:0"] Nothing Nothing hSetBuffering out NoBuffering hGetBuffering out >>= print hGetLine out >>= putStrLn return () The data of 'out' seems to be buffered, because 'aseqdump' must produce many lines until even the first one is returned by 'hGetLine' and printed by 'putStrLn'. I tried to disable buffering for 'out' and indeed 'NoBuffering' is printed to the terminal, but the output from 'aseqdump' is still deferred. From rfhayes at reillyhayes.com Fri Oct 12 17:30:54 2007 From: rfhayes at reillyhayes.com (R Hayes) Date: Fri Oct 12 17:29:31 2007 Subject: Trying to install binary-0.4 In-Reply-To: <470CCAED.4010702@cogito.org.uk> References: <470CCAED.4010702@cogito.org.uk> Message-ID: <2E0C0BD7-DEFE-4B92-BCF6-78A9BC566A98@reillyhayes.com> Paul, Just out of curiosity, which version of the AMQP spec are you writing to? 0.9? Which implementations of the broker are you testing against? -reilly On Oct 10, 2007, at 5:51 AM, Paul Johnson wrote: > In my copious free time I'm putting together a client-side library > for AMQP. This needs efficient packing of bytestrings, so I > downloaded Dons' bytestring 0.4. Unfortunately it won't install: I > get > > [paj@eiffel binary-0.4]$ ./Setup.lhs configure > Configuring binary-0.4... > configure: Dependency base-any: using base-2.1.1 > Setup.lhs: cannot satisfy dependency containers-any > > > Should this be "collections" not "containers"? I can't find a > "containers" package in Hackage. > > Paul. > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries From agl at imperialviolet.org Fri Oct 12 23:52:46 2007 From: agl at imperialviolet.org (Adam Langley) Date: Fri Oct 12 23:51:08 2007 Subject: runInteractiveProcess and buffering In-Reply-To: References: Message-ID: <396556a20710122052m43b45169n2a0ffb37aca68ee3@mail.gmail.com> On 10/12/07, Henning Thielemann wrote: > The data of 'out' seems to be buffered, because 'aseqdump' must produce > many lines until even the first one is returned by 'hGetLine' and printed > by 'putStrLn'. I tried to disable buffering for 'out' and indeed > 'NoBuffering' is printed to the terminal, but the output from 'aseqdump' > is still deferred. [I suspect this is a job for haskell-cafe@, anyway] Are you sure that you aseqdump isn't buffering itself? The standard C libraries will buffer output at the line level at least, and are free to buffer much more than that if they think that the output is not to a terminal. Try building this code: #include #include int main() { printf("line 1\n"); write(1, "line 2\n", 7); printf("line 3\n"); return 0; } For me (glibc 2.6), if I send stdout to a terminal then it's line buffered and I get the lines in the correct order. However, if I redirect to a file, line 3 comes first because the printf lines are buffered until the process dies. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org 650-283-9641 From ashley at semantic.org Sat Oct 13 04:23:27 2007 From: ashley at semantic.org (Ashley Yakeley) Date: Sat Oct 13 04:22:52 2007 Subject: Proposal: Add Compositor class as superclass of Arrow Message-ID: http://hackage.haskell.org/trac/ghc/ticket/1773 (darcs patch attached to ticket) The Compositor class has two members: class Compositor comp where identity :: comp a a (>>>) :: comp a b -> comp b c -> comp a c with the obvious monoid. Since all Arrows are Compositors, make Compositor a superclass of Arrow. A number of useful types are Compositors but not Arrows: 1. Bijections data Bijection a b = MkBijection (a -> b) (b -> a) 2. Codecs, i.e. encoder/decoder pairs such as charset converters data Codec base derived = MkCodec { encode :: derived -> base, decode :: base -> Maybe derived -- or other Monad } utf8 :: Codec [Word8] String xml :: Codec String XML 3. Lenses These make updatable sections of data structures. data Lens s t = MkLens { lensGet :: s -> t, lensPutback :: t -> s -> s } See http://www.cis.upenn.edu/~bcpierce/papers/lenses-etapsslides.pdf 4. Reified proofs of type identity These are useful if you use GADTs and type-witnesses a lot. newtype SameType a a' = MkSameType (forall f. f a -> f a') Proposal period: two weeks, until 10-27 From apfelmus at quantentunnel.de Sat Oct 13 05:08:57 2007 From: apfelmus at quantentunnel.de (apfelmus) Date: Sat Oct 13 05:07:10 2007 Subject: Proposal: Add Compositor class as superclass of Arrow In-Reply-To: References: Message-ID: Ashley Yakeley wrote: > http://hackage.haskell.org/trac/ghc/ticket/1773 > (darcs patch attached to ticket) > > The Compositor class has two members: > > class Compositor comp where > identity :: comp a a > (>>>) :: comp a b -> comp b c -> comp a c > > with the obvious monoid. Since all Arrows are Compositors, make Yes, bring 'em in! But _only_ under their standard name :) class Category c where id :: c a a (.) :: c b c -> c a b -> c a c subject to the well-known laws f = id . f = f . id f . (g . h) = (f . g) . h Who says category theory isn't for functional programmers? ;) Unfortunately, the names id and (.) are already taken / give headache to those that don't like map :: Functor f => (a -> b) -> f a -> f b . Regards, apfelmus From twanvl at gmail.com Sat Oct 13 07:03:25 2007 From: twanvl at gmail.com (Twan van Laarhoven) Date: Sat Oct 13 07:01:35 2007 Subject: Proposal: Add Compositor class as superclass of Arrow In-Reply-To: References: Message-ID: <4710A5FD.7060306@gmail.com> apfelmus wrote: > Yes, bring 'em in! But _only_ under their standard name :) > > class Category c where > id :: c a a > (.) :: c b c -> c a b -> c a c I think using these names is a good idea, it means that you can write generic code without it becoming an ugly mess of non-standard names. > Unfortunately, the names id and (.) are already taken / give headache > to those that don't like map :: Functor f => (a -> b) -> f a -> f b . I don't see a problem here, if you don't want to use these functions then don't import Control.Category. This is similair to the situation with adding the arrow operators to Data.Tuple. Also, these functions are likely to give less problems than the map function; I can't think of a case where they are not directly used as a function, which immediatly leads to c = (->). I am not a category-theorist, but is Category c the right terminoligy? As I understand it 'c a b' is a morphism between the objects 'a' and 'b' from the category Hask. I don't think there even is a name for the type constructor c itself. When I wrote this exact class for myself a while ago I called it 'Morphism', which makes (some) sense, espacially since we also have the 'Arrow' class. But I realize that morphism is not the correct term either. Twan From paul at cogito.org.uk Sat Oct 13 12:04:22 2007 From: paul at cogito.org.uk (Paul Johnson) Date: Sat Oct 13 12:02:48 2007 Subject: Trying to install binary-0.4 In-Reply-To: <2E0C0BD7-DEFE-4B92-BCF6-78A9BC566A98@reillyhayes.com> References: <470CCAED.4010702@cogito.org.uk> <2E0C0BD7-DEFE-4B92-BCF6-78A9BC566A98@reillyhayes.com> Message-ID: <4710EC86.1090807@cogito.org.uk> R Hayes wrote: > Paul, > > Just out of curiosity, which version of the AMQP spec are you writing > to? 0.9? 0.9 > Which implementations of the broker are you testing against? Not got that far yet. I'm currently working on the framing layer. Paul. From lemming at henning-thielemann.de Sat Oct 13 12:25:06 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat Oct 13 12:23:26 2007 Subject: Applicative functor for building C structs with Storable Message-ID: Are there analogons to ByteString's Put and Get Monads to construct and disect binary data in a C struct for exchange with a C program? From lemming at henning-thielemann.de Sat Oct 13 12:56:32 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat Oct 13 12:54:55 2007 Subject: runInteractiveProcess and buffering In-Reply-To: <396556a20710122052m43b45169n2a0ffb37aca68ee3@mail.gmail.com> References: <396556a20710122052m43b45169n2a0ffb37aca68ee3@mail.gmail.com> Message-ID: On Fri, 12 Oct 2007, Adam Langley wrote: > On 10/12/07, Henning Thielemann wrote: >> The data of 'out' seems to be buffered, because 'aseqdump' must produce >> many lines until even the first one is returned by 'hGetLine' and printed >> by 'putStrLn'. I tried to disable buffering for 'out' and indeed >> 'NoBuffering' is printed to the terminal, but the output from 'aseqdump' >> is still deferred. > > [I suspect this is a job for haskell-cafe@, anyway] > > Are you sure that you aseqdump isn't buffering itself? I'm not sure, I only see that it works when started in a terminal. However if I pipe it to 'less' then the output is deferred for a while. This seems to indicate that the C program actually buffers itself. :-( > The standard C libraries will buffer output at the line level at least, > and are free to buffer much more than that if they think that the output > is not to a terminal. Is this decision done automatically by C's standard library or must the C programmer do this manually? I couldn't find such a switch in the C program. From agl at imperialviolet.org Sat Oct 13 13:29:41 2007 From: agl at imperialviolet.org (Adam Langley) Date: Sat Oct 13 13:28:03 2007 Subject: runInteractiveProcess and buffering In-Reply-To: References: <396556a20710122052m43b45169n2a0ffb37aca68ee3@mail.gmail.com> Message-ID: <396556a20710131029q676c33ddn2ffaba9daa77399b@mail.gmail.com> On 10/13/07, Henning Thielemann wrote: > Is this decision done automatically by C's standard library or must the C > programmer do this manually? I couldn't find such a switch in the C > program. I believe that glibc fstat's FD 1 to find out if stdout is a terminal and sets its buffering up accordingly. The solution is to call fflush(stdout) at the correct places in the C code, or to force the buffering explicitly at the beginning of the program (see man setbuf). AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org 650-283-9641 From agl at imperialviolet.org Sat Oct 13 13:34:31 2007 From: agl at imperialviolet.org (Adam Langley) Date: Sat Oct 13 13:32:52 2007 Subject: Applicative functor for building C structs with Storable In-Reply-To: References: Message-ID: <396556a20710131034s662ecd15he56c6c9570938558@mail.gmail.com> On 10/13/07, Henning Thielemann wrote: > Are there analogons to ByteString's Put and Get Monads to construct and > disect binary data in a C struct for exchange with a C program? The memory layout of structs depends on the ABI of system. You can take a guess and write code in the Get and Put monads. Your guess will probably work pretty well within a single architecture (e.g. x86 or x86-64). However, the portable way to do this is to get the information from the C compiler, which is the approach that c2hs[1] and friends use. I would recommend this unless there's some good reason to think otherwise. (see [2] for the exact hook) [1] http://www.cse.unsw.edu.au/~chak/haskell/c2hs/ [2] http://www.cse.unsw.edu.au/~chak/haskell/c2hs/docu/c2hs-2.html#ss2.8 AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org 650-283-9641 From magnus at therning.org Sat Oct 13 14:26:45 2007 From: magnus at therning.org (Magnus Therning) Date: Sat Oct 13 14:25:08 2007 Subject: Data encoding library Message-ID: <20071013182645.GA3418@die.therning.org> I've just created the page http://haskell.org/haskellwiki/Library/Data_encoding (there are no links into it at the moment). Any comments on what I've written there? Are the locations in the hierarchy good? I have code to share if you are interested in commenting on it as well. Just let me know and I'll find a place to put it for public download. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus?therning?org Jabber: magnus?therning?gmail?com http://therning.org/magnus Windows [n.] A thirty-two bit extension and GUI shell to a sixteen bit patch to an eight bit operating system originally coded for a four bit microprocessor and sold by a two-bit company that can't stand one bit of competition. -- Anonymous USEnet post -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/libraries/attachments/20071013/379d8d6f/attachment.bin From ashley at semantic.org Sat Oct 13 15:34:35 2007 From: ashley at semantic.org (Ashley Yakeley) Date: Sat Oct 13 15:33:20 2007 Subject: Proposal: Add Compositor class as superclass of Arrow In-Reply-To: References: Message-ID: apfelmus wrote: > Yes, bring 'em in! But _only_ under their standard name :) > > class Category c where > id :: c a a > (.) :: c b c -> c a b -> c a c class Category cat where id :: cat a a (.) :: cat b c -> cat a b -> cat a c I'm not against this, but it would mean moving Category to the Prelude. As far as bikeshed issues: 1. I don't care either way about the name. "Category" or "Morphism" would both be fine. 2. I made a sort of "minimal bikeshed" patch, with this from Arrow: (>>>) :: comp a b -> comp b c -> comp a c But I actually prefer (<<<) :: comp b c -> comp a b -> comp a c , like (.). I originally called that member 'compose'. > Unfortunately, the names id and (.) are already taken / give headache > to those that don't like map :: Functor f => (a -> b) -> f a -> f b . I prefer the generalised 'map' too. In fact I always use fmap over lists, map is just one more thing to remember so I don't. But that's another proposal... -- Ashley Yakeley Seattle, WA From apfelmus at quantentunnel.de Sun Oct 14 06:55:28 2007 From: apfelmus at quantentunnel.de (apfelmus) Date: Sun Oct 14 06:53:33 2007 Subject: Data encoding library In-Reply-To: <20071013182645.GA3418@die.therning.org> References: <20071013182645.GA3418@die.therning.org> Message-ID: Magnus Therning wrote: > I've just created the page > http://haskell.org/haskellwiki/Library/Data_encoding (there are no links > into it at the moment). > > Any comments on what I've written there? > Are the locations in the hierarchy good? Nice, but do you really need separate modules for each encoding? I mean, Ashely's proposal > 2. Codecs, i.e. encoder/decoder pairs such as charset converters > > data Codec base derived = MkCodec > { > encode :: derived -> base, > decode :: base -> Maybe derived -- or other Monad > } > > utf8 :: Codec [Word8] String > xml :: Codec String XML from the recent thread http://article.gmane.org/gmane.comp.lang.haskell.libraries/7663 would fit the bill perfectly, wouldn't it? In other words, encodings are just pairs of functions, nothing complicated base16 :: Codec String [Word8] -- decode Strings to Word8 base32 :: Codec String [Word8] base64 :: ... base64url :: uuencode :: For more documentation in the types, a type synonym may come in very handy type ASCII = String base16 :: Codec ASCII [Word8] ... Want to encode an example? Here you go encode base16 [0xde,0xad,0xbe,0xef] :: ASCII Btw, it is essential that decode may fail on bad input! Also, I don't have a clue about what chop and unchop are supposed to do. Regards, apfelmus From apfelmus at quantentunnel.de Sun Oct 14 08:51:51 2007 From: apfelmus at quantentunnel.de (apfelmus) Date: Sun Oct 14 08:50:07 2007 Subject: Proposal: Add Compositor class as superclass of Arrow In-Reply-To: <4710A5FD.7060306@gmail.com> References: <4710A5FD.7060306@gmail.com> Message-ID: Twan van Laarhoven wrote: > apfelmus wrote: > > class Category c where >> id :: c a a >> (.) :: c b c -> c a b -> c a c > >> Unfortunately, the names id and (.) are already taken > > I don't see a problem here, if you don't want to use these functions > then don't import Control.Category. This is similar to the situation > with adding the arrow operators to Data.Tuple. Yes, except that these here are already in the Prelude. But hey, you can always import Control.Category import Prelude hiding (id,(.)) > I am not a category-theorist, but is Category c the right terminology? > As I understand it 'c a b' is a morphism between the objects 'a' and 'b' > from the category Hask. I don't think there even is a name for the type > constructor c itself. When I wrote this exact class for myself a while > ago I called it 'Morphism', which makes (some) sense, especially since > we also have the 'Arrow' class. But I realize that morphism is not the > correct term either. Yeah, neither terminology is correct, but I'd opt for Category for the following reason: While a and b are objects in the category Hask, they may well be phantom types. For instance, c could implement a small stack based domain specific language and the types merely ensure that all stack operations are ok data C a b = Pop | Swap | Int Int | Float Float | Add data a :- b -- empty data Number -- empty pop :: C (a :- s) s swap :: C (a :- b :- s) (b :- a :- s) int :: Int -> C s (Number :- s) float :: Float -> C s (Number :- s) add :: C (Number :- Number :- s) (Number :- s) In the category Hask, those types Number and a :- b are empty but from the viewpoint of our category of stack operations, there are quite a lot of useful morphisms between them. Thus, in a sense, C can redefine the meaning of objects from Hask, so I think of it as more than a Morphism between objects in Hask. Regards, apfelmus From magnus at therning.org Sun Oct 14 12:50:59 2007 From: magnus at therning.org (Magnus Therning) Date: Sun Oct 14 12:49:20 2007 Subject: Data encoding library In-Reply-To: References: <20071013182645.GA3418@die.therning.org> Message-ID: <20071014165059.GA3438@die.therning.org> On Sun, Oct 14, 2007 at 12:55:28 +0200, apfelmus wrote: > Magnus Therning wrote: >> I've just created the page >> http://haskell.org/haskellwiki/Library/Data_encoding (there are no links >> into it at the moment). >> Any comments on what I've written there? >> Are the locations in the hierarchy good? > > Nice, but do you really need separate modules for each encoding? >I mean, Ashely's proposal There is no particular need for separate modules, except that in the current version there would be name clashes. >> 2. Codecs, i.e. encoder/decoder pairs such as charset converters >> data Codec base derived = MkCodec >> { >> encode :: derived -> base, >> decode :: base -> Maybe derived -- or other Monad >> } >> utf8 :: Codec [Word8] String >> xml :: Codec String XML > > from the recent thread > > http://article.gmane.org/gmane.comp.lang.haskell.libraries/7663 > > would fit the bill perfectly, wouldn't it? In other words, encodings are > just pairs of functions, nothing complicated > > base16 :: Codec String [Word8] -- decode Strings to Word8 > base32 :: Codec String [Word8] > base64 :: ... > base64url :: > uuencode :: > > For more documentation in the types, a type synonym may come in very handy > > type ASCII = String > base16 :: Codec ASCII [Word8] > ... > > Want to encode an example? Here you go > > encode base16 [0xde,0xad,0xbe,0xef] :: ASCII A similar result could be gotten by using phantom types, right? But then there must be some way of liberating the result. I'm not sure yet whether they are worth it. AFAIU the example from above then changes to encode [0xde,0xad,0xbe,0xef] :: Base16 ASCII > Btw, it is essential that decode may fail on bad input! I will for sure change the result of decode to deal with failures. > Also, I don't have a clue about what chop and unchop are supposed > to do. For some encodings there are standard ways of splitting an encoded string over several lines. Unfortunately it's not always as simple as just splitting a string at a particular length. Uuencode is the most complicated I've come across so far. That's what chop/unchop is for. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus?therning?org Jabber: magnus?therning?gmail?com http://therning.org/magnus -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/libraries/attachments/20071014/265a91e5/attachment.bin From apfelmus at quantentunnel.de Sun Oct 14 14:11:14 2007 From: apfelmus at quantentunnel.de (apfelmus) Date: Sun Oct 14 14:10:28 2007 Subject: Data encoding library In-Reply-To: <20071014165059.GA3438@die.therning.org> References: <20071013182645.GA3418@die.therning.org> <20071014165059.GA3438@die.therning.org> Message-ID: Magnus Therning wrote: >>> 2. Codecs, i.e. encoder/decoder pairs such as charset converters >>> data Codec base derived = MkCodec >>> { >>> encode :: derived -> base, >>> decode :: base -> Maybe derived -- or other Monad >>> } >>> utf8 :: Codec [Word8] String >>> xml :: Codec String XML >> >> type ASCII = String >> base16 :: Codec ASCII [Word8] >> ... >> >> encode base16 [0xde,0xad,0xbe,0xef] :: ASCII > > A similar result could be gotten by using phantom types, right? Most likely, although I'm not sure whether the choice from your blog is the right one. I mean, the only-a-little-bit-phantom type newtype Base16 a = Base16 { unBase16 :: a } deriving (Eq,Show) will do the job too instance DataEncoding Base16 where encode = Base16 . b16Encode decode = b16Decode . unBase16 chop n = Base16 . b16chop n . unBase16 unchop = Base16 . b16unchop . unBase16 liberate = unBase16 incarcerate = Base16 Usually, the "normal" phantom type approach would be to make the encoding a phantom argument of a string type, not the other way round: newtype EncodedString enc = ES String data Base16 -- empty type, no constructors instance DataEncoding (EncodedString Base16) where ... But your idea of fixing the encoding in the type for more type safety is good. Another way to do that would be to have an abstract data type -- this is not a String, this is base16-encoded data! newtype Base16 = Base16 String with functions encode :: [Word8] -> Base16 decode :: Base16 -> [Word8] and functions encode :: Base16 -> String decode :: String -> Maybe Base16 The "normal" phantom type approach has the advantage of making the last functions polymorphic encode :: EncodedString enc -> String decode :: String -> EncodedString enc encode (ES s) = s decode s = ES s at the expense of shifting the possible failure to decode :: EncodedString Base16 -> Maybe [Word8] Of course, you can use both phantom types and the codec approach eliminating the need for a type class base16 :: Codec [Word8] (EncodedString Base16) string :: Codec (EncodedString a) String > But then there must be some way of liberating the result. > I'm not sure yet whether they are worth it. > > AFAIU the example from above then changes to > > encode [0xde,0xad,0xbe,0xef] :: Base16 ASCII Concerning the choice between encoding the encoding (... ;-) in the types (like Base16) or as values (like base16 :: Codec ...), the observation is that you have to specify the encoding anyway :) either as type annotation ("type argument") encode [0xde,0xad,0xbe,0xef] :: EncodedString Base16 encode' (undefined :: Base16) [0xde,0xad,0xbe,0xef] or as value argument encode base16 [0xde,0xad,0xbe,0xef] In this case, I would prefer the value argument approach for its brevity and mnemonics ("encode in base16 the following data"). However, possible strong type guarantees usually are a good argument for the typed approach. To be true, I'm not really sure whether strong types would gain us something here. >> Also, I don't have a clue about what chop and unchop are supposed >> to do. > > For some encodings there are standard ways of splitting an encoded > string over several lines. Unfortunately it's not always as simple as > just splitting a string at a particular length. Uuencode is the most > complicated I've come across so far. That's what chop/unchop is for. Ah, that's what they are for. An idea would be to build the line length into the encoding, like base16 :: Int -> Codec [Word8] [String] with the intention that encode (base16 70) x will encode x with a line length of 70 characters. Hm, should decode (base16 70) s fail when the lines are not 70 characters in length, or should it accept any line length? Maybe it should be basae16 :: Maybe Int -> Codec [Words8] [String] since the programmer may choose to not wrap lines anyway. But perhaps the line length is best paired with the data base16 :: Codec ([Words8], Maybe Int) [String] so that encode base16 (..., Just 70) x will encode with a line length of 70 characters and let (,ll) = decode base16 s in ... will return the parsed line length in ll . Oh my lambda, it's wondrous how Haskell gives so many possibilities to ponder for such a seemingly innocent API design problem :) Regards, apfelmus From gale at sefer.org Sun Oct 14 15:00:59 2007 From: gale at sefer.org (Yitzchak Gale) Date: Sun Oct 14 14:59:20 2007 Subject: Let's do ListT right, finally Message-ID: <2608b8a80710141200k665403bhfa1ee3cd8ba6692e@mail.gmail.com> Hi Ian, thanks for responding to my plea! I am renaming this thread and moving it to libraries. Please respond there. I wrote: >> http://haskell.org/haskellwiki/ListT_done_right >> and not the broken implementation that comes with mtl. >> (Finally fixed in 6.8? Please?) Ian Lynagh wrote: > If you want to propose that mtl switches to a different definition of > ListT then please see > http://www.haskell.org/haskellwiki/Library_submissions OK, then. This is a major rewrite of this module. So let me open up the topic for discussion even before posting a submission. Do we need to worry about breaking code? Not very much, I suspect. That "monad" really is broken - it's not a monad at all. The problem and its solution have been well known for years. I personally tried using the "standard" ListT for a while, just because it's the standard. Until I ran into enough problems that I finally slapped my forehead and said "forget it". But just in case: Is there anyone reading this who would be hurt by this change and opposes it? Should we provide a more gradual deprecation path (what is it)? Thanks, Yitz From lemming at henning-thielemann.de Sun Oct 14 15:19:24 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun Oct 14 15:17:42 2007 Subject: building and analysing C structs with Storable In-Reply-To: <396556a20710131034s662ecd15he56c6c9570938558@mail.gmail.com> References: <396556a20710131034s662ecd15he56c6c9570938558@mail.gmail.com> Message-ID: On Sat, 13 Oct 2007, Adam Langley wrote: > On 10/13/07, Henning Thielemann wrote: >> Are there analogons to ByteString's Put and Get Monads to construct and >> disect binary data in a C struct for exchange with a C program? > > The memory layout of structs depends on the ABI of system. You can > take a guess and write code in the Get and Put monads. Your guess will > probably work pretty well within a single architecture (e.g. x86 or > x86-64). > > However, the portable way to do this is to get the information from > the C compiler, which is the approach that c2hs[1] and friends use. I > would recommend this unless there's some good reason to think > otherwise. (see [2] for the exact hook) > > [1] http://www.cse.unsw.edu.au/~chak/haskell/c2hs/ > [2] http://www.cse.unsw.edu.au/~chak/haskell/c2hs/docu/c2hs-2.html#ss2.8 I do not quite see the need for an extra tool. I thought it must be possible to ship a Haskell compiler with modules that depend on the system's C compiler, just like the modules that are implemented differently for Windows and Unix. Such modules could provide the functionality to create and inspect C structs for exchange with system libraries. From stefanor at cox.net Sun Oct 14 15:23:00 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Sun Oct 14 15:21:20 2007 Subject: building and analysing C structs with Storable In-Reply-To: References: <396556a20710131034s662ecd15he56c6c9570938558@mail.gmail.com> Message-ID: <20071014192300.GA4089@localhost.localdomain> On Sun, Oct 14, 2007 at 09:19:24PM +0200, Henning Thielemann wrote: > > On Sat, 13 Oct 2007, Adam Langley wrote: > >> On 10/13/07, Henning Thielemann wrote: >>> Are there analogons to ByteString's Put and Get Monads to construct and >>> disect binary data in a C struct for exchange with a C program? >> >> The memory layout of structs depends on the ABI of system. You can >> take a guess and write code in the Get and Put monads. Your guess will >> probably work pretty well within a single architecture (e.g. x86 or >> x86-64). >> >> However, the portable way to do this is to get the information from >> the C compiler, which is the approach that c2hs[1] and friends use. I >> would recommend this unless there's some good reason to think >> otherwise. (see [2] for the exact hook) >> >> [1] http://www.cse.unsw.edu.au/~chak/haskell/c2hs/ >> [2] http://www.cse.unsw.edu.au/~chak/haskell/c2hs/docu/c2hs-2.html#ss2.8 > > I do not quite see the need for an extra tool. I thought it must be > possible to ship a Haskell compiler with modules that depend on the > system's C compiler, just like the modules that are implemented differently > for Windows and Unix. Such modules could provide the functionality to > create and inspect C structs for exchange with system libraries. You say "the system's C compiler" as if there was only one. It's quite common for UNIXoid systems to have several C compilers installed simultaneously; and if you use the module corresponding to the wrong compiler, you get silent data loss. I wouldn't risk it. Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/libraries/attachments/20071014/3c75a374/attachment.bin From lemming at henning-thielemann.de Sun Oct 14 15:28:45 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun Oct 14 15:27:02 2007 Subject: building and analysing C structs with Storable In-Reply-To: <20071014192300.GA4089@localhost.localdomain> References: <396556a20710131034s662ecd15he56c6c9570938558@mail.gmail.com> <20071014192300.GA4089@localhost.localdomain> Message-ID: On Sun, 14 Oct 2007, Stefan O'Rear wrote: > On Sun, Oct 14, 2007 at 09:19:24PM +0200, Henning Thielemann wrote: >> >> On Sat, 13 Oct 2007, Adam Langley wrote: >> >>> On 10/13/07, Henning Thielemann wrote: >>>> Are there analogons to ByteString's Put and Get Monads to construct and >>>> disect binary data in a C struct for exchange with a C program? >>> >>> The memory layout of structs depends on the ABI of system. You can >>> take a guess and write code in the Get and Put monads. Your guess will >>> probably work pretty well within a single architecture (e.g. x86 or >>> x86-64). >>> >>> However, the portable way to do this is to get the information from >>> the C compiler, which is the approach that c2hs[1] and friends use. I >>> would recommend this unless there's some good reason to think >>> otherwise. (see [2] for the exact hook) >>> >>> [1] http://www.cse.unsw.edu.au/~chak/haskell/c2hs/ >>> [2] http://www.cse.unsw.edu.au/~chak/haskell/c2hs/docu/c2hs-2.html#ss2.8 >> >> I do not quite see the need for an extra tool. I thought it must be >> possible to ship a Haskell compiler with modules that depend on the >> system's C compiler, just like the modules that are implemented differently >> for Windows and Unix. Such modules could provide the functionality to >> create and inspect C structs for exchange with system libraries. > > You say "the system's C compiler" as if there was only one. It's quite > common for UNIXoid systems to have several C compilers installed > simultaneously; and if you use the module corresponding to the wrong > compiler, you get silent data loss. I wouldn't risk it. Do different C compilers on the same platform actually use different layouts for structs? If yes, how can I find out, with which compiler a library was compiled? From stefanor at cox.net Sun Oct 14 15:53:09 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Sun Oct 14 15:51:28 2007 Subject: building and analysing C structs with Storable In-Reply-To: References: <396556a20710131034s662ecd15he56c6c9570938558@mail.gmail.com> <20071014192300.GA4089@localhost.localdomain> Message-ID: <20071014195309.GA4174@localhost.localdomain> On Sun, Oct 14, 2007 at 09:28:45PM +0200, Henning Thielemann wrote: > Do different C compilers on the same platform actually use different > layouts for structs? Yes, because there are tradeoffs involved. On x86, the optimal alignment for long double is 8 bytes, but a lot of people aren't crazy about 6 bytes of padding per 10 byte datum, so some compilers default to 4 byte alignment. > If yes, how can I find out, with which compiler a > library was compiled? Ask the person who did the compiling. Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/libraries/attachments/20071014/06b444cd/attachment.bin From lemming at henning-thielemann.de Sun Oct 14 16:05:27 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun Oct 14 16:06:25 2007 Subject: building and analysing C structs with Storable In-Reply-To: <20071014195309.GA4174@localhost.localdomain> References: <396556a20710131034s662ecd15he56c6c9570938558@mail.gmail.com> <20071014192300.GA4089@localhost.localdomain> <20071014195309.GA4174@localhost.localdomain> Message-ID: On Sun, 14 Oct 2007, Stefan O'Rear wrote: > On Sun, Oct 14, 2007 at 09:28:45PM +0200, Henning Thielemann wrote: >> Do different C compilers on the same platform actually use different >> layouts for structs? > > Yes, because there are tradeoffs involved. On x86, the optimal > alignment for long double is 8 bytes, but a lot of people aren't crazy > about 6 bytes of padding per 10 byte datum, so some compilers default to > 4 byte alignment. > >> If yes, how can I find out, with which compiler a >> library was compiled? > > Ask the person who did the compiling. ... but then c2hs cannot do it better (=automatically) than the "compiler dependent Haskell module" approach, can it? From gale at sefer.org Sun Oct 14 16:12:28 2007 From: gale at sefer.org (Yitzchak Gale) Date: Sun Oct 14 16:10:45 2007 Subject: [Haskell-cafe] Let's do ListT right, finally In-Reply-To: <625b74080710141243x5ae2fe81xa767a878644c1f6b@mail.gmail.com> References: <2608b8a80710141200k665403bhfa1ee3cd8ba6692e@mail.gmail.com> <625b74080710141243x5ae2fe81xa767a878644c1f6b@mail.gmail.com> Message-ID: <2608b8a80710141312i4d958bc5h5e19f0f22fc8ecb7@mail.gmail.com> Hi Dan, I wrote: >> That "monad" really is broken - it's not a monad at all. Dan Piponi wrote: > Depending on your point of view, ListT isn't broken. It correctly > transforms commutative monads into monads. Interesting. What do you mean by a "commutative monad"? It can't be a monad with some sort of additional commutative law, because the old ListT doesn't even satisfy the monad laws. Or does it in some sense? > The replacement ListT is usually the monad transformer > I need when I want a List-like monad transformer, > so I'm all for it being in (the standard prelude) mtl. OK. I take this as a +1 vote for the rewrite. > But it seems sad there isn't a place for the old one > to live. OK, do you propose that we keep it and change its name? -Yitz From stefanor at cox.net Sun Oct 14 16:27:13 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Sun Oct 14 16:25:32 2007 Subject: building and analysing C structs with Storable In-Reply-To: References: <396556a20710131034s662ecd15he56c6c9570938558@mail.gmail.com> <20071014192300.GA4089@localhost.localdomain> <20071014195309.GA4174@localhost.localdomain> Message-ID: <20071014202713.GA4230@localhost.localdomain> On Sun, Oct 14, 2007 at 10:05:27PM +0200, Henning Thielemann wrote: > > On Sun, 14 Oct 2007, Stefan O'Rear wrote: > >> On Sun, Oct 14, 2007 at 09:28:45PM +0200, Henning Thielemann wrote: >>> Do different C compilers on the same platform actually use different >>> layouts for structs? >> >> Yes, because there are tradeoffs involved. On x86, the optimal >> alignment for long double is 8 bytes, but a lot of people aren't crazy >> about 6 bytes of padding per 10 byte datum, so some compilers default to >> 4 byte alignment. >> >>> If yes, how can I find out, with which compiler a >>> library was compiled? >> >> Ask the person who did the compiling. > > ... but then c2hs cannot do it better (=automatically) than the "compiler > dependent Haskell module" approach, can it? On second thought, you're right. It would work. However, you still need the information in the header file, due to the possibility of things like __attribute__((packed)). c2hs reads and fully parses the headers themselves; so must your TH binding generator. Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/libraries/attachments/20071014/97370535/attachment.bin From dave at zednenem.com Sun Oct 14 16:50:42 2007 From: dave at zednenem.com (David Menendez) Date: Sun Oct 14 16:49:08 2007 Subject: [Haskell-cafe] Let's do ListT right, finally In-Reply-To: <625b74080710141243x5ae2fe81xa767a878644c1f6b@mail.gmail.com> References: <2608b8a80710141200k665403bhfa1ee3cd8ba6692e@mail.gmail.com> <625b74080710141243x5ae2fe81xa767a878644c1f6b@mail.gmail.com> Message-ID: <49a77b7a0710141350w14f57717ge293a2ac899b6f18@mail.gmail.com> On 10/14/07, Dan Piponi wrote: > On 10/14/07, Yitzchak Gale wrote: > > Not very much, I suspect. That "monad" really is broken - > > it's not a monad at all. > > Depending on your point of view, ListT isn't broken. It correctly > transforms commutative monads into monads. The problem is that you > can't express "commutative monad" any differently from "monad" in > Haskell. And so it's been shoehorned into the wrong type class. If desired, we could easily define a class for commutative monads, and then state that ListT m is only a monad if m is a commutative monad. For example, class Monad m => CommutativeMonad m instance (CommutativeMonad m) => Monad (ListT m) where return a = ListT (return [a]) etc. Naturally, it's up to the programmer to guarantee that instances of CommutativeMonad are actually commutative monads. -- Dave Menendez From gale at sefer.org Sun Oct 14 18:02:27 2007 From: gale at sefer.org (Yitzchak Gale) Date: Sun Oct 14 18:00:51 2007 Subject: [Haskell-cafe] Let's do ListT right, finally In-Reply-To: <49a77b7a0710141350w14f57717ge293a2ac899b6f18@mail.gmail.com> References: <2608b8a80710141200k665403bhfa1ee3cd8ba6692e@mail.gmail.com> <625b74080710141243x5ae2fe81xa767a878644c1f6b@mail.gmail.com> <49a77b7a0710141350w14f57717ge293a2ac899b6f18@mail.gmail.com> Message-ID: <2608b8a80710141502l4c52883w1797c1a9ec3fecdb@mail.gmail.com> David Menendez wrote: > If desired, we could easily define a class for commutative monads, and > then state that ListT m is only a monad if m is a commutative monad. If we do that, can I suggest that we use some name other than ListT for that? So far, we seem to agree that most practical applications use the new ListT. Thanks, Yitz From john at repetae.net Sun Oct 14 23:51:13 2007 From: john at repetae.net (John Meacham) Date: Sun Oct 14 23:49:31 2007 Subject: building and analysing C structs with Storable In-Reply-To: References: <396556a20710131034s662ecd15he56c6c9570938558@mail.gmail.com> <20071014192300.GA4089@localhost.localdomain> Message-ID: <20071015035113.GJ5340@momenergy.repetae.net> On Sun, Oct 14, 2007 at 09:28:45PM +0200, Henning Thielemann wrote: > >You say "the system's C compiler" as if there was only one. It's quite > >common for UNIXoid systems to have several C compilers installed > >simultaneously; and if you use the module corresponding to the wrong > >compiler, you get silent data loss. I wouldn't risk it. > > Do different C compilers on the same platform actually use different > layouts for structs? If yes, how can I find out, with which compiler a > library was compiled? Not in general, the exact layout of C structs and whatnot is set forth in the ABI spec developed by the chip manufacturer. All compilers must follow it or they cannot even use the same libraries. that said, some compilers out there do sometimes deviate from the ABI, or allow it as an option, but there is generally an accepted ABI for a OS-platform pair. Otherwise things like 'libc' would not be abled to be linked against. for instance the ABI for x86-64 is here http://www.x86-64.org/documentation/abi-0.98.pdf John -- John Meacham - ?repetae.net?john? From ramsdell at mitre.org Mon Oct 15 14:32:44 2007 From: ramsdell at mitre.org (John D. Ramsdell) Date: Mon Oct 15 14:31:11 2007 Subject: Linking executables and the library of a Cabal package description Message-ID: I'm sure this will be an easy question for those on this list. What do you need to add to a Cabal package description so as to allow an executable in the description to be built from the library it also describes? I searched the Cabal documentation many times, but came up empty handed. John $ make runhaskell Setup.hs build Preprocessing library a-1.0... Preprocessing executables for a-1.0... Building a-1.0... [1 of 1] Compiling A ( A.hs, dist/build/A.o ) /usr/bin/ar: creating dist/build/libHSa-1.0.a exec/Main.hs:3:7: Could not find module `A': Use -v to see a list of the files searched for. make: *** [all] Error 1 $ : after cleaning... $ more `find . -type f ` > ../a.txt $ cat ../a.txt :::::::::::::: ./a.cabal :::::::::::::: Name: a Version: 1.0 Build-Depends: base Exposed-Modules: A Executable: b Main-Is: Main.hs Other-Modules: A Hs-Source-Dirs: exec :::::::::::::: ./Setup.hs :::::::::::::: import Distribution.Simple main = defaultMain :::::::::::::: ./Makefile :::::::::::::: SETUP = runhaskell Setup.hs all: if test ! -f .setup-config; then $(SETUP) configure; fi $(SETUP) build Makefile: @echo make $@ %: force $(SETUP) $@ .PHONY: all force :::::::::::::: ./A.hs :::::::::::::: module A where a :: Int a = 3 :::::::::::::: ./exec/Main.hs :::::::::::::: module Main (main) where import A main :: IO () main = print a $ ghc -h ghc-6.6.1: unrecognised flags: -h Usage: For basic information, try the `--help' option. $ uname -a Linux goo 2.6.22.9-91.fc7 #1 SMP Thu Sep 27 23:10:59 EDT 2007 i686 i686 i386 GNU/Linux $ From josef.svenningsson at gmail.com Mon Oct 15 15:16:38 2007 From: josef.svenningsson at gmail.com (Josef Svenningsson) Date: Mon Oct 15 15:14:52 2007 Subject: Proposal: Add &&& and *** to Data.Tuple In-Reply-To: <8dde104f0709270644u1b52e1cm49a10083f83eec82@mail.gmail.com> References: <8dde104f0709170623h672ee600t569f1637664d5a6c@mail.gmail.com> <20070917175122.GA8398@matrix.chaos.earth.li> <46EEC677.2020000@cs.nott.ac.uk> <8dde104f0709211015y3269ca9bpea3216f5367ac34@mail.gmail.com> <8dde104f0709270644u1b52e1cm49a10083f83eec82@mail.gmail.com> Message-ID: <8dde104f0710151216k7836c3f8ra75fb165fe050a1@mail.gmail.com> Lads and lasses of the libraries list, The discussion deadline for the proposal of adding &&& and *** to Data.Tuple is up. Here's a summary of the discussion: * Twan van Laarhoven suggested that we should also add functions corresponding to first and second in Control.Arrow. Benjamin Franksen suggested the names onFst and onSnd. There were no objections against this and I've created a new patch which contains these functions as well. * There is a majority for this patch but it's not overwhelming. Here is the current count: In favour: Neil Mitchell, Don Steward, Twan van Laarhoven, Isaac Dupree and myself Against: Ian Lynagh, Henrik Nilsson * I responded to the objections against this patch but haven't gotten any replies so I can't say we've reached a consensus on this one. Despite the fact that we don't have a consensus I interpret the majority as a go for this patch. Cheers, Josef From conal at conal.net Mon Oct 15 16:39:15 2007 From: conal at conal.net (Conal Elliott) Date: Mon Oct 15 16:37:30 2007 Subject: Proposal: Add &&& and *** to Data.Tuple In-Reply-To: <20070920224628.6gmz6wuzsok0s8ow@webmail.spamcop.net> References: <8dde104f0709170623h672ee600t569f1637664d5a6c@mail.gmail.com> <20070917175122.GA8398@matrix.chaos.earth.li> <20070920202337.GA3051@localhost.localdomain> <20070920224628.6gmz6wuzsok0s8ow@webmail.spamcop.net> Message-ID: Maybe I've missed the essence of this discussion, but I seem to see to opposite sentiments running through. One is to create additional, *specialized* (for "->") names for existing general arrow operators, rather than using the generalized versions, citing simpler error messages. The other thread is regret over th Haskell 98 committee having done just this kind of specialization (dumbing down) for monads vs lists. My personal vote is for generality of the language & libraries, and address the newbie issue with training-wheels prelude & libs or something like Jon's "subsumes" proposal. People may say that generality of functions like "first" & "second" is unnecessary for their purposes. Personally, I sometimes find that such "unnecessary" generality leads me to discover that an idea I'm working on is much more general (and therefore useful to others) than I'd originally imagined. I agree that the names "onFst" and "onSnd" are easier to interpret than "first" and "second". So let's use those names for the general (Arrow) versions, rather than the specializations. Comments? Cheers, - Conal On 9/20/07, ajb@spamcop.net wrote: > > G'day all. > > Quoting Stefan O'Rear : > > > The reason ++ and mplus is so similar is that they used to be the same; > > (++) *was* the MonadPlus class member. Cale Gibbard explains this as > > {{{Quite a few people on the Haskell 98 committee had an irrational fear > > of polymorphism.}}} > > That's a slight exaggeration. They actually had nightmares involving > trying to explain to their undergraduate students what the inevitable > type error messages meant. > > At a time when Haskell was mostly a teaching/research language, this made > a certain amount of sense. Now that Haskell is officially Cool(tm), the > argument is much weaker. > > Cheers, > Andrew Bromage > _______________________________________________ > 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/20071015/83685aec/attachment.htm From duncan.coutts at worc.ox.ac.uk Mon Oct 15 16:44:05 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Oct 15 16:51:27 2007 Subject: Applicative functor for building C structs with Storable In-Reply-To: References: Message-ID: <1192481045.9844.143.camel@localhost> On Sat, 2007-10-13 at 18:25 +0200, Henning Thielemann wrote: > Are there analogons to ByteString's Put and Get Monads to construct and > disect binary data in a C struct for exchange with a C program? It's certainly possible. As John Meacham says on most platforms there is a standard ABI (ie standard on that platform, not standard between platforms). So one could make a lib on top of Data.Binary.Get/Put that embeds the knowledge about some particular platform's C struct ABI and allows reading/writing them. Like, Data.Binary's Get/Put it could be used just via the Applicative combinators. You could probably also get a good deal of code re-use between different platform ABIs by parametrising by things like alignment, endianness, size of primitives etc. Duncan From bernardy at chalmers.se Mon Oct 15 17:31:37 2007 From: bernardy at chalmers.se (Jean-Philippe Bernardy) Date: Mon Oct 15 17:29:51 2007 Subject: Proposal: Add &&& and *** to Data.Tuple In-Reply-To: References: <8dde104f0709170623h672ee600t569f1637664d5a6c@mail.gmail.com> <20070917175122.GA8398@matrix.chaos.earth.li> <20070920202337.GA3051@localhost.localdomain> <20070920224628.6gmz6wuzsok0s8ow@webmail.spamcop.net> Message-ID: <953e0d250710151431n28787050g5282ff3d20c441f0@mail.gmail.com> > Comments? +1 -- JP From ross at soi.city.ac.uk Mon Oct 15 19:50:03 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Mon Oct 15 19:48:33 2007 Subject: Proposal: Add &&& and *** to Data.Tuple In-Reply-To: <8dde104f0710151216k7836c3f8ra75fb165fe050a1@mail.gmail.com> References: <8dde104f0709170623h672ee600t569f1637664d5a6c@mail.gmail.com> <20070917175122.GA8398@matrix.chaos.earth.li> <46EEC677.2020000@cs.nott.ac.uk> <8dde104f0709211015y3269ca9bpea3216f5367ac34@mail.gmail.com> <8dde104f0709270644u1b52e1cm49a10083f83eec82@mail.gmail.com> <8dde104f0710151216k7836c3f8ra75fb165fe050a1@mail.gmail.com> Message-ID: <20071015235003.GB2716@soi.city.ac.uk> On Mon, Oct 15, 2007 at 09:16:38PM +0200, Josef Svenningsson wrote: > Despite the fact that we don't have a consensus I interpret the > majority as a go for this patch. In general, I think it's important to try for consensus with the core libraries. The discussion it requires is much more likely to explore the issues. Voting should be the last resort. From ajb at spamcop.net Mon Oct 15 22:54:04 2007 From: ajb at spamcop.net (ajb@spamcop.net) Date: Mon Oct 15 22:52:16 2007 Subject: Proposal: Add &&& and *** to Data.Tuple In-Reply-To: References: <8dde104f0709170623h672ee600t569f1637664d5a6c@mail.gmail.com> <20070917175122.GA8398@matrix.chaos.earth.li> <20070920202337.GA3051@localhost.localdomain> <20070920224628.6gmz6wuzsok0s8ow@webmail.spamcop.net> Message-ID: <20071015225404.vsgd1vaitc4so8kg@webmail.spamcop.net> G'day all. Quoting Conal Elliott : > Maybe I've missed the essence of this discussion, but I seem to see to > opposite sentiments running through. One is to create additional, > *specialized* (for "->") names for existing general arrow operators, rather > than using the generalized versions, citing simpler error messages. The > other thread is regret over th Haskell 98 committee having done just this > kind of specialization (dumbing down) for monads vs lists. Just for the record, my problem is not that there are specialised versions of things for lists/functions rather than monads/arrows, but rather that some of the "good" names are taken by the specialised versions (e.g. map vs fmap). I should point out the following operations, which are in Data.Graph.Inductive.Query.Monad (so no wonder nobody knows about them): mapFst :: (a -> b) -> (a, c) -> (b, c) mapSnd :: (a -> b) -> (c, a) -> (c, b) (><) :: (a -> b) -> (c -> d) -> (a, c) -> (b, d) How about moving those into Data.Tuple, along with a work-alike for (***)? How about (>*<)? Cheers, Andrew Bromage From bertram.felgenhauer at googlemail.com Tue Oct 16 01:44:54 2007 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Tue Oct 16 01:43:15 2007 Subject: Proposal: Add &&& and *** to Data.Tuple In-Reply-To: References: <8dde104f0709170623h672ee600t569f1637664d5a6c@mail.gmail.com> <20070917175122.GA8398@matrix.chaos.earth.li> <20070920202337.GA3051@localhost.localdomain> <20070920224628.6gmz6wuzsok0s8ow@webmail.spamcop.net> Message-ID: <20071016054454.GA4246@zombie.inf.tu-dresden.de> Conal Elliott wrote: > Maybe I've missed the essence of this discussion, but I seem to see to > opposite sentiments running through. One is to create additional, > *specialized* (for "->") names for existing general arrow operators, rather > than using the generalized versions, citing simpler error messages. The > other thread is regret over th Haskell 98 committee having done just this > kind of specialization (dumbing down) for monads vs lists. > I agree that the names "onFst" and "onSnd" are easier to interpret than > "first" and "second". So let's use those names for the general (Arrow) > versions, rather than the specializations. Changing the names of 'first' and 'second' in Control.Arrow is a bad idea, I think. It'll break a lot of packages. Adding functions that conflict with Control.Arrow in Data.Tuple looks far less problematic, because Data.Tuple is quite rarely used. The Prelude reexport of Data.Tuple for nhc should be pruned, however. Data points: Number of occurences of "Data.Tuple" in various packages: (note: not all of these are package imports.) 9 ghc/libraries/base/ 7 ghc/ 5 ghc/testsuite/ 4 lambdabot/ 1 ghc/libraries/template-haskell/ Same for "Control.Arrow": (note: includes non-imports and imports like Control.Arrow.ListArrow, so it's overcounting quite a bit) 174 hxt/ 128 ghc/libraries/arrows/ 21 ghc/testsuite/ 16 lambdabot/ 6 ghc/ 5 ghc/libraries/base/ 2 ghc/libraries/containers/ 1 xmonad/ The sample consists of ghc + testsuite + libraries + extra libraries, HAppS, X11-extras, binary, derive, gtk2hs, haddock, hssdl, http, hxt, jhc, lambdabot, tagsoup, uniplate, xmonad and zlib. Bertram From lemming at henning-thielemann.de Tue Oct 16 03:44:27 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Oct 16 03:42:43 2007 Subject: building and analysing C structs with Storable In-Reply-To: <20071015035113.GJ5340@momenergy.repetae.net> References: <396556a20710131034s662ecd15he56c6c9570938558@mail.gmail.com> <20071014192300.GA4089@localhost.localdomain> <20071015035113.GJ5340@momenergy.repetae.net> Message-ID: On Sun, 14 Oct 2007, John Meacham wrote: > On Sun, Oct 14, 2007 at 09:28:45PM +0200, Henning Thielemann wrote: >>> You say "the system's C compiler" as if there was only one. It's quite >>> common for UNIXoid systems to have several C compilers installed >>> simultaneously; and if you use the module corresponding to the wrong >>> compiler, you get silent data loss. I wouldn't risk it. >> >> Do different C compilers on the same platform actually use different >> layouts for structs? If yes, how can I find out, with which compiler a >> library was compiled? > > Not in general, the exact layout of C structs and whatnot is set forth > in the ABI spec developed by the chip manufacturer. All compilers must > follow it or they cannot even use the same libraries. that said, some > compilers out there do sometimes deviate from the ABI, or allow it as an > option, but there is generally an accepted ABI for a OS-platform pair. > Otherwise things like 'libc' would not be abled to be linked against. This means, if this knowledge is baked into system dependent instances of Storable (especially 'alignment') then generic routines for constructing and disecting C structs are straightforward to implement. Right? From duncan.coutts at worc.ox.ac.uk Tue Oct 16 05:46:26 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Oct 16 05:41:53 2007 Subject: CPP confusion Message-ID: <1192527986.9844.175.camel@localhost> All, There seems to me to be a great deal of confusion with CPP options in Haskell land. We apply the same cpp options to C code and to Haskell code, and there are other tools like pre-processors which make things even more confusing. The latest thing I've stumbled over is HsUnix.h in ghc-6.8. This header file is for defines to use when pre-processing Haskell code. It used to live in the global $GHCLIBDIR/include but now lives in the include dir for the unix package. This is probably the right thing to do, however... How do packages that want to use this include actually use it? If they #include it directly in a .hs file then it'll work since ghc -package unix adds the unix package's include dir to the search path. But what if someone needs to use it in a .hsc file? Well, then it does not work. It does not work because Cabal does not pass these include directories to hsc2hs, since we've relied on ghc to do that. But obviously that does not work for hsc2hs. As it happens the fork of hsc2hs that ghc comes bundled with uses ghc as it's C compiler, so we could in fact pass hsc2hs --cflag=-package --cflag=unix then it does work because hsc2hs ends up passing ghc -package unix and then ghc adds the unix's include dir to the search path when it goes on to call gcc to actually compile the C code. Yay, for many layers of confusion. So what is the solution? We could take advantage of the fact that we know that hsc2hs really uses ghc as it's C compiler and change the flags we pass it when we happen to be building with ghc. On the other hand this all becomes non-portable. In fact this totally relies on a package database to remember what search directories to use when pre-processing dependent packages. In other words it only has a chance of working with ghc at the moment, or nhc in future if/when it implements a package database. What to do? Short and long term suggestions please. Duncan From simonmarhaskell at gmail.com Tue Oct 16 08:08:49 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Oct 16 08:07:06 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <200710162354.37812.dm.maillists@gmail.com> References: <20071014140922.GA25871@matrix.chaos.earth.li> <20071015203802.GA3229@web.de> <47147355.6020109@gmail.com> <200710162354.37812.dm.maillists@gmail.com> Message-ID: <4714A9D1.8070501@microsoft.com> Several good points have been raised in this thread, and while I might not agree with everything, I think we can all agree on the goal: things shouldn't break so often. So rather than keep replying to individual points, I'd like to make some concrete proposals so we can make progress. 1. Document the version numbering policy. We should have done this earlier, but we didn't. The proposed policy, for the sake of completeness is: x.y where: x changes ==> API changed x constant but y changes ==> API extended only x and y constant ==> API is identical further sub-versions may be added after the x.y, their meaning is package-defined. Ordering on versions is lexicographic, given multiple versions that satisfy a dependency Cabal will pick the latest. 2. Precise dependencies. As suggested by various people in this thread: we change the convention so that dependencies must specify a single x.y API version, or a range of versions with an upper bound. Cabal or Hackage can refuse to accept packages that don't follow this convention (perhaps Hackage is a better place to enforce it, and Cabal should just warn, I'm not sure). Yes, earlier I argued that not specifying precise dependencies allows some packages to continue working even when dependencies change, and that having precise dependencies means that all packages are guaranteed to break when base is updated. However, I agree that specifying precise dependencies is ultimately the right thing, we'll get better errors when things break, There's lots more to discuss, but I think the above 2 proposals are a step in the right direction, agreed? Cheers, Simon From Alistair_Bayley at invescoperpetual.co.uk Tue Oct 16 08:15:28 2007 From: Alistair_Bayley at invescoperpetual.co.uk (Bayley, Alistair) Date: Tue Oct 16 08:13:46 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <4714A9D1.8070501@microsoft.com> References: <20071014140922.GA25871@matrix.chaos.earth.li> <20071015203802.GA3229@web.de><47147355.6020109@gmail.com><200710162354.37812.dm.maillists@gmail.com> <4714A9D1.8070501@microsoft.com> Message-ID: <125EACD0CAE4D24ABDB4D148C4593DA9049E9015@GBLONXMB02.corp.amvescap.net> > From: libraries-bounces@haskell.org > [mailto:libraries-bounces@haskell.org] On Behalf Of Simon Marlow > > x changes ==> API changed > x constant but y changes ==> API extended only > x and y constant ==> API is identical > > Ordering on versions is lexicographic, given multiple > versions that satisfy a dependency Cabal will pick the latest. Just a minor point, but would mind explaining exactly what lexicographic ordering implies? It appears to me that e.g. version 9.3 of a package would be preferred over version 10.0. That strikes me as counter-intuitive. Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ***************************************************************** From haskell at list.mightyreason.com Tue Oct 16 08:32:46 2007 From: haskell at list.mightyreason.com (ChrisK) Date: Tue Oct 16 08:31:13 2007 Subject: Proposal: register a package as providing several API versions In-Reply-To: <4714A9D1.8070501@microsoft.com> References: <20071014140922.GA25871@matrix.chaos.earth.li> <20071015203802.GA3229@web.de> <47147355.6020109@gmail.com> <200710162354.37812.dm.maillists@gmail.com> <4714A9D1.8070501@microsoft.com> Message-ID: <4714AF6E.70903@list.mightyreason.com> Simon Marlow wrote: > Several good points have been raised in this thread, and while I might > not agree with everything, I think we can all agree on the goal: things > shouldn't break so often. I have another concrete proposal to avoid things breaking so often. Let us steal from something that works: shared library versioning on unixy systems. On Max OS X, I note that I have, in /usr/lib: > lrwxr-xr-x 1 root wheel 15 Jul 24 2005 libcurl.2.dylib -> libcurl.3.dylib > lrwxr-xr-x 1 root wheel 15 Jul 24 2005 libcurl.3.0.0.dylib -> libcurl.3.dylib > -rwxr-xr-x 1 root wheel 201156 Aug 17 17:14 libcurl.3.dylib > lrwxr-xr-x 1 root wheel 15 Jul 24 2005 libcurl.dylib -> libcurl.3.dylib The above declaratively expresses that libcurl-3.3.0 provides the version 3 API and the version 2 API. This is the capability that should be added to Haskell library packages. Right now a library can only declare a single version number. So if I update hsFoo from 2.1.1 to 3.0.0 then I cannot express whether or not the version 3 API is a superset of (backward compatible with) the version 2 API. Once it is possible to have cabal register the hsFoo-3.0.0 also as hsFoo-2 it will be easy to upgrade to hsFoo. No old programs will fail to compile. Who here knows enough about the ghc-pkg database to say how easy or hard this would be? -- Chris From simonmarhaskell at gmail.com Tue Oct 16 08:45:09 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Oct 16 08:43:34 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <125EACD0CAE4D24ABDB4D148C4593DA9049E9015@GBLONXMB02.corp.amvescap.net> References: <20071014140922.GA25871@matrix.chaos.earth.li> <20071015203802.GA3229@web.de><47147355.6020109@gmail.com><200710162354.37812.dm.maillists@gmail.com> <4714A9D1.8070501@microsoft.com> <125EACD0CAE4D24ABDB4D148C4593DA9049E9015@GBLONXMB02.corp.amvescap.net> Message-ID: <4714B255.7030709@gmail.com> Bayley, Alistair wrote: >> From: libraries-bounces@haskell.org >> [mailto:libraries-bounces@haskell.org] On Behalf Of Simon Marlow >> >> x changes ==> API changed >> x constant but y changes ==> API extended only >> x and y constant ==> API is identical >> >> Ordering on versions is lexicographic, given multiple >> versions that satisfy a dependency Cabal will pick the latest. > > Just a minor point, but would mind explaining exactly what lexicographic > ordering implies? It appears to me that e.g. version 9.3 of a package > would be preferred over version 10.0. That strikes me as > counter-intuitive. The lexicographical ordering would make 10.0 > 9.3. In general, A.B > C.D iff A > C or A == C && B > D. When we say the "latest" version we mean "greatest", implying that version numbers increase with time. Does that help? Cheers, Simon From simonmarhaskell at gmail.com Tue Oct 16 08:57:01 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Oct 16 08:55:20 2007 Subject: Proposal: register a package as providing several API versions In-Reply-To: <4714AF6E.70903@list.mightyreason.com> References: <20071014140922.GA25871@matrix.chaos.earth.li> <20071015203802.GA3229@web.de> <47147355.6020109@gmail.com> <200710162354.37812.dm.maillists@gmail.com> <4714A9D1.8070501@microsoft.com> <4714AF6E.70903@list.mightyreason.com> Message-ID: <4714B51D.7060507@gmail.com> ChrisK wrote: > Simon Marlow wrote: >> Several good points have been raised in this thread, and while I might >> not agree with everything, I think we can all agree on the goal: things >> shouldn't break so often. > > I have another concrete proposal to avoid things breaking so often. Let us > steal from something that works: shared library versioning on unixy systems. > > On Max OS X, I note that I have, in /usr/lib: >> lrwxr-xr-x 1 root wheel 15 Jul 24 2005 libcurl.2.dylib -> libcurl.3.dylib >> lrwxr-xr-x 1 root wheel 15 Jul 24 2005 libcurl.3.0.0.dylib -> libcurl.3.dylib >> -rwxr-xr-x 1 root wheel 201156 Aug 17 17:14 libcurl.3.dylib >> lrwxr-xr-x 1 root wheel 15 Jul 24 2005 libcurl.dylib -> libcurl.3.dylib > > The above declaratively expresses that libcurl-3.3.0 provides the version 3 API > and the version 2 API. > > This is the capability that should be added to Haskell library packages. > > Right now a library can only declare a single version number. So if I update > hsFoo from 2.1.1 to 3.0.0 then I cannot express whether or not the version 3 API > is a superset of (backward compatible with) the version 2 API. Certainly, this is something we want to support. However, there's an important difference between shared-library linking and Haskell: in Haskell, a superset of an API is not backwards-compatible, because it has the potential to cause new name clashes. > Once it is possible to have cabal register the hsFoo-3.0.0 also as hsFoo-2 it > will be easy to upgrade to hsFoo. No old programs will fail to compile. > > Who here knows enough about the ghc-pkg database to say how easy or hard this > would be? It could be done using the tricks that Claus just posted and I followed up on. You'd need a separate package for hsFoo-2 that specifies exactly which bits of hsFoo-3 are re-exported. Given some Cabal support and a little extension in GHC, this could be made relatively painless for the library maintainer. Cheers, Simon From Alistair_Bayley at invescoperpetual.co.uk Tue Oct 16 09:01:01 2007 From: Alistair_Bayley at invescoperpetual.co.uk (Bayley, Alistair) Date: Tue Oct 16 08:59:20 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <4714B255.7030709@gmail.com> References: <20071014140922.GA25871@matrix.chaos.earth.li> <20071015203802.GA3229@web.de><47147355.6020109@gmail.com><200710162354.37812.dm.maillists@gmail.com> <4714A9D1.8070501@microsoft.com> <125EACD0CAE4D24ABDB4D148C4593DA9049E9015@GBLONXMB02.corp.amvescap.net> <4714B255.7030709@gmail.com> Message-ID: <125EACD0CAE4D24ABDB4D148C4593DA9049E9017@GBLONXMB02.corp.amvescap.net> > From: Simon Marlow [mailto:simonmarhaskell@gmail.com] > > The lexicographical ordering would make 10.0 > 9.3. In > general, A.B > C.D > iff A > C or A == C && B > D. When we say the "latest" > version we mean > "greatest", implying that version numbers increase with time. > Does that help? Sort of. It's what I'd expect from a sensible version comparison. It's just not something I'd ever choose to call lexicographic ordering. IMO, lexicographgic ordering is a basic string comparision so e.g. max "10.0" "9.3" = "9.3" I'd call what you're doing numeric ordering. Does it have a better name, like version-number-ordering, or section-number-ordering (e.g. Section 3.2.5, Section 3.2.6)? Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ***************************************************************** From simonmarhaskell at gmail.com Tue Oct 16 09:05:52 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Oct 16 09:04:08 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <125EACD0CAE4D24ABDB4D148C4593DA9049E9017@GBLONXMB02.corp.amvescap.net> References: <20071014140922.GA25871@matrix.chaos.earth.li> <20071015203802.GA3229@web.de><47147355.6020109@gmail.com><200710162354.37812.dm.maillists@gmail.com> <4714A9D1.8070501@microsoft.com> <125EACD0CAE4D24ABDB4D148C4593DA9049E9015@GBLONXMB02.corp.amvescap.net> <4714B255.7030709@gmail.com> <125EACD0CAE4D24ABDB4D148C4593DA9049E9017@GBLONXMB02.corp.amvescap.net> Message-ID: <4714B730.1050503@microsoft.com> Bayley, Alistair wrote: >> From: Simon Marlow [mailto:simonmarhaskell@gmail.com] >> >> The lexicographical ordering would make 10.0 > 9.3. In >> general, A.B > C.D >> iff A > C or A == C && B > D. When we say the "latest" >> version we mean >> "greatest", implying that version numbers increase with time. >> Does that help? > > > Sort of. It's what I'd expect from a sensible version comparison. It's > just not something I'd ever choose to call lexicographic ordering. IMO, > lexicographgic ordering is a basic string comparision so e.g. > > max "10.0" "9.3" = "9.3" > > I'd call what you're doing numeric ordering. Does it have a better name, > like version-number-ordering, or section-number-ordering (e.g. Section > 3.2.5, Section 3.2.6)? I've heard it called lexicographical ordering before, but I'm happy to call it by whatever name induces the least confusion! Cheers, Simon From simonmarhaskell at gmail.com Tue Oct 16 09:19:33 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Oct 16 09:17:53 2007 Subject: Linking executables and the library of a Cabal package description In-Reply-To: References: Message-ID: <4714BA65.6080202@gmail.com> John D. Ramsdell wrote: > I'm sure this will be an easy question for those on this list. What > do you need to add to a Cabal package description so as to allow an > executable in the description to be built from the library it also > describes? I searched the Cabal documentation many times, but came up > empty handed. > > John > > $ make > runhaskell Setup.hs build > Preprocessing library a-1.0... > Preprocessing executables for a-1.0... > Building a-1.0... > [1 of 1] Compiling A ( A.hs, dist/build/A.o ) > /usr/bin/ar: creating dist/build/libHSa-1.0.a > > exec/Main.hs:3:7: > Could not find module `A': > Use -v to see a list of the files searched for. I'm not sure exactly what problem you're running into here, but my advice would be to split the library off into a separate package. Libraries and executables in the same package are not well supported by Cabal. Really we should fix or remove that feature, my vote would be to remove it. Cheers, Simon From stefanor at cox.net Tue Oct 16 10:09:56 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Tue Oct 16 10:08:16 2007 Subject: [Haskell-cafe] Re: Proposal: register a package as providing several API versions In-Reply-To: <4714B51D.7060507@gmail.com> References: <20071014140922.GA25871@matrix.chaos.earth.li> <20071015203802.GA3229@web.de> <47147355.6020109@gmail.com> <200710162354.37812.dm.maillists@gmail.com> <4714A9D1.8070501@microsoft.com> <4714AF6E.70903@list.mightyreason.com> <4714B51D.7060507@gmail.com> Message-ID: <20071016140956.GA3284@localhost.localdomain> On Tue, Oct 16, 2007 at 01:57:01PM +0100, Simon Marlow wrote: > Certainly, this is something we want to support. However, there's an > important difference between shared-library linking and Haskell: in > Haskell, a superset of an API is not backwards-compatible, because it has > the potential to cause new name clashes. This is the case on Unixy .so systems too, because the namespace is flat. If libreadline suddenly starts exporting a symbol named SDL_init, programs which use both readline and sdl will break. I have not seen this happen in practice. (Which might have something to do with the aforementioned name mangling :)) Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/libraries/attachments/20071016/bbca6c34/attachment.bin From apfelmus at quantentunnel.de Tue Oct 16 09:48:19 2007 From: apfelmus at quantentunnel.de (apfelmus) Date: Tue Oct 16 10:34:38 2007 Subject: Proposal: register a package as providing several API versions In-Reply-To: <4714AF6E.70903@list.mightyreason.com> References: <20071014140922.GA25871@matrix.chaos.earth.li> <20071015203802.GA3229@web.de> <47147355.6020109@gmail.com> <200710162354.37812.dm.maillists@gmail.com> <4714A9D1.8070501@microsoft.com> <4714AF6E.70903@list.mightyreason.com> Message-ID: Simon Marlow wrote: > The proposed policy, for the sake of completeness is: x.y where: > > x changes ==> API changed > x constant but y changes ==> API extended only > x and y constant ==> API is identical > [..] > dependencies must specify a single x.y API version, or a range of > versions with an upper bound. What about x == 0? I mean, the intention of 0 is that 0.1, 0.2 and so on may well overthrow the API. But that's a bikeshed issue. ChrisK wrote: > The above declaratively expresses that libcurl-3.3.0 provides the version 3 API > and the version 2 API. Good idea. In the end, both proposals are based on the same observation: the dependency knows best which of its versions are compatible and which aren't. It's *not* a responsibility of the dependent package to know that. It only has to know one particular version it compiles against. So, it would just specify "I do compile with foobar 1.2" and let foobar 1.3 decide whether it's compatible with 1.2 or not. Given Simon's proposed policy, the answer would be "yes", if it were not for possible name clashes: > However, there's an important difference between shared-library > linking and Haskell: in Haskell, a superset of an API is not > backwards-compatible, because it has the potential to cause new name clashes. Solution? explicit imports? explicit module signatures with subtyping? implicit signature conversion foobar 1.3 -> foobar 1.2 on the package level? Regards, apfelmus From ketil+haskell at ii.uib.no Tue Oct 16 10:37:21 2007 From: ketil+haskell at ii.uib.no (Ketil Malde) Date: Tue Oct 16 10:35:40 2007 Subject: Proposal: register a package as providing several API versions In-Reply-To: <4714AF6E.70903@list.mightyreason.com> (ChrisK's message of "Tue\, 16 Oct 2007 13\:32\:46 +0100") References: <20071014140922.GA25871@matrix.chaos.earth.li> <20071015203802.GA3229@web.de> <47147355.6020109@gmail.com> <200710162354.37812.dm.maillists@gmail.com> <4714A9D1.8070501@microsoft.com> <4714AF6E.70903@list.mightyreason.com> Message-ID: <87hckrf7mm.fsf@nmd9999.imr.no> ChrisK writes: > Once it is possible to have cabal register the hsFoo-3.0.0 also as hsFoo-2 it > will be easy to upgrade to hsFoo. No old programs will fail to compile. > Who here knows enough about the ghc-pkg database to say how easy or hard this > would be? Ignoring disk space, I suppose the motivation is that it will ease the user experience by only having to download, compile and install a single package? And perhaps ease the maintenance a bit for the library author, too. One way to do this would be to have multiple .cabal files in the package, with small differences like different version numbering. You can use a Makefile or other hack to automate switching. -k -- If I haven't seen further, it is by standing in the footprints of giants From claus.reinke at talk21.com Tue Oct 16 11:38:34 2007 From: claus.reinke at talk21.com (Claus Reinke) Date: Tue Oct 16 11:36:50 2007 Subject: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4 References: <20071014140922.GA25871@matrix.chaos.earth.li> <20071015203802.GA3229@web.de><47147355.6020109@gmail.com><200710162354.37812.dm.maillists@gmail.com> <4714A9D1.8070501@microsoft.com> Message-ID: <02c001c8100a$9e9f8170$5b238351@cr3lt> > 1. Document the version numbering policy. agreed. just making everybody's interpretation explicit has already exposed subtle differences, so documenting common ground will help. > We should have done this earlier, but we didn't. The proposed policy, for > the sake of completeness is: x.y where: > > x changes ==> API changed > x constant but y changes ==> API extended only > x and y constant ==> API is identical > > further sub-versions may be added after the x.y, their meaning is > package-defined. Ordering on versions is lexicographic, given multiple > versions that satisfy a dependency Cabal will pick the latest. referring to a haskell function to compute ordering, or to parse version strings into lists of numbers, might remove ambiguities here. for instance, some people use patch-levels as sub-versions, some use dates. also, compare Simon's (S) with Daniel's (D) version: | If the convention for modifying package versions of form x.y.z is: | - increment z for bugfixes/changes that don't alter the interface | - increment y for changes that consist solely of additions to the interface, | parts of the interface may be marked as deprecated | - increment x for changes that include removal of deprecated parts of the | interface version D gives us strictly more information from a version number: just from number differences, we can tell what kind of changes happened to the api. i like that. version S is closer to current practice, which is less informative but psychologically motivated:-) if one does a substantial rewrite without changing the api, or if one adds fundamentally new features without breaking backwards compatibility, one likes to bump the leading number (that is no doubt inspired by commercialism: paying customers are said to prefer higher version numbers, and to focus on new features). corollary: after fixing the version numbering policy (policies?), the implications on usage need to be investigated (sorting wrt dates? does a version number tell us anything about which version can stand in for which dependency?). > 2. Precise dependencies. > > As suggested by various people in this thread: we change the convention so > that dependencies must specify a single x.y API version, or a range of > versions with an upper bound. Cabal or Hackage can refuse to accept > packages that don't follow this convention (perhaps Hackage is a better > place to enforce it, and Cabal should just warn, I'm not sure). > > Yes, earlier I argued that not specifying precise dependencies allows some > packages to continue working even when dependencies change, and that having > precise dependencies means that all packages are guaranteed to break when > base is updated. However, I agree that specifying precise dependencies is > ultimately the right thing, we'll get better errors when things break, agreed. please note, however, that this is likely to flush out issues that have so far been swiped under the carpet. this is a good thing, as it will lead to proposals for making cabal deal with these issues properly (replacing unspecified user complaints with concrete bugs and fixes). but it will increase the noise!-) claus From claus.reinke at talk21.com Tue Oct 16 11:41:11 2007 From: claus.reinke at talk21.com (Claus Reinke) Date: Tue Oct 16 11:39:27 2007 Subject: [Haskell-cafe] Re: Proposal: register a package as providingseveral API versions References: <20071014140922.GA25871@matrix.chaos.earth.li> <20071015203802.GA3229@web.de> <47147355.6020109@gmail.com> <200710162354.37812.dm.maillists@gmail.com><4714A9D1.8070501@microsoft.com><4714AF6E.70903@list.mightyreason.com> <4714B51D.7060507@gmail.com> Message-ID: <02c201c8100a$fcb951a0$5b238351@cr3lt> >> I have another concrete proposal to avoid things breaking so often. Let us >> steal from something that works: shared library versioning on unixy systems. indeed!-) there are established workarounds that are needed to make that system work as it does, so it is a good idea to check whether cabal has the means to cover those situations. >> The above declaratively expresses that libcurl-3.3.0 provides the version 3 API >> and the version 2 API. >> >> This is the capability that should be added to Haskell library packages. >> >> Right now a library can only declare a single version number. So if I update >> hsFoo from 2.1.1 to 3.0.0 then I cannot express whether or not the version 3 API >> is a superset of (backward compatible with) the version 2 API. > > Certainly, this is something we want to support. However, there's an > important difference between shared-library linking and Haskell: in > Haskell, a superset of an API is not backwards-compatible, because it has > the potential to cause new name clashes. yes, one would need to define what it means for one api to be compatible with another. even so, i think that permitting a single package to act as a provider for multiple versions of an api is a necessary feature, even more so if loose dependency specs like 'base', or 'base >= 1.0' are going to be discouraged. > It could be done using the tricks that Claus just posted and I followed up > on. You'd need a separate package for hsFoo-2 that specifies exactly which > bits of hsFoo-3 are re-exported. Given some Cabal support and a little > extension in GHC, this could be made relatively painless for the library > maintainer. are those tricks necessary in this specific case? couldn't we have a list/range of versions in the version: field, and let cabal handle the details? aside: what happens if we try to combine two modules M and N that use the same api A, but provided by two different packages P1 and P2? say, M was built when P1 was still around, but when N was built, P2 had replaced P1, still supporting A, but not necessarily with the same internal representation as used in P1. claus From simonmarhaskell at gmail.com Tue Oct 16 11:52:17 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Oct 16 11:50:32 2007 Subject: [Haskell-cafe] Re: Proposal: register a package as providingseveral API versions In-Reply-To: <02c201c8100a$fcb951a0$5b238351@cr3lt> References: <20071014140922.GA25871@matrix.chaos.earth.li> <20071015203802.GA3229@web.de> <47147355.6020109@gmail.com> <200710162354.37812.dm.maillists@gmail.com><4714A9D1.8070501@microsoft.com><4714AF6E.70903@list.mightyreason.com> <4714B51D.7060507@gmail.com> <02c201c8100a$fcb951a0$5b238351@cr3lt> Message-ID: <4714DE31.6050503@gmail.com> Claus Reinke wrote: >> It could be done using the tricks that Claus just posted and I >> followed up on. You'd need a separate package for hsFoo-2 that >> specifies exactly which bits of hsFoo-3 are re-exported. Given some >> Cabal support and a little extension in GHC, this could be made >> relatively painless for the library maintainer. > > are those tricks necessary in this specific case? couldn't we > have a list/range of versions in the version: field, and let cabal > handle the details? I don't understand what you're proposing here. Surely just writing version: 1.0, 2.0 isn't enough - you need to say what the 1.0 and 2.0 APIs actually *are*, and then wouldn't that require more syntax? I don't yet see a good reason to do this in a single .cabal file instead of two separate packages. The two-package way seems to require fewer extensions to Cabal. > aside: what happens if we try to combine two modules M and N > that use the same api A, but provided by two different packages > P1 and P2? say, M was built when P1 was still around, but when > N was built, P2 had replaced P1, still supporting A, but not necessarily > with the same internal representation as used in P1. Not sure what you mean by "try to combine". A concrete example? Cheers, Simon From claus.reinke at talk21.com Tue Oct 16 12:32:06 2007 From: claus.reinke at talk21.com (Claus Reinke) Date: Tue Oct 16 12:30:20 2007 Subject: [Haskell-cafe] Re: Proposal: register a package asprovidingseveral API versions References: <20071014140922.GA25871@matrix.chaos.earth.li> <20071015203802.GA3229@web.de> <47147355.6020109@gmail.com> <200710162354.37812.dm.maillists@gmail.com><4714A9D1.8070501@microsoft.com><4714AF6E.70903@list.mightyreason.com><4714B51D.7060507@gmail.com> <02c201c8100a$fcb951a0$5b238351@cr3lt> <4714DE31.6050503@gmail.com> Message-ID: <035a01c81012$184e0080$5b238351@cr3lt> >> are those tricks necessary in this specific case? couldn't we >> have a list/range of versions in the version: field, and let cabal >> handle the details? > > I don't understand what you're proposing here. Surely just writing > > version: 1.0, 2.0 > > isn't enough - you need to say what the 1.0 and 2.0 APIs actually *are*, > and then wouldn't that require more syntax? I don't yet see a good reason > to do this in a single .cabal file instead of two separate packages. The > two-package way seems to require fewer extensions to Cabal. yes, and no. cabal is currently not symmetric in this: providers specify apis (at the level of exposed modules), clients only specify api numbers as dependencies. the idea was for the cabal file to specify a single provided api, but to register that as sufficient for a list of dependency numbers. so the package would implement the latest api, but could be used by clients expecting either the old or the new api. >> aside: what happens if we try to combine two modules M and N >> that use the same api A, but provided by two different packages >> P1 and P2? say, M was built when P1 was still around, but when >> N was built, P2 had replaced P1, still supporting A, but not necessarily >> with the same internal representation as used in P1. > > Not sure what you mean by "try to combine". A concrete example? lets see - how about this: -- package P-1, Name: P, Version: 0.1 module A(L,f,g) where newtype L a = L [a] f a (L as) = elem a as g as = L as -- package P-2, Name: P, Version: 0.2 module A(L,f,g) where newtype L a = L (a->Bool) f a (L as) = as a g as = L (`elem` as) if i got this right, both P-1 and P-2 support the same api A, right down to types. but while P-1's A and P-2's A are each internally consistent, they can't be mixed. now, consider module M where import A m = g [1,2,3] module N where import A n :: Integer -> A.L Integer -> Bool n = f so, if i install P-1, then build M, then install P-2, then build N, wouldn't N pick up the "newer" P-2, while M would use the "older" P-1? and if so, what happens if we then add module Main where import M import N main = print (n 0 m) i don't seem to be able to predict the result, without actually trying it out. can you?-) i suspect it won't be pretty, though. claus From ross at soi.city.ac.uk Tue Oct 16 14:36:49 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Oct 16 14:35:18 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <4714A9D1.8070501@microsoft.com> References: <20071014140922.GA25871@matrix.chaos.earth.li> <20071015203802.GA3229@web.de> <47147355.6020109@gmail.com> <200710162354.37812.dm.maillists@gmail.com> <4714A9D1.8070501@microsoft.com> Message-ID: <20071016183649.GA5847@soi.city.ac.uk> On Tue, Oct 16, 2007 at 01:08:49PM +0100, Simon Marlow wrote: > So rather than keep replying to individual points, I'd like to make some > concrete proposals so we can make progress. > > 1. Document the version numbering policy. > > We should have done this earlier, but we didn't. The proposed policy, for > the sake of completeness is: x.y where: > > x changes ==> API changed > x constant but y changes ==> API extended only > x and y constant ==> API is identical > > further sub-versions may be added after the x.y, their meaning is > package-defined. This should be required for at least the GHC boot packages (and encouraged for others). I would make "API extended only" a bit more precise: any module that uses explicit import lists will not be affected by the changes. So one can add classes, types and functions, but not instances (except where either the class or the type is new). You probably can't add data constructors or fields, and have to be careful with new methods. I'd also prefer that major versions used two numbers, because that's common now, it supports the experimental versions 0.x apfelmus mentioned, and it makes it easier to leave room for development versions (possibly using an odd-even scheme). If you make your development repository available, and it contains API changes, you'll want its version number to have a larger major number. From isaacdupree at charter.net Tue Oct 16 15:02:10 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Tue Oct 16 15:01:27 2007 Subject: Proposal: Add &&& and *** to Data.Tuple In-Reply-To: <20071015235003.GB2716@soi.city.ac.uk> References: <8dde104f0709170623h672ee600t569f1637664d5a6c@mail.gmail.com> <20070917175122.GA8398@matrix.chaos.earth.li> <46EEC677.2020000@cs.nott.ac.uk> <8dde104f0709211015y3269ca9bpea3216f5367ac34@mail.gmail.com> <8dde104f0709270644u1b52e1cm49a10083f83eec82@mail.gmail.com> <8dde104f0710151216k7836c3f8ra75fb165fe050a1@mail.gmail.com> <20071015235003.GB2716@soi.city.ac.uk> Message-ID: <47150AB2.3090409@charter.net> Ross Paterson wrote: > On Mon, Oct 15, 2007 at 09:16:38PM +0200, Josef Svenningsson wrote: >> Despite the fact that we don't have a consensus I interpret the >> majority as a go for this patch. > > In general, I think it's important to try for consensus with the core > libraries. The discussion it requires is much more likely to explore > the issues. Voting should be the last resort. I agree. I'm not sure I want to vote for this. Isaac From isaacdupree at charter.net Tue Oct 16 15:25:35 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Tue Oct 16 15:25:10 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <20071016183649.GA5847@soi.city.ac.uk> References: <20071014140922.GA25871@matrix.chaos.earth.li> <20071015203802.GA3229@web.de> <47147355.6020109@gmail.com> <200710162354.37812.dm.maillists@gmail.com> <4714A9D1.8070501@microsoft.com> <20071016183649.GA5847@soi.city.ac.uk> Message-ID: <4715102F.7030704@charter.net> Ross Paterson wrote: > I would make "API extended only" a bit more precise: any module that uses > explicit import lists will not be affected by the changes. So one can > add classes, types and functions, but not instances (except where either > the class or the type is new). okay > You probably can't add data constructors > or fields, and have to be careful with new methods. If they're exported and new members of existing classes/datatypes, then you can't add them, because they might be imported with "class/typename(..)". (right?) What about semantic changes to the API? Including, adding a default to a class method changes the default from 'undefined', which someone might have relied on as the default (although it seems unlikely). Isaac From dons at galois.com Tue Oct 16 15:44:33 2007 From: dons at galois.com (Don Stewart) Date: Tue Oct 16 15:42:55 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <4714A9D1.8070501@microsoft.com> References: <20071014140922.GA25871@matrix.chaos.earth.li> <20071015203802.GA3229@web.de> <47147355.6020109@gmail.com> <200710162354.37812.dm.maillists@gmail.com> <4714A9D1.8070501@microsoft.com> Message-ID: <20071016194433.GF15214@scytale.galois.com> simonmarhaskell: > Several good points have been raised in this thread, and while I might not > agree with everything, I think we can all agree on the goal: things > shouldn't break so often. > > So rather than keep replying to individual points, I'd like to make some > concrete proposals so we can make progress. > > 1. Document the version numbering policy. > > We should have done this earlier, but we didn't. The proposed policy, for > the sake of completeness is: x.y where: > > x changes ==> API changed > x constant but y changes ==> API extended only > x and y constant ==> API is identical > > further sub-versions may be added after the x.y, their meaning is > package-defined. Ordering on versions is lexicographic, given multiple > versions that satisfy a dependency Cabal will pick the latest. > > 2. Precise dependencies. > > As suggested by various people in this thread: we change the convention so > that dependencies must specify a single x.y API version, or a range of > versions with an upper bound. Cabal or Hackage can refuse to accept > packages that don't follow this convention (perhaps Hackage is a better > place to enforce it, and Cabal should just warn, I'm not sure). I agree. >= 1.0 isn't viable in the long term. Rather, a specific list, or bounded range of tested versions seems likely to be more robust. -- Don From ramsdell at mitre.org Tue Oct 16 15:48:21 2007 From: ramsdell at mitre.org (John D. Ramsdell) Date: Tue Oct 16 15:46:34 2007 Subject: Linking executables and the library of a Cabal package description In-Reply-To: <4714BA65.6080202@gmail.com> References: <4714BA65.6080202@gmail.com> Message-ID: Simon Marlow writes: > Really we should fix or remove that feature, my vote would be to > remove it. Simon, Thank you for your quick reply. Whatever is done about this feature, I urge a change be made in the documentation as soon as possible. Section two of the Cabal documentation includes Example 3, an example even more complex than the one I sent to the list. It's prominent position in the document suggested to me that this feature is well tested, and that any problem I was having using it was, as they say, user error. I would not have spent so much time rereading the document had I know what I do now. For my application, it is natural to package it as a library and several binaries built on top of the library, so I would like to see this feature supported, but the description of it removed from the documentation until it works. John From ndmitchell at gmail.com Tue Oct 16 15:48:52 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Oct 16 15:47:14 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <20071016194433.GF15214@scytale.galois.com> References: <20071014140922.GA25871@matrix.chaos.earth.li> <20071015203802.GA3229@web.de> <47147355.6020109@gmail.com> <200710162354.37812.dm.maillists@gmail.com> <4714A9D1.8070501@microsoft.com> <20071016194433.GF15214@scytale.galois.com> Message-ID: <404396ef0710161248r1fe1573t4e99872b3b21bae9@mail.gmail.com> Hi > I agree. >= 1.0 isn't viable in the long term. Rather, a specific list, > or bounded range of tested versions seems likely to be more robust. In general, if it compiles and type checks, it will work. It is rare that an interface stays sufficiently similar that the thing compiles, but then crashes at runtime. Given that, shouldn't the tested versions be something a machine figures out - rather than something each library author has to tend to with every new release of every other library in hackage? Thanks Neil From dons at galois.com Tue Oct 16 16:07:23 2007 From: dons at galois.com (Don Stewart) Date: Tue Oct 16 16:05:35 2007 Subject: Support for high baud rates in the serial binding Message-ID: <20071016200723.GL15214@scytale.galois.com> The attached patch adds support for higher baud rates to System.Posix.Terminal. We need this in practice, so it would be nice to get this into stable. Its a trivial change. -- Don -------------- next part -------------- New patches: [Support for 57600 and 115200 baudrates pweaver@galois.com**20071016191631] { hunk ./System/Posix/Terminal.hsc 337 + | B57600 + | B115200 hunk ./System/Posix/Terminal.hsc 632 +baud2Word B57600 = (#const B57600) +baud2Word B115200 = (#const B115200) hunk ./System/Posix/Terminal.hsc 656 + else if x == (#const B57600) then B57600 + else if x == (#const B115200) then B115200 } Context: [Add basic pseudoterminal support. Bryan O'Sullivan **20070925113330] [check for shm_open/shm_unlink (for archs like OpenBSD without them) Don Stewart **20070916025218] [Add more entries to boring file Ian Lynagh **20070913210721] [Add a boring file Ian Lynagh **20070913204658] [in pPrPr_disableITimers (who made up that name?) call the RTS to disable the timer Simon Marlow **20070912145647 Since we switched to using timer_create() in the RTS, this function has been failing to disables the timer interrupts. This turns out to be the cause of the random framework failures in the test suite. Invoking the RTS to turn off the timer signal is the right thing. ] [TAG ghc-6.8 branched 2007-09-03 Ian Lynagh **20070903155840] Patch bundle hash: bc92611f100215941b46157287c6dcb85b81f2db From isaacdupree at charter.net Tue Oct 16 16:06:27 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Tue Oct 16 16:05:52 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <404396ef0710161248r1fe1573t4e99872b3b21bae9@mail.gmail.com> References: <20071014140922.GA25871@matrix.chaos.earth.li> <20071015203802.GA3229@web.de> <47147355.6020109@gmail.com> <200710162354.37812.dm.maillists@gmail.com> <4714A9D1.8070501@microsoft.com> <20071016194433.GF15214@scytale.galois.com> <404396ef0710161248r1fe1573t4e99872b3b21bae9@mail.gmail.com> Message-ID: <471519C3.1090503@charter.net> Neil Mitchell wrote: > Hi > >> I agree. >= 1.0 isn't viable in the long term. Rather, a specific list, >> or bounded range of tested versions seems likely to be more robust. > > In general, if it compiles and type checks, it will work. It is rare > that an interface stays sufficiently similar that the thing compiles, > but then crashes at runtime. True.. GoboLinux's package system records the exact set of versions something compiles with (just for reference), and uses min version bounds (and max bounds where needed) for dependencies. It's always possible for Haskell library implementation-bug-fixes to change relied-on behavior, as discussed in the original ECT description. I agree that compiling and type-checking is a pretty good sign of working. Passing tests (e.g. QuickCheck) could be tested too, where available. If optimizations and unsafePerformIO interact differently, different compiler versions could also affect whether something works correctly, but still compiles... But, the issue here is much more limited: we assume that there were some set of versions of these libraries that DID work, and, that every version of each library, on its own (or with only the libraries it depends on), works. So it might be valuable to record subjectively-working exact version sets, somewhere. Isaac From conal at conal.net Tue Oct 16 17:10:20 2007 From: conal at conal.net (Conal Elliott) Date: Tue Oct 16 17:08:31 2007 Subject: Proposal: Add &&& and *** to Data.Tuple In-Reply-To: <20071016054454.GA4246@zombie.inf.tu-dresden.de> References: <8dde104f0709170623h672ee600t569f1637664d5a6c@mail.gmail.com> <20070917175122.GA8398@matrix.chaos.earth.li> <20070920202337.GA3051@localhost.localdomain> <20070920224628.6gmz6wuzsok0s8ow@webmail.spamcop.net> <20071016054454.GA4246@zombie.inf.tu-dresden.de> Message-ID: It wouldn't have to be a change. We could add these new synonyms. I'm personally happy with first & second for use with functions & other Arrow types. My main suggestion is that if we want new names for memorability, then let's add them for the general meanings rather than the specialized ones. On 10/15/07, Bertram Felgenhauer wrote: > > > Changing the names of 'first' and 'second' in Control.Arrow is a bad > idea, I think. It'll break a lot of packages. [...] -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20071016/43518191/attachment.htm From igloo at earth.li Tue Oct 16 18:30:03 2007 From: igloo at earth.li (Ian Lynagh) Date: Tue Oct 16 18:28:14 2007 Subject: CPP confusion In-Reply-To: <1192527986.9844.175.camel@localhost> References: <1192527986.9844.175.camel@localhost> Message-ID: <20071016223002.GA16485@matrix.chaos.earth.li> [can we keep this on just one mailing list please? cabal-devel@ makes most sense to me] On Tue, Oct 16, 2007 at 10:46:26AM +0100, Duncan Coutts wrote: > > The latest thing I've stumbled over is HsUnix.h in ghc-6.8. This header > file is for defines to use when pre-processing Haskell code. It used to > live in the global $GHCLIBDIR/include but now lives in the include dir > for the unix package. This is probably the right thing to do, however... > > How do packages that want to use this include actually use it? If they > #include it directly in a .hs file then it'll work since ghc -package > unix adds the unix package's include dir to the search path. But what if > someone needs to use it in a .hsc file? > > Well, then it does not work. It does not work because Cabal does not > pass these include directories to hsc2hs Is there a reason we can't just fix that, and pass hsc2hs "-Ifoo" for each includes directory "foo" in a package we depend on? > In fact this totally relies on a package > database to remember what search directories to use when pre-processing > dependent packages. In other words it only has a chance of working with > ghc at the moment, or nhc in future if/when it implements a package > database. Yes, I think that at some point all impls will need some sort of package database (or perhaps Cabal could manage a package database itself for some or all impls?). Thanks Ian From duncan.coutts at worc.ox.ac.uk Tue Oct 16 18:52:08 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Oct 16 18:47:51 2007 Subject: Linking executables and the library of a Cabal package description In-Reply-To: References: Message-ID: <1192575128.9844.212.camel@localhost> On Mon, 2007-10-15 at 14:32 -0400, John D. Ramsdell wrote: > I'm sure this will be an easy question for those on this list. What > do you need to add to a Cabal package description so as to allow an > executable in the description to be built from the library it also > describes? I searched the Cabal documentation many times, but came up > empty handed. > Name: a > Version: 1.0 > Build-Depends: base > Exposed-Modules: A > > Executable: b > Main-Is: Main.hs > Other-Modules: A > Hs-Source-Dirs: exec I think the problem here is search paths. Try adding . to the Hs-Source-Dirs, or alternatively moving everything into the root dir rather than under exec. This smells like a bug in cabal to me. Duncan From duncan.coutts at worc.ox.ac.uk Tue Oct 16 18:55:11 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Oct 16 18:51:04 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <125EACD0CAE4D24ABDB4D148C4593DA9049E9017@GBLONXMB02.corp.amvescap.net> References: <20071014140922.GA25871@matrix.chaos.earth.li> <20071015203802.GA3229@web.de><47147355.6020109@gmail.com> <200710162354.37812.dm.maillists@gmail.com> <4714A9D1.8070501@microsoft.com> <125EACD0CAE4D24ABDB4D148C4593DA9049E9015@GBLONXMB02.corp.amvescap.net> <4714B255.7030709@gmail.com> <125EACD0CAE4D24ABDB4D148C4593DA9049E9017@GBLONXMB02.corp.amvescap.net> Message-ID: <1192575311.9844.214.camel@localhost> On Tue, 2007-10-16 at 14:01 +0100, Bayley, Alistair wrote: > > From: Simon Marlow [mailto:simonmarhaskell@gmail.com] > > > > The lexicographical ordering would make 10.0 > 9.3. In > > general, A.B > C.D > > iff A > C or A == C && B > D. When we say the "latest" > > version we mean > > "greatest", implying that version numbers increase with time. > > Does that help? > > > Sort