From jeanphilippe.bernardy at gmail.com Sun Apr 1 02:16:10 2007 From: jeanphilippe.bernardy at gmail.com (Jean-Philippe Bernardy) Date: Sun Apr 1 02:15:10 2007 Subject: Can we do better than duplicate APIs? [was: Data.CompactString 0.3] In-Reply-To: <953e0d250703310951x2638fc37ob06006efc81090b5@mail.gmail.com> References: <45F45917.1090800@gmail.com> <953e0d250703232321u5c7a997du6333a3aa629775f8@mail.gmail.com> <953e0d250703310518n5de784f5hf98ac9dc0391a352@mail.gmail.com> <460E5CE9.8040504@iee.org> <953e0d250703310951x2638fc37ob06006efc81090b5@mail.gmail.com> Message-ID: <953e0d250703312316y3b191619v7a601d27d99c7c90@mail.gmail.com> > I think I don't master cabal distribution mechanism well enough yet. > Till I get better, please use the darcs repo: > http://darcs.haskell.org/packages/collections-ghc6.6/ This has now been fixed (thanks to Ross). To make things clear: http://darcs.haskell.org/packages/collections-ghc6.6/ repository working against the latest stable release of ghc/base http://darcs.haskell.org/packages/collections/ development repository (you basically need ghc 6.7 for this one) http://hackage.haskell.org/cgi-bin/hackage-scripts/package/collections-0.3 latest snapshot of the former (ie. stable version). Cheers, JP. From jyasskin at gmail.com Sun Apr 1 02:37:16 2007 From: jyasskin at gmail.com (Jeffrey Yasskin) Date: Sun Apr 1 02:36:16 2007 Subject: Automated tests for the libraries? In-Reply-To: <404396ef0703181015x1995db7dj52b9c823c23d45cb@mail.gmail.com> References: <5d44f72f0703152239k338fe09dl84a1edd578e20be7@mail.gmail.com> <45FAF17D.4060203@cogito.org.uk> <404396ef0703161238v61524268mc6fb8d0f213db01b@mail.gmail.com> <5d44f72f0703171854q456e47b1x88138af2ffb55069@mail.gmail.com> <404396ef0703181015x1995db7dj52b9c823c23d45cb@mail.gmail.com> Message-ID: <5d44f72f0703312337o48d77fa1h68c4bc31796279f@mail.gmail.com> I've been working on getting test running Cabalized and finally have a patch to send. Extracting tests from the source code is, I think, an independent problem. http://jeffrey.yasskin.info/darcs/filepath/Setup.hs has the main instructions for running the test (with the same test extraction as the original GenTests.hs), and http://jeffrey.yasskin.info/darcs/filepath/SingleFileOps.hs has some operations that I'd like to add to Cabal itself. With some more experience writing tests like this, we'll definitely want to extract most of this Setup.hs into a shared module. The basic idea is that I want to base the tests as much as possible on production code, but I may need to #define TESTING or some other symbol in a particular file to get that file's tests to run. So each file "foo.hs" may be compiled with the 'tag' "foo" (practically, into the dist/build/foo directory) with -DTESTING, and then its test is run in the context of ["foo", ""] (look for "foo" object files, and then the results of `Setup.hs build`). Putting testing builds in a different place also makes sure that they don't get installed or released accidentally. What would be the best way to proceed? Is this system overkill and I should start over with something simpler (either a single -DTESTING build tree or just `runhaskell -DTESTING`)? Should I clean up SingleFileOps and submit it to Cabal? Should I take what I have and apply it to base? This patch is based on http://www.cs.york.ac.uk/fp/darcs/filepath/, so it's a little out of date. Neil, if you're interested in accepting this for the version of FilePath on darcs.haskell.org, I'll get you a patch that works there in the next week. On 3/18/07, Neil Mitchell wrote: > Hi > > > > This gives a list of properties, which are automatically extracted > > > from the documentation, and checked using QuickCheck. All the tool is > > > in the repo. If anyone wanted to generalise the code in there, it > > > would be handy! > > > > Neil, your extractor looks cool, but I wonder how it'll work with > > modules like Data.Set whose (commented out) tests define some > > Arbitrary instances and some helper functions in addition to the > > actual properties. My first inclination would have been to define the > > properties in code, perhaps "#ifdef TESTING"ed out, and try to teach > > Haddock to pull them into the documentation. But yours is definitely > > simpler and probably worth pursuing until it obviously stops working. > > FilePath also has that issue, I do: > > module FilePath( > #ifdef TESTING > properties and instances for testing > #endif > > ) where > > Then I just define TESTING when running the test. This has the > advantage that the tests at least always compile, even as I make other > changes. In reality, FilePath only requires a couple of things (the > drive properties) to be exported for testing but not for real use. > > I don't see much complication in extending my approach. In fact, I > suspect that my FilePath test extractor is overly complex, since it > allows: > > Windows: property > Posix: property > property > > For Windows properties it added System.FilePath.Windows.functions, > ditto for Posix, and for normal ones it generates the test twice, once > with Windows and once with Posix. It also detects if a property has > any free variables, and if not changes it to a single assertion, > rather than a quickcheck property. > > I think it is very handy, and integrating it with Cabal and removing > the special cases that FilePath requires is probably well worth the > effort! I would certainly like such a tool... > > Thanks > > Neil > -- Namast?, Jeffrey Yasskin -------------- next part -------------- A non-text attachment was scrubbed... Name: cabalize-gentests.dpatch Type: text/x-darcs-patch Size: 23246 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20070331/895e2219/cabalize-gentests-0001.bin From sven.panne at aedion.de Sun Apr 1 06:50:10 2007 From: sven.panne at aedion.de (Sven Panne) Date: Sun Apr 1 06:49:11 2007 Subject: Proposal [Trac #1212]: add IPv6 support to network library In-Reply-To: <460EACAD.4070207@serpentine.com> References: <45F268D0.8090504@serpentine.com> <460EACAD.4070207@serpentine.com> Message-ID: <200704011250.11061.sven.panne@aedion.de> I've downloaded your darcs repo, and it built fine (openSUSE 10.2 x86_64). Two remarks: * You use an internal class HostAddr and make two type synonyms an instance of it. This has 2 drawbacks: It is not H98 and Haddock complains about a missing link destination. I think one could handle things easily without a class, because all possible instances are known at compile time. * The types and values of AddrInfoFlags/NameInfoFlags are not very Haskell-like. Using data AddrInfoFlag = Passive | CanonName | NumericHost | ... and [AddrInfoFlag] instead of AddrInfoFlags is much nicer. The only cost is that a tiny marshaling function has to be written. Same for NameInfoFlags. Interfaces writte this way are more type safe and one can easily see which alternatives are possible for a given set of flags in a single place. Alas, the X11 package is not nice regarding the last item, either... :-( Cheers, S. From isaacdupree at charter.net Sun Apr 1 08:00:18 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Sun Apr 1 07:58:11 2007 Subject: [Haskell-cafe] Why the Prelude must die In-Reply-To: References: <20070324024812.GA3712@localhost.localdomain> Message-ID: <460F9ED2.9@charter.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David House wrote: > On 24/03/07, Stefan O'Rear wrote: >> This is a ranty request for comments, and the more replies the better. > > Without responding to any particular comment, my opinion is that we > should have a minimal Prelude with functions like (.) that couldn't be > reasonably redefined in any function. I can recall two variations on (.)... Strict composition, perhaps (.!), that is somehow strict in the functions that are its arguments. Unicode composition, i.e. use the Unicode character for function composition (?) instead of the overloaded (with module system syntax) "." symbol Not that these are worthy alternatives for our Prelude, just reasons that I don't entirely like the idea of any implicitly included prelude. Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGD57RHgcxvIWYTTURAjwuAKCeX5KJ+511lctcC5EXJ+7kYtsNqACfd/GS PSteOUuiJqYAaaJBwiblaso= =U/j/ -----END PGP SIGNATURE----- From igloo at earth.li Sun Apr 1 11:56:13 2007 From: igloo at earth.li (Ian Lynagh) Date: Sun Apr 1 11:55:13 2007 Subject: Proposal [Trac #1212]: add IPv6 support to network library In-Reply-To: <460EACAD.4070207@serpentine.com> References: <45F268D0.8090504@serpentine.com> <460EACAD.4070207@serpentine.com> Message-ID: <20070401155613.GA6232@matrix.chaos.earth.li> On Sat, Mar 31, 2007 at 01:47:09PM +0000, Bryan O'Sullivan wrote: > > http://hackage.haskell.org/trac/ghc/attachment/ticket/1212/ipv6.2.patch This contains: hunk ./network.cabal 2 -version: 2.0 +version: 2.0.1 I don't think patches should include changes to the version number, as they will then depend/conflict with every other patch. Instead, changes should accumulate in the darcs repo, and the version number incremented by a patch (that does nothing else) just before a release is made. Thanks Ian From igloo at earth.li Sun Apr 1 12:02:39 2007 From: igloo at earth.li (Ian Lynagh) Date: Sun Apr 1 12:01:38 2007 Subject: Dubious behavior in TH pretty printer In-Reply-To: <20070331080006.GA4363@localhost.localdomain> References: <20070331080006.GA4363@localhost.localdomain> Message-ID: <20070401160239.GA6182@matrix.chaos.earth.li> On Sat, Mar 31, 2007 at 01:00:06AM -0700, Stefan O'Rear wrote: > > stefan@stefans:~/daanpp$ ghci -fth > Prelude> :m + Language.Haskell.TH > Prelude Language.Haskell.TH> runQ [| (+) 2 2 |] >>= print . ppr > GHC.Num.+ 2 2 > > I am trying to use the Template Haskell AST system for internal > representation of terms in a derivation library that can output > Haskell or feed directly into a splice. This "bug", unfixed, would > force me to fork the TH pretty printer. What would people think of a > patch changing the behavor to "Always produce parsable output"? (Yes, > I'm offering to implement it.) Sounds great - the pretty-printer is intended to print in valid Haskell syntax. Thanks Ian From stefanor at cox.net Sun Apr 1 15:14:41 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Sun Apr 1 15:13:40 2007 Subject: darcs patch: Create showName, which takes an addition... (and 4 more) Message-ID: Adds support for handling prefix and infix names to the (Template Haskell) pretty printer; parenthesis and backticks are added as needed to match the intrinsic fixity of symbols with fixity contexts. Also contains a one-line fix causing irrefutable patterns to be properly printed. NB: changes Show Name output. Sun Apr 1 09:46:35 PDT 2007 Stefan O'Rear * Create showName, which takes an additional prefix-context argument Sun Apr 1 09:48:14 PDT 2007 Stefan O'Rear * Thread prefix-context argument through pprName Sun Apr 1 09:56:55 PDT 2007 Stefan O'Rear * Use pprName False in pretty printer Sun Apr 1 09:59:45 PDT 2007 Stefan O'Rear * Typo fixes, missing {in,ex}ports Sun Apr 1 12:02:15 PDT 2007 Stefan O'Rear * Properly handle tilde-patterns -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 4818 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/libraries/attachments/20070401/f02fcb60/attachment.bin From duncan.coutts at worc.ox.ac.uk Sun Apr 1 19:05:00 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Apr 1 19:04:07 2007 Subject: Proposal [Trac #1212]: add IPv6 support to network library In-Reply-To: <20070401155613.GA6232@matrix.chaos.earth.li> References: <45F268D0.8090504@serpentine.com> <460EACAD.4070207@serpentine.com> <20070401155613.GA6232@matrix.chaos.earth.li> Message-ID: <1175468701.4994.66.camel@localhost> On Sun, 2007-04-01 at 16:56 +0100, Ian Lynagh wrote: > On Sat, Mar 31, 2007 at 01:47:09PM +0000, Bryan O'Sullivan wrote: > I don't think patches should include changes to the version number, as > they will then depend/conflict with every other patch. Instead, changes > should accumulate in the darcs repo, and the version number incremented > by a patch (that does nothing else) just before a release is made. Indeed. It'd be nice to make cabal make it easier to work in this way, for example by making dated snapshot versions easier to make. cabal-setup sdist [release|snapshot] ? Duncan From ross at soi.city.ac.uk Sun Apr 1 19:08:54 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sun Apr 1 19:07:52 2007 Subject: Proposal [Trac #1212]: add IPv6 support to network library In-Reply-To: <1175468701.4994.66.camel@localhost> References: <45F268D0.8090504@serpentine.com> <460EACAD.4070207@serpentine.com> <20070401155613.GA6232@matrix.chaos.earth.li> <1175468701.4994.66.camel@localhost> Message-ID: <20070401230854.GA30223@soi.city.ac.uk> On Mon, Apr 02, 2007 at 09:05:00AM +1000, Duncan Coutts wrote: > It'd be nice to make cabal make it easier to work in this way, for > example by making dated snapshot versions easier to make. > > cabal-setup sdist [release|snapshot] ? Like setup sdist --snapshot ? From duncan.coutts at worc.ox.ac.uk Sun Apr 1 19:14:22 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Apr 1 19:13:28 2007 Subject: Proposal [Trac #1212]: add IPv6 support to network library In-Reply-To: <20070401230854.GA30223@soi.city.ac.uk> References: <45F268D0.8090504@serpentine.com> <460EACAD.4070207@serpentine.com> <20070401155613.GA6232@matrix.chaos.earth.li> <1175468701.4994.66.camel@localhost> <20070401230854.GA30223@soi.city.ac.uk> Message-ID: <1175469263.4994.71.camel@localhost> On Mon, 2007-04-02 at 00:08 +0100, Ross Paterson wrote: > On Mon, Apr 02, 2007 at 09:05:00AM +1000, Duncan Coutts wrote: > > It'd be nice to make cabal make it easier to work in this way, for > > example by making dated snapshot versions easier to make. > > > > cabal-setup sdist [release|snapshot] ? > > Like setup sdist --snapshot ? You'd think that being Cabal release manager I'd know about this kind of thing wouldn't you? :-) Ah well. Duncan From shelarcy at gmail.com Sun Apr 1 23:51:59 2007 From: shelarcy at gmail.com (shelarcy) Date: Sun Apr 1 23:51:24 2007 Subject: Adding System.FilePath In-Reply-To: <1443978744.20070316212806@gmail.com> References: <404396ef0703150925o6323653eh7d513f8b231cce5b@mail.gmail.com> <200703161424.47137.sven.panne@aedion.de> <631847515.20070316162601@gmail.com> <200703161442.00623.sven.panne@aedion.de> <1443978744.20070316212806@gmail.com> Message-ID: On Sat, 17 Mar 2007 03:28:06 +0900, Bulat Ziganshin wrote: > Friday, March 16, 2007, 7:19:34 PM, you wrote: >>> * Use a "wide" API when available internally > >> I trid to change by just changing from ascii API to wide API tonight. >> But ... there is one problem. _wopendir defined in mingwex library, and >> mingwex requires dll. I'm sorry about I am wrong about this. If I use ghc to make binary, binary file can be linked with _wopendir. This problem is caused only on intepreter (GHCi and runghc). And this provlem isn't just _wopendir's, my current modified version reports error for _wreaddir's. > i've used _wfindfirsti64/_wfindnexti64 functions. of course, their > semantics isn't the same as semantics of _wopendir. look at Win32Files > module from http://www.haskell.org/bz/FreeArc-sources.tar.gz - it > implements all the function i use to work with files in my program So we need not use _wfindfirsti64/_wfindnexti64 functions. If someone knows that how to fix above problem, please tell me. I attached darcs version of current patch. (I removed modified version of package.conf.in from this patch. Because this doesn't help to fix above problem.) This patch doesn't support all unix platform. Vecause I don't modify configure.ac to detect that "wide" API available, and add alternative part for unavailable platform yet. -- shelarcy http://page.freett.com/shelarcy/ -------------- next part -------------- A non-text attachment was scrubbed... Name: exp_wide_base.dpatch Type: application/octet-stream Size: 63452 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20070402/1ce6ab5a/exp_wide_base-0001.obj From simonpj at microsoft.com Mon Apr 2 04:02:41 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Apr 2 04:01:38 2007 Subject: Dubious behavior in TH pretty printer In-Reply-To: <20070331080006.GA4363@localhost.localdomain> References: <20070331080006.GA4363@localhost.localdomain> Message-ID: | I am trying to use the Template Haskell AST system for internal | representation of terms in a derivation library that can output | Haskell or feed directly into a splice. This "bug", unfixed, would | force me to fork the TH pretty printer. What would people think of a | patch changing the behavor to "Always produce parsable output"? (Yes, | I'm offering to implement it.) Good plan. You may find the function isSymOcc :: OccName -> Bool in OccName.lhs useful Send us a patch, by all means. Thanks for offering to help. Simon From stefanor at cox.net Mon Apr 2 04:12:35 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Mon Apr 2 04:11:38 2007 Subject: Dubious behavior in TH pretty printer In-Reply-To: References: <20070331080006.GA4363@localhost.localdomain> Message-ID: <20070402081235.GA26379@localhost.localdomain> On Mon, Apr 02, 2007 at 09:02:41AM +0100, Simon Peyton-Jones wrote: > | I am trying to use the Template Haskell AST system for internal > | representation of terms in a derivation library that can output > | Haskell or feed directly into a splice. This "bug", unfixed, would > | force me to fork the TH pretty printer. What would people think of a > | patch changing the behavor to "Always produce parsable output"? (Yes, > | I'm offering to implement it.) > > Good plan. You may find the function isSymOcc :: OccName -> Bool > in OccName.lhs useful > > Send us a patch, by all means. I already sent a patch to the libraries list: http://haskell.org/pipermail/libraries/2007-April/007317.html This also fixes the printign of tilde-patterns. (That said, a new issue has been found - \ ((:) x xs) -> x pprs as \ (:) x xs -> x, incorrectly parend.) I didn't know about isSymOcc (indeed I never saw an OccName.lhs in template-haskell); I implemented it myself with dropWhile and isAlpha. Stefan From simonpj at microsoft.com Mon Apr 2 04:52:09 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Apr 2 04:51:06 2007 Subject: Dubious behavior in TH pretty printer In-Reply-To: <20070402081235.GA26379@localhost.localdomain> References: <20070331080006.GA4363@localhost.localdomain> <20070402081235.GA26379@localhost.localdomain> Message-ID: | I already sent a patch to the libraries list: | http://haskell.org/pipermail/libraries/2007-April/007317.html | | This also fixes the printign of tilde-patterns. Great, thanks. | I didn't know about isSymOcc (indeed I never saw an OccName.lhs in | template-haskell); I implemented it myself with dropWhile and isAlpha. Ah yes, of course. OccName is for GHC's syntax, not TH's. Still, you might want to look in compiler/basicTypes/OccName.lhs, if only to check that your impl and GHC's agree about what an operator is. Simon From simonmarhaskell at gmail.com Mon Apr 2 05:13:33 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Apr 2 05:12:31 2007 Subject: System.Process bugs on Unix In-Reply-To: <460D401B.8040501@serpentine.com> References: <460ABFEF.8030900@serpentine.com> <460B8D1F.7030603@gmail.com> <460BE34E.4040801@serpentine.com> <460CD2DD.7010301@gmail.com> <460D401B.8040501@serpentine.com> Message-ID: <4610C93D.3020805@gmail.com> Bryan O'Sullivan wrote: > Simon Marlow wrote: > >> I'm sure, yes. The non-blocking flag is part of the "open file >> description" (see [1], [2]), not the file descriptor. > > Ah, yes indeed. I had misunderstood what runProcess was trying to do. > Given that, the patch I believed would help was not, in fact, going to > do so. > > If there's a way to work around this behaviour, it's not obvious to me. > Had you any thoughts in mind? We use O_NONBLOCK to do multithreaded I/O with our lightweight threads. If you're prepared to use OS threads, then you don't need O_NONBLOCK, you can just make a non-blocking foreign call to do the I/O: e.g foreign import safe "read", this makes the call in a separate OS thread, so other Haskell threads aren't blocked. Only the threaded RTS supports OS threads, though. The idea in my patch (not my idea, I think it's been used elsewhere) is to allow both kinds of FDs: non-blocking I/O for FDs that we are sure are local to the current process, and ordinary blocking I/O with OS threads for FDs that might be shared with another process. In the non-threaded RTS you have two options: continue to use O_NONBLOCK and keep the tee bug, or use blocking I/O for the standard FDs (all other threads will be blocked while you do I/O on a std FD). Cheers, Simon From simonmarhaskell at gmail.com Mon Apr 2 06:16:55 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Apr 2 06:15:52 2007 Subject: openTempFile only defined on GHC In-Reply-To: <404396ef0703311051p29bc4088ga8f866ca7f6e3221@mail.gmail.com> References: <404396ef0703311051p29bc4088ga8f866ca7f6e3221@mail.gmail.com> Message-ID: <4610D817.3030308@gmail.com> Neil Mitchell wrote: > Hi, > >> From the System.IO export list: > > #ifdef __GLASGOW_HASKELL__ > openTempFile, > openBinaryTempFile, > #endif > > So we have a standardised module with a standardised interface which > is totally broken on all but one compiler. > > Can this please be either: > > 1) Implemented for all compilers > 2) Removed, and then potentially re-added by the proper libraries > submission process > > I hope the new libraries submission process will stop things like this > being added in future, without appropriate thought. Isn't it just a bug that these functions are not implemented by other compilers? There's no fundamental reason, right? The implementation is necessarily dependent on the internals of Handle because openFile doesn't currently provide a way to open a file and fail if it already exists (the O_EXCL flag). Cheers, Simon From bulat.ziganshin at gmail.com Mon Apr 2 06:48:00 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Apr 2 07:25:08 2007 Subject: openTempFile only defined on GHC In-Reply-To: <4610D817.3030308@gmail.com> References: <404396ef0703311051p29bc4088ga8f866ca7f6e3221@mail.gmail.com> <4610D817.3030308@gmail.com> Message-ID: <1368021516.20070402144800@gmail.com> Hello Simon, Monday, April 2, 2007, 2:16:55 PM, you wrote: >> openTempFile, >> openBinaryTempFile, > Isn't it just a bug that these functions are not implemented by other compilers? > There's no fundamental reason, right? The implementation is necessarily > dependent on the internals of Handle because openFile doesn't currently provide > a way to open a file and fail if it already exists (the O_EXCL flag). this means that these functions should be implemented in GHC.*, NHC.* and Hugs.* and only then System.IO may include interface function that will call one of them -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From sven.panne at aedion.de Mon Apr 2 08:21:47 2007 From: sven.panne at aedion.de (Sven Panne) Date: Mon Apr 2 08:20:43 2007 Subject: openTempFile only defined on GHC In-Reply-To: <1368021516.20070402144800@gmail.com> References: <404396ef0703311051p29bc4088ga8f866ca7f6e3221@mail.gmail.com> <4610D817.3030308@gmail.com> <1368021516.20070402144800@gmail.com> Message-ID: <200704021421.47831.sven.panne@aedion.de> On Monday 02 April 2007 12:48, Bulat Ziganshin wrote: > this means that these functions should be implemented in GHC.*, NHC.* > and Hugs.* and only then System.IO may include interface function that > will call one of them I don't think that this will really solve portability issues, as we would still need #ifdefs in System.IO to import the right module. The general question is: Where do we want to solve these issues: Within the code or outside of it (i.e. in the build system)? Both approaches have pros and cons, but if we want to factor things out into the build system, we would need a System.IO.Impl module, which is specific to a Haskell implementation and outside base, but which has an implementation-independent API. Mixing both approaches only complicates things with no real benefit. Cheers, S. From Malcolm.Wallace at cs.york.ac.uk Mon Apr 2 08:20:03 2007 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Mon Apr 2 08:21:53 2007 Subject: openTempFile only defined on GHC In-Reply-To: <4610D817.3030308@gmail.com> References: <404396ef0703311051p29bc4088ga8f866ca7f6e3221@mail.gmail.com> <4610D817.3030308@gmail.com> Message-ID: <20070402132003.51fd2533.Malcolm.Wallace@cs.york.ac.uk> Simon Marlow wrote: > Isn't it just a bug that these functions are not implemented by other > compilers? Yes and no. Of course we could implement them. But I for one wasn't even aware that they existed in the API. I don't know when they were added, or by whom, and I may not even be sure what they are supposed to do. For instance, you mention not opening a file if it already exists, but the Haddock does not say anything about that. Regards, Malcolm From bulat.ziganshin at gmail.com Mon Apr 2 08:41:38 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Apr 2 08:42:44 2007 Subject: openTempFile only defined on GHC In-Reply-To: <200704021421.47831.sven.panne@aedion.de> References: <404396ef0703311051p29bc4088ga8f866ca7f6e3221@mail.gmail.com> <4610D817.3030308@gmail.com> <1368021516.20070402144800@gmail.com> <200704021421.47831.sven.panne@aedion.de> Message-ID: <264124522.20070402164138@gmail.com> Hello Sven, Monday, April 2, 2007, 4:21:47 PM, you wrote: >> this means that these functions should be implemented in GHC.*, NHC.* >> and Hugs.* and only then System.IO may include interface function that >> will call one of them > I don't think that this will really solve portability issues, as we would > still need #ifdefs in System.IO to import the right module. yes, and this is standard practice. modules in base package should have compiler-independent interface, but not implementation > The general > question is: Where do we want to solve these issues: Within the code or > outside of it (i.e. in the build system)? Both approaches have pros and cons, > but if we want to factor things out into the build system, we would need a > System.IO.Impl module, which is specific to a Haskell implementation and > outside base, but which has an implementation-independent API. Mixing both > approaches only complicates things with no real benefit. afaiu, this is not relevant in light of my remark? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From sven.panne at aedion.de Mon Apr 2 08:54:13 2007 From: sven.panne at aedion.de (Sven Panne) Date: Mon Apr 2 08:53:09 2007 Subject: openTempFile only defined on GHC In-Reply-To: <264124522.20070402164138@gmail.com> References: <404396ef0703311051p29bc4088ga8f866ca7f6e3221@mail.gmail.com> <200704021421.47831.sven.panne@aedion.de> <264124522.20070402164138@gmail.com> Message-ID: <200704021454.13469.sven.panne@aedion.de> On Monday 02 April 2007 14:41, Bulat Ziganshin wrote: > Hello Sven, > > Monday, April 2, 2007, 4:21:47 PM, you wrote: > >> this means that these functions should be implemented in GHC.*, NHC.* > >> and Hugs.* and only then System.IO may include interface function that > >> will call one of them > > > > I don't think that this will really solve portability issues, as we would > > still need #ifdefs in System.IO to import the right module. > > yes, and this is standard practice. modules in base package should > have compiler-independent interface, but not implementation "standard" does not necessarily imply "good". > > The general > > question is: Where do we want to solve these issues: Within the code or > > outside of it (i.e. in the build system)? Both approaches have pros and > > cons, but if we want to factor things out into the build system, we would > > need a System.IO.Impl module, which is specific to a Haskell > > implementation and outside base, but which has an > > implementation-independent API. Mixing both approaches only complicates > > things with no real benefit. > > afaiu, this is not relevant in light of my remark? It is relevant: Before joyfully moving things around modules, we should have a common and clear picture what we should aim for. Currently, I don't see this, so I object to ad hoc changes. Cheers, S. From simonmarhaskell at gmail.com Mon Apr 2 08:58:22 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Apr 2 08:57:19 2007 Subject: openTempFile only defined on GHC In-Reply-To: <20070402132003.51fd2533.Malcolm.Wallace@cs.york.ac.uk> References: <404396ef0703311051p29bc4088ga8f866ca7f6e3221@mail.gmail.com> <4610D817.3030308@gmail.com> <20070402132003.51fd2533.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <4610FDEE.9060405@gmail.com> Malcolm Wallace wrote: > Simon Marlow wrote: > >> Isn't it just a bug that these functions are not implemented by other >> compilers? > > Yes and no. Of course we could implement them. But I for one wasn't > even aware that they existed in the API. I don't know when they were > added, or by whom, and I may not even be sure what they are supposed to > do. For instance, you mention not opening a file if it already exists, > but the Haddock does not say anything about that. They were added in Jan 2005 by Krasimir: Thu Jan 6 19:35:07 GMT 2005 krasimir * [project @ 2005-01-06 19:35:05 by krasimir] add temporary files API I agree the documentation is lacking and should be improved. The reason they were added to System.IO, I suspect is because the alternative is worse: System.IO.Extras, GHC.IO.Extras or something else. Apart from being uninformative names, there's nothing compiler-dependent about these functions, and our naming guidelines forbid module names that don't have anything to do with functionality. The intention was that the missing implementations would appear in due course. Perhaps as a first step, rather than just omitting them from the export list where they aren't supported, they should be replaced by dummy definitions that emit a helpful error message? I suspect there are many such examples in the base package, FWIW. nch98 doesn't implement various bits of System.IO.Error, for example. Hugs has a very different version of Control.Concurrent. Cheers, Simon From Malcolm.Wallace at cs.york.ac.uk Mon Apr 2 10:36:50 2007 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Mon Apr 2 10:36:44 2007 Subject: proposal: add 'unsafeCoerce' In-Reply-To: <20061110114748.7afc4434.Malcolm.Wallace@cs.york.ac.uk> References: <20061110114748.7afc4434.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <20070402153650.26a8397d.Malcolm.Wallace@cs.york.ac.uk> I wrote (back in November): > Currently, all implementations provide either the 'unsafeCoerce' or > 'unsafeCoerce#' functions, but they live in implementation-specific > locations. This proposal is to adopt the Haskell'98-compatible name > 'unsafeCoerce', and to add it to the standard base library package. > > http://hackage.haskell.org/trac/ghc/ticket/994 Discussion finished, with a general feeling that this would be a good thing. There were some objections from Iavor (and others) that the behaviour of 'unsafeCoerce' is entirely implementation-dependent. Others replied, yes, indeed, but it _is_ marked "unsafe". The proposal merely makes the same name available in all compilers (to avoid the need for CPP), but gives no guarantees about its effects. You must satisfy yourself about whether any given usage is safe or not, with any given compiler. So I have just pushed a patch for this. The final location chosen in the module hierarchy was Unsafe.Coerce. Regards, Malcolm From stefanor at cox.net Mon Apr 2 11:39:27 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Mon Apr 2 11:38:28 2007 Subject: darcs patch: Fix precedence passing for patterns in L... (and 1 more) Message-ID: Testing = typechecked Mon Apr 2 08:26:34 PDT 2007 Stefan O'Rear * Fix precedence passing for patterns in LamE (fixes \((:) x xs) -> x misprinting) Mon Apr 2 08:28:54 PDT 2007 Stefan O'Rear * Pretty-print an empty list of fundeps without '|' (should fix #1260) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 782 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/libraries/attachments/20070402/79bce0aa/attachment.bin From bos at serpentine.com Mon Apr 2 13:12:48 2007 From: bos at serpentine.com (Bryan O'Sullivan) Date: Mon Apr 2 13:09:15 2007 Subject: Proposal [Trac #1212]: add IPv6 support to network library In-Reply-To: <200704011250.11061.sven.panne@aedion.de> References: <45F268D0.8090504@serpentine.com> <460EACAD.4070207@serpentine.com> <200704011250.11061.sven.panne@aedion.de> Message-ID: <46113990.3030904@serpentine.com> Sven Panne wrote: > * You use an internal class HostAddr and make two type synonyms an instance > of it. You must have downloaded the first version of the patch that I posted a few weeks ago. The updated version doesn't have this rather unpleasant wart. Unfortunately, Trac won't let me drop old versions of a patch. > * The types and values of AddrInfoFlags/NameInfoFlags are not very > Haskell-like. Using > > data AddrInfoFlag = Passive | CanonName | NumericHost | ... > > and [AddrInfoFlag] instead of AddrInfoFlags is much nicer. OK, I'll update the interface to look like this. It would be nice if there were helper functions in Foreign.Marshal.Utils or Data.Bits to make this a more mindless operation: import Data.Bits import Data.List (foldl') packBits :: (Eq a, Bits b) => [(a, b)] -> [a] -> b packBits mapping xs = foldl' pack 0 mapping where pack acc (k, v) | k `elem` xs = acc .|. v | otherwise = acc unpackBits :: Bits b => [(a, b)] -> b -> [a] unpackBits mapping bits = foldl' unpack [] mapping where unpack acc (k, v) | bits .&. v == 0 = acc | otherwise = k:acc It's simple boilerplate, but nice not to need to write. This would make the conversion process very tidy: aiMapping = [(AI_PASSIVE, #const AI_PASSIVE), (AI_CANONNAME, #const AI_CANONNAME), ...and so on...] packAIFlags = packBits aiMapping unpackAIFlags = unpackBits aiMapping Assuming people like the interface, should I submit this as a separate proposal, or just fold it into Network.Socket? > Alas, the X11 package is not nice regarding the last item, either... :-( True. But there's an SoC proposal to add XCB bindings, which could presumably use this bit-swizzling code :-) References: <45F268D0.8090504@serpentine.com> <460EACAD.4070207@serpentine.com> <20070401155613.GA6232@matrix.chaos.earth.li> Message-ID: <461139E6.8020802@serpentine.com> Ian Lynagh wrote: > On Sat, Mar 31, 2007 at 01:47:09PM +0000, Bryan O'Sullivan wrote: >> http://hackage.haskell.org/trac/ghc/attachment/ticket/1212/ipv6.2.patch > > This contains: > > hunk ./network.cabal 2 > -version: 2.0 > +version: 2.0.1 The perils of "darcs record -a" :) Thanks for spotting that; I'll drop that hunk when I submit a new patch that addresses Sven's comments. References: <45F268D0.8090504@serpentine.com> <460EACAD.4070207@serpentine.com> <200704011250.11061.sven.panne@aedion.de> <46113990.3030904@serpentine.com> Message-ID: <46113B78.3080404@serpentine.com> Bryan O'Sullivan wrote: > unpackBits :: Bits b => [(a, b)] -> b -> [a] > > unpackBits mapping bits = foldl' unpack [] mapping > where unpack acc (k, v) | bits .&. v == 0 = acc > | otherwise = k:acc Of course, this is stricter than it needs to be, and should use foldr instead of foldl'. But I hope that the idea is useful nevertheless :-) References: <32808E09-F1E5-425E-895B-773E48F6C682@eecs.oregonstate.edu> Message-ID: Martin, Thanks for your work on this very interesting library. For the record, I was able to build it here on an x86 architecture under ghc 6.6, but only with -fglasgow-exts, and one other minor tweak. If anyone wants details, let me know. Andrew On 4/2/07, Martin Erwig wrote: > FGL - A Functional Graph Library, Version: April 2007 > ===================================================== > > A new release of the Functional Graph Library for Haskell > is available at: > > http://eecs.oregonstate.edu/~erwig/fgl/haskell/ > > This release fixes some bugs in the implementation of > several basic inspection functions. > > > -- > Martin > > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > From jyasskin at gmail.com Tue Apr 3 01:12:56 2007 From: jyasskin at gmail.com (Jeffrey Yasskin) Date: Tue Apr 3 01:11:48 2007 Subject: [Haskell] ANNOUNCE: new FGL version (April 2007) In-Reply-To: References: <32808E09-F1E5-425E-895B-773E48F6C682@eecs.oregonstate.edu> Message-ID: <5d44f72f0704022212n8960319q381de14ca3c9cd5d@mail.gmail.com> I've been working on two small patches to the darcs repository at http://darcs.haskell.org/packages/fgl/. Is there another mainline I should be working against? On 4/2/07, Andrew Wagner wrote: > Martin, > Thanks for your work on this very interesting library. For the record, > I was able to build it here on an x86 architecture under ghc 6.6, but > only with -fglasgow-exts, and one other minor tweak. If anyone wants > details, let me know. > > Andrew > > On 4/2/07, Martin Erwig wrote: > > FGL - A Functional Graph Library, Version: April 2007 > > ===================================================== > > > > A new release of the Functional Graph Library for Haskell > > is available at: > > > > http://eecs.oregonstate.edu/~erwig/fgl/haskell/ > > > > This release fixes some bugs in the implementation of > > several basic inspection functions. > > -- Namast?, Jeffrey Yasskin From bos at serpentine.com Tue Apr 3 03:18:54 2007 From: bos at serpentine.com (Bryan O'Sullivan) Date: Tue Apr 3 03:15:17 2007 Subject: Proposal [Trac #1212]: add IPv6 support to network library In-Reply-To: <200704011250.11061.sven.panne@aedion.de> References: <45F268D0.8090504@serpentine.com> <460EACAD.4070207@serpentine.com> <200704011250.11061.sven.panne@aedion.de> Message-ID: <4611FFDE.3010206@serpentine.com> Sven Panne wrote: > I've downloaded your darcs repo, and it built fine (openSUSE 10.2 x86_64). I've updated both the ticket and repo with the latest change, to use lists instead of bitmasks. I left flag names as AI_FOO etc due to name clashes. darcs get --partial http://darcs.serpentine.com/network6 References: <45F268D0.8090504@serpentine.com> <200704011250.11061.sven.panne@aedion.de> <4611FFDE.3010206@serpentine.com> Message-ID: <200704031052.04743.sven.panne@aedion.de> On Tuesday 03 April 2007 09:18, Bryan O'Sullivan wrote: > I've updated both the ticket and repo with the latest change, to use > lists instead of bitmasks. I left flag names as AI_FOO etc due to name > clashes. [...] Naming entities always has a slightly religious touch, but personally I don't like those C names in Haskell. Prefixing things in C is only necessary because you basically don't have any control over namespaces, but Haskell is quite different from it. 'NumericHost' looks much nicer and Haskell-like than 'AI_NUMERICHOST', and even in the unlikely case that there is a name clash, one could always use qualification. Anyway, the constructors of 'Family' have traditionally ugly names, too, so perhaps to keep the "consistency of unattractiveness", I can live with the 'AI_' and 'NI_' prefixes... :-P BTW, what's that' DummySocketOption__' thingy? If I see things correctly, you can't use it with {g,s}etSocketOption and it has no other visible use. Cheers, S. From simonmarhaskell at gmail.com Tue Apr 3 06:21:34 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Apr 3 06:20:34 2007 Subject: Proposal: reduce base from the top Message-ID: <46122AAE.7060405@gmail.com> This is an attempt to propose a set of changes that we could reasonably make in the GHC 6.8 timeframe, that would significantly reduce the size of base and give us more flexibility to independently develop packages. This is not an attempt to solve all the issues we have in one go, but a practical incremental step towards the goal. I'm not trying to make base compiler-independent for example; that's a worthy goal, but it's not clear (at least to me) how to get there yet. What I'm doing here is disentangling the dependencies from the top down. We started on this path before GHC 6.6 (see http://hackage.haskell.org/trac/ghc/ticket/710), this proposal will clarify some the details of the next stage. There may be dependencies I've missed, but as far as I'm aware all of the following is possible without any significant rewriting of code. These reoganisations will allow more reuse: for example, more libraries will be able to make direct use of the unix/Win32 packages rather than being limited to the primitives available in the base package, so cleanups will be possible after the reoganisation. There are several things I'm not completely sure about, and some naming issues to resolve, so please take a look and comment if you can. I'll make one request regarding comments: please don't suggest renaming modules at this point. There are various modules whose names I'm aware are contentious, but I think it would be a distraction to discuss those as part of this proposal; let's do it separately. Here goes: System.Time --> new package old-time (dep. on unix/Win32) System.Locale --> new package old-locale System.Posix.Signals --> unix (System.Cmd depends on it, but moves to new package process) System.Directory --> new package directory (dep. on filepath, unix/Win32) System.Directory.Internals goes away, use filepath instead Data.Array.* --> new package array (maybe; I'm slightly dubious here) (dep. on concurrent for Data.Array.Diff) Data.Generics.* --> generics (maybe; Data class is defined for everything and is derivable) Data.ByteString.* --> fps (dep. on base, generics, array) Control.Concurrent.*, System.Timeout --> new package concurrent (needed by Data.Unique, where to move it?) Control.Parallel.* --> new package parallel System.Process, System.Cmd --> new package process (dep. on concurrent) Control.Applicative Data.Foldable, Data.Traversable Data.Map, Data.IntMap, Data.Set, Data.IntSet Data.Sequence, Data.Tree Data.HashTable Data.Graph ---> new package collections? containers? or split further? (dep. on array, generics, concurrent) System.Console.GetOpt ---> new package getopt? consoleutils? Text.PrettyPrint.* ---> new package pretty System.Random ---> new package random (modify to use time, not old-time) Other modules we could move: Text.Printf, Data.Unique, Data.Monoid, System.CPUTime. Topological sort of core packages with dependencies --------------------------------------------------- base unix/Win32 (base) generics (base) concurrent (base) parallel (base) filepath (base) Cabal (base) readline (base) regex-base (base) regex-posix (base, regex-base) regex-compat (base, regex-base, regex-posix) parsec (base) stm (base) template-haskell (base) pretty (base) (could drop from core-packages) getopt (base) (could drop from core-packages) old-locale (base) old-time (base, unix/Win32) array (base, generics, concurrent) fps (base, generics, array) process (base, unix/Win32, concurrent) directory (base, unix/Win32, filepath) time (base, unix/Win32) random (base, unix/Win32, time) haskell98 (old-time, old-locale, random, directory, process) containers (base, array, generics, concurrent) From igloo at earth.li Tue Apr 3 07:42:31 2007 From: igloo at earth.li (Ian Lynagh) Date: Tue Apr 3 07:41:24 2007 Subject: Proposal: reduce base from the top In-Reply-To: <46122AAE.7060405@gmail.com> References: <46122AAE.7060405@gmail.com> Message-ID: <20070403114231.GA1576@matrix.chaos.earth.li> Hi Simon, On Tue, Apr 03, 2007 at 11:21:34AM +0100, Simon Marlow wrote: > > Data.ByteString.* > --> fps (dep. on base, generics, array) I think this should be called bytestring; fps will just be a random string to newcomers to Haskell. > Control.Concurrent.*, System.Timeout > --> new package concurrent > (needed by Data.Unique, where to move it?) At worst it can go in a "unique" package. > Control.Applicative > Data.Foldable, Data.Traversable > Data.Map, Data.IntMap, Data.Set, Data.IntSet > Data.Sequence, Data.Tree > Data.HashTable > Data.Graph > ---> new package collections? containers? or split further? > (dep. on array, generics, concurrent) I assume you give "containers" as an option because I used it in #710, but I think I prefer "collections" myself. I'm not sure if it should be plural or singular. Logically it should match "array", but somehow "array" and "containers" feels right. > System.Console.GetOpt > ---> new package getopt? consoleutils? It might be nice to leave "getopt" for a future C getopt binding. I haven't checked for any dependencies you've missed or anything, but I think the way to do this sort of thing is to agree on a split in principle and then see if anything breaks when you try it. Overall it looks good, and makes later, more exciting refactoring easier! Thanks Ian From sven.panne at aedion.de Tue Apr 3 09:13:57 2007 From: sven.panne at aedion.de (Sven Panne) Date: Tue Apr 3 09:12:49 2007 Subject: Proposal: reduce base from the top In-Reply-To: <20070403114231.GA1576@matrix.chaos.earth.li> References: <46122AAE.7060405@gmail.com> <20070403114231.GA1576@matrix.chaos.earth.li> Message-ID: <200704031513.57216.sven.panne@aedion.de> On Tuesday 03 April 2007 13:42, Ian Lynagh wrote: > On Tue, Apr 03, 2007 at 11:21:34AM +0100, Simon Marlow wrote: > [...] > > System.Console.GetOpt > > ---> new package getopt? consoleutils? > > It might be nice to leave "getopt" for a future C getopt binding. Hmmm, System.Console.GetOpt is meant as a functionally 100% complete Haskell-like replacement for getopt(3). Is there anything missing? Anyway, using a package for a single module looks a little bit like overkill to me. But if we do that, "getopt" should be the natural name. Cheers, S. From ross at soi.city.ac.uk Tue Apr 3 09:36:06 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Apr 3 09:34:59 2007 Subject: Proposal: reduce base from the top In-Reply-To: <46122AAE.7060405@gmail.com> References: <46122AAE.7060405@gmail.com> Message-ID: <20070403133606.GA3068@soi.city.ac.uk> On Tue, Apr 03, 2007 at 11:21:34AM +0100, Simon Marlow wrote: > This is an attempt to propose a set of changes that we could reasonably > make in the GHC 6.8 timeframe, that would significantly reduce the size of > base and give us more flexibility to independently develop packages. > [...] > Control.Applicative > Data.Foldable, Data.Traversable > Data.Map, Data.IntMap, Data.Set, Data.IntSet > Data.Sequence, Data.Tree > Data.HashTable > Data.Graph > ---> new package collections? containers? or split further? > (dep. on array, generics, concurrent) Data.HashTable (and thus Data.Array.*) is used in the implementation of Data.Typeable. It also differs from the others in being a mutable data structure. I imagine that without it this package wouldn't need to depend on array and concurrent. Data.Monoid could possibly go here too. Another possibility is to split the 4 class modules from the concrete data structures. From dons at cse.unsw.edu.au Tue Apr 3 09:39:28 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Tue Apr 3 09:38:24 2007 Subject: Proposal: reduce base from the top In-Reply-To: <46122AAE.7060405@gmail.com> References: <46122AAE.7060405@gmail.com> Message-ID: <20070403133928.GA16808@cse.unsw.EDU.AU> simonmarhaskell: > This is an attempt to propose a set of changes that we could reasonably > make in the GHC 6.8 timeframe, that would significantly reduce the size of > base and give us more flexibility to independently develop packages. > > This is not an attempt to solve all the issues we have in one go, but a > practical incremental step towards the goal. I'm not trying to make base > compiler-independent for example; that's a worthy goal, but it's not clear > (at least to me) how to get there yet. What I'm doing here is > disentangling the dependencies from the top down. We started on this path > before GHC 6.6 (see http://hackage.haskell.org/trac/ghc/ticket/710), this > proposal will clarify some the details of the next stage. > > There may be dependencies I've missed, but as far as I'm aware all of the > following is possible without any significant rewriting of code. These > reoganisations will allow more reuse: for example, more libraries will be > able to make direct use of the unix/Win32 packages rather than being > limited to the primitives available in the base package, so cleanups will > be possible after the reoganisation. There are several things I'm not > completely sure about, and some naming issues to resolve, so please take a > look and comment if you can. > > I'll make one request regarding comments: please don't suggest renaming > modules at this point. There are various modules whose names I'm aware are > contentious, but I think it would be a distraction to discuss those as part > of this proposal; let's do it separately. > > Here goes: > > System.Time > --> new package old-time (dep. on unix/Win32) > > System.Locale > --> new package old-locale > > System.Posix.Signals > --> unix (System.Cmd depends on it, but moves to new package process) > > System.Directory > --> new package directory (dep. on filepath, unix/Win32) > System.Directory.Internals goes away, use filepath instead > > Data.Array.* > --> new package array (maybe; I'm slightly dubious here) > (dep. on concurrent for Data.Array.Diff) > > Data.Generics.* > --> generics (maybe; Data class is defined for everything and is derivable) > > Data.ByteString.* > --> fps (dep. on base, generics, array) Yep, but we might call it the 'bytestring' package as Ian suggests. I'm good with this. > > Control.Concurrent.*, System.Timeout > --> new package concurrent > (needed by Data.Unique, where to move it?) > > Control.Parallel.* > --> new package parallel > > System.Process, System.Cmd > --> new package process (dep. on concurrent) > > Control.Applicative > Data.Foldable, Data.Traversable > Data.Map, Data.IntMap, Data.Set, Data.IntSet > Data.Sequence, Data.Tree > Data.HashTable > Data.Graph > ---> new package collections? containers? or split further? > (dep. on array, generics, concurrent) > > System.Console.GetOpt > ---> new package getopt? consoleutils? > > Text.PrettyPrint.* > ---> new package pretty > > System.Random > ---> new package random (modify to use time, not old-time) > > Other modules we could move: Text.Printf, Data.Unique, Data.Monoid, > System.CPUTime. > > > Topological sort of core packages with dependencies > --------------------------------------------------- > base > unix/Win32 (base) > generics (base) > concurrent (base) > parallel (base) > filepath (base) > Cabal (base) > readline (base) > regex-base (base) > regex-posix (base, regex-base) > regex-compat (base, regex-base, regex-posix) > parsec (base) > stm (base) > template-haskell (base) > pretty (base) (could drop from core-packages) > getopt (base) (could drop from core-packages) > old-locale (base) > old-time (base, unix/Win32) > array (base, generics, concurrent) > fps (base, generics, array) > process (base, unix/Win32, concurrent) > directory (base, unix/Win32, filepath) > time (base, unix/Win32) > random (base, unix/Win32, time) > haskell98 (old-time, old-locale, random, directory, process) > containers (base, array, generics, concurrent) > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries From bulat.ziganshin at gmail.com Tue Apr 3 08:25:38 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Apr 3 09:42:48 2007 Subject: about compiler-independent base In-Reply-To: <46122AAE.7060405@gmail.com> References: <46122AAE.7060405@gmail.com> Message-ID: <1983667553.20070403162538@gmail.com> Hello Simon, Tuesday, April 3, 2007, 2:21:34 PM, you wrote: > This is not an attempt to solve all the issues we have in one go, but a > practical incremental step towards the goal. I'm not trying to make base > compiler-independent for example; that's a worthy goal, but it's not clear (at > least to me) how to get there yet. i'm all for this plan. long way starts with first step about "making base compiler-independent". its *interface* is already compiler-independent. if you say about implementation, it seems rather obvious for me - split it into ghc-base package that includes GHC.* and modules on which GHC.* depend and new-base package which contains the rest. then move any "#ifdef GHC" code into from new-base into *hc-base. then, as time permits, we can start to move ghc-independent code from ghc-base into new-base. meantime, faking Base package may be established that just reexports ghc-base and new-base, so user will not depend on where we moved each particular module my Core library was actually an attempt to separate GHC.* into ghc-specific and ghc-independent part of course, it's entirely separate proposal, we can return to discussing it in some future, probably after your plan will be implemented -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Tue Apr 3 08:31:56 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Apr 3 09:43:03 2007 Subject: Proposal: reduce base from the top In-Reply-To: <20070403114231.GA1576@matrix.chaos.earth.li> References: <46122AAE.7060405@gmail.com> <20070403114231.GA1576@matrix.chaos.earth.li> Message-ID: <104478187.20070403163156@gmail.com> Hello Ian, Tuesday, April 3, 2007, 3:42:31 PM, you wrote: >> Data.ByteString.* >> --> fps (dep. on base, generics, array) > I think this should be called bytestring; fps will just be a random > string to newcomers to Haskell. +1 >> Control.Applicative >> Data.Foldable, Data.Traversable >> Data.Map, Data.IntMap, Data.Set, Data.IntSet >> Data.Sequence, Data.Tree >> Data.HashTable >> Data.Graph >> ---> new package collections? containers? or split further? >> (dep. on array, generics, concurrent) > I assume you give "containers" as an option because I used it in #710, > but I think I prefer "collections" myself. Collections is the name of another existing library ;) >> System.Console.GetOpt >> ---> new package getopt? consoleutils? thhis may be joined with filesystem-related stuff into one package. how about having Unix and Win32 for low-level OS-specific functions and then OS_Services on top of them? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From pixel at mandriva.com Tue Apr 3 10:40:42 2007 From: pixel at mandriva.com (Pixel) Date: Tue Apr 3 10:38:34 2007 Subject: System.Posix.User.getAllUserEntries bugfix Message-ID: it seems setpwent is never called, and so getAllUserEntries can only be used once. Here is a suggested fix: (if i should be posting this somewhere else (a bug system...), please tell me) -------------- next part -------------- A non-text attachment was scrubbed... Name: User.hsc.patch Type: text/x-patch Size: 854 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20070403/67aaccb7/User.hsc.bin From stefanor at cox.net Tue Apr 3 10:46:53 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Tue Apr 3 10:45:59 2007 Subject: Proposal: reduce base from the top In-Reply-To: <20070403133606.GA3068@soi.city.ac.uk> References: <46122AAE.7060405@gmail.com> <20070403133606.GA3068@soi.city.ac.uk> Message-ID: <20070403144653.GA3169@localhost.localdomain> On Tue, Apr 03, 2007 at 02:36:06PM +0100, Ross Paterson wrote: > On Tue, Apr 03, 2007 at 11:21:34AM +0100, Simon Marlow wrote: > > This is an attempt to propose a set of changes that we could reasonably > > make in the GHC 6.8 timeframe, that would significantly reduce the size of > > base and give us more flexibility to independently develop packages. > > [...] > > Control.Applicative > > Data.Foldable, Data.Traversable > > Data.Map, Data.IntMap, Data.Set, Data.IntSet > > Data.Sequence, Data.Tree > > Data.HashTable > > Data.Graph > > ---> new package collections? containers? or split further? > > (dep. on array, generics, concurrent) > > Data.HashTable (and thus Data.Array.*) is used in the implementation > of Data.Typeable. It also differs from the others in being a mutable > data structure. I imagine that without it this package wouldn't need to > depend on array and concurrent. I hear that a lot - but as I see it, why does *Typeable* need to be in base? As long as we have a portable Unsafe.Coerce (exists now), and a portable equivalent to GHC.Prim.Any (should be trivial to add to both Hugs and YHC - names anyone?) Typeable/Dynamic can be a portable high-level library. My cursory grepping of the '*.*hs' files in base reveals only one non-deriving non-SYB use of Typeable/Dynamic/TypeRep: DynException. I suppose this highlights a major problem with the class/module system. If package A defines FooLike, and package B defines Foo, one needs to depend on the other in order for instances to exist. Assuming you don't want O(n^2) instance packages floating around. Random other eample: QuickCheck (Arbitrary) depends on most data types. Stefan From bos at serpentine.com Tue Apr 3 11:18:40 2007 From: bos at serpentine.com (Bryan O'Sullivan) Date: Tue Apr 3 11:17:30 2007 Subject: Proposal [Trac #1212]: add IPv6 support to network library In-Reply-To: <200704031052.04743.sven.panne@aedion.de> References: <45F268D0.8090504@serpentine.com> <200704011250.11061.sven.panne@aedion.de> <4611FFDE.3010206@serpentine.com> <200704031052.04743.sven.panne@aedion.de> Message-ID: <46127050.6070205@serpentine.com> Sven Panne wrote: > Naming entities always has a slightly religious touch, but personally I don't > like those C names in Haskell. I understand. In fact, I took a look at the prevailing uses of names in Network.Socket as I was redoing this patch, and before I committed it. When I tried to use the "more Haskelly" names like NumericHost and so on, I found that of the nine names I had, three of them clashed. "Datagram" clashed with a SocketType, and both AddrInfoFlag and NameInfoFlag had a NumericHost. (I mentioned the clashes in my message yesterday, but not in detail.) Rather than introduce a new naming scheme of NI_NumericHost and so on, I opted to be consistent with the other existing scheme in Network.Socket, of using the C-style names. > BTW, what's that' DummySocketOption__' thingy? Not my fault :-) References: <46122AAE.7060405@gmail.com> Message-ID: On 4/3/07, Simon Marlow wrote: > > System.Directory > --> new package directory (dep. on filepath, unix/Win32) > Why bother with having hierarchical module names if package names are not similarly qualified? It seems like collisions in the packaging name space are just as likely as in the module name space (especially with single-module packages like many that you proposed). There are multiple competing collection libraries available, and a name like "collections" or "containers" does not really help to differentiate this particular library from the others, or suggest its provenance. Considering that arrays are collections, and the "collections/containers" package depends on Data.Array such that significant modifications to Data.Array will probably cause modifications to the modules in "collections/containers," why not just merge Data.Array into the collections/containers package? Regards, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20070403/5134a83d/attachment.htm From jyasskin at gmail.com Wed Apr 4 02:44:11 2007 From: jyasskin at gmail.com (Jeffrey Yasskin) Date: Wed Apr 4 02:43:03 2007 Subject: Proposal [Trac #1266]: Make Data.Graph.Inductive.NodeMap handle slightly messy input without crashing Message-ID: <5d44f72f0704032344q2d6d81c2h48aa6c65e8bbe10b@mail.gmail.com> See http://hackage.haskell.org/trac/ghc/ticket/1266 for the patch. The basic idea is that insMapNode should survive a duplicate node, and insMapEdge should survive (and insert) an edge whose endpoints weren't yet in the graph. This was impossible for the current type of insMapEdge, so I added a safeInsMapEdge instead. There's also a fairly small test suite in here, which people are welcome to suggest improvements to. I suggest a discussion period of two weeks, ending April 17, unless discussion is still active by then, in which case a week after it dies down. Thanks, Jeffrey Yasskin From simonmarhaskell at gmail.com Wed Apr 4 04:15:59 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Apr 4 04:15:17 2007 Subject: Proposal: reduce base from the top In-Reply-To: <20070403144653.GA3169@localhost.localdomain> References: <46122AAE.7060405@gmail.com> <20070403133606.GA3068@soi.city.ac.uk> <20070403144653.GA3169@localhost.localdomain> Message-ID: <46135EBF.6090706@gmail.com> Stefan O'Rear wrote: > On Tue, Apr 03, 2007 at 02:36:06PM +0100, Ross Paterson wrote: >> On Tue, Apr 03, 2007 at 11:21:34AM +0100, Simon Marlow wrote: >>> This is an attempt to propose a set of changes that we could reasonably >>> make in the GHC 6.8 timeframe, that would significantly reduce the size of >>> base and give us more flexibility to independently develop packages. >>> [...] >>> Control.Applicative >>> Data.Foldable, Data.Traversable >>> Data.Map, Data.IntMap, Data.Set, Data.IntSet >>> Data.Sequence, Data.Tree >>> Data.HashTable >>> Data.Graph >>> ---> new package collections? containers? or split further? >>> (dep. on array, generics, concurrent) >> Data.HashTable (and thus Data.Array.*) is used in the implementation >> of Data.Typeable. It also differs from the others in being a mutable >> data structure. I imagine that without it this package wouldn't need to >> depend on array and concurrent. > > I hear that a lot - but as I see it, why does *Typeable* need to be in > base? As long as we have a portable Unsafe.Coerce (exists now), and a > portable equivalent to GHC.Prim.Any (should be trivial to add to both > Hugs and YHC - names anyone?) Typeable/Dynamic can be a portable > high-level library. > > My cursory grepping of the '*.*hs' files in base reveals only one > non-deriving non-SYB use of Typeable/Dynamic/TypeRep: DynException. Separating Typeable and Dynamic from base is certainly something we should try to do, but I think this belongs in the next stage. The DynException dependency might be removed if we switch to using extensible exceptions along the lines of my Haskell Workshop paper from last year. Cheers, Simon From simonmarhaskell at gmail.com Wed Apr 4 06:38:44 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Apr 4 06:37:34 2007 Subject: about compiler-independent base In-Reply-To: <1983667553.20070403162538@gmail.com> References: <46122AAE.7060405@gmail.com> <1983667553.20070403162538@gmail.com> Message-ID: <46138034.2070601@gmail.com> Bulat Ziganshin wrote: > Hello Simon, > > Tuesday, April 3, 2007, 2:21:34 PM, you wrote: > >> This is not an attempt to solve all the issues we have in one go, but a >> practical incremental step towards the goal. I'm not trying to make base >> compiler-independent for example; that's a worthy goal, but it's not clear (at >> least to me) how to get there yet. > > i'm all for this plan. long way starts with first step > > about "making base compiler-independent". its *interface* is already > compiler-independent. if you say about implementation, it seems rather > obvious for me - split it into ghc-base package that includes GHC.* > and modules on which GHC.* depend and new-base package which contains > the rest. then move any "#ifdef GHC" code into from new-base into > *hc-base. then, as time permits, we can start to move ghc-independent > code from ghc-base into new-base. meantime, faking Base package may be > established that just reexports ghc-base and new-base, so user will > not depend on where we moved each particular module Apart from anything else, we don't actually have support for packages that re-expose modules from other packages. This is an important feature and will indeed make package refactoring easier - care to look into implementing it? :-) Cheers, Simon From simonmarhaskell at gmail.com Wed Apr 4 06:39:02 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Apr 4 06:37:53 2007 Subject: Proposal: reduce base from the top In-Reply-To: <20070403133606.GA3068@soi.city.ac.uk> References: <46122AAE.7060405@gmail.com> <20070403133606.GA3068@soi.city.ac.uk> Message-ID: <46138046.1000808@gmail.com> Ross Paterson wrote: > On Tue, Apr 03, 2007 at 11:21:34AM +0100, Simon Marlow wrote: >> This is an attempt to propose a set of changes that we could reasonably >> make in the GHC 6.8 timeframe, that would significantly reduce the size of >> base and give us more flexibility to independently develop packages. >> [...] >> Control.Applicative >> Data.Foldable, Data.Traversable >> Data.Map, Data.IntMap, Data.Set, Data.IntSet >> Data.Sequence, Data.Tree >> Data.HashTable >> Data.Graph >> ---> new package collections? containers? or split further? >> (dep. on array, generics, concurrent) > > Data.HashTable (and thus Data.Array.*) is used in the implementation > of Data.Typeable. It also differs from the others in being a mutable > data structure. I imagine that without it this package wouldn't need to > depend on array and concurrent. Good point; I propose to leave Data.HashTable where it is for now. It doesn't depend on array, fortunately, becuase it uses the low-level IOArray, so this won't prevent the array package from being split. > Data.Monoid could possibly go here too. Another possibility is to split > the 4 class modules from the concrete data structures. If the 4 class modules were in a separate package, any suggestions for naming? Cheers, Simon From bos at serpentine.com Wed Apr 4 18:44:24 2007 From: bos at serpentine.com (Bryan O'Sullivan) Date: Wed Apr 4 18:40:41 2007 Subject: Proposal [Trac #1212]: add IPv6 support to network library In-Reply-To: <200704031052.04743.sven.panne@aedion.de> References: <45F268D0.8090504@serpentine.com> <200704011250.11061.sven.panne@aedion.de> <4611FFDE.3010206@serpentine.com> <200704031052.04743.sven.panne@aedion.de> Message-ID: <46142A48.7010900@serpentine.com> Since we seem to have converged on an agreeable API and implementation for adding IPv6 support to Network.Socket, I've added another patch on top of this that transparently adds IPv6 support to the Network module. This required no API changes, merely a few modifications to the plumbing. I've attached the patch for review. If the Network.Socket change is to go in, I think this one ought to as well. That will leave Network.BSD as a legacy-only package that can only deal with IPv4. darcs get --partial http://darcs.serpentine.com/network6 As a learning excersize, I re-wrote and re-optimized Data.Binary.Builder yesterday. 1. Intuition is NOT your friend. Most obvious pessimizations I made were actually wins, and vice versa. 2. Parameters are very expensive. Our type of functions that build (ignoring CPS for the time being) was MBA# -> Int# -> [ByteString], where the Int# is the current write pointer. Adding an extra Int# to cache the size of the array (rather than calling sMBA# each time) slowed the code down ~2x. Conversely, moving the write pointer into the byte array (storing it in bytes 0#, 1#, 2#, and 3#) sped the code by 4x. 3. MBA# is just as fast as Addr#, and garbage collected to boot. 4. You can't keep track of which version of the code is which, what is a regression, and what is an enhancement. Don't even try. Next time I try something like this I will make as much use of darcs as possible. 5. State# threads clog the optimizer quite effectively. Replacing st(n-1)# with realWorld# everywhere I could count on data dependencies to do the same job doubled performance. 6. The inliner is a bit too greedy. Removing the slow-path code from singleton doesn't help because popSingleton is only used once; but if I explicitly {-# NOINLINE popSingleton #-}, the code for singleton itself becomes much smaller, and inlinable (15% perf gain). Plus the new singleton doesn't allocate memory, so I can use even MORE realWorld#s. And probably a few more I forgot about because of #4. The code is online at http://members.cox.net/stefanor/hackedbuilder if anyone cares (but see #4). Some parting numbers: (Builder7 is my current version, Builder1 is the unmodified rossp/kolmodin builder) stefan@stefans:~/hackedbuilder$ ghc -v0 --make -O2 -fforce-recomp -DBUILDER=Builder7 Bench.hs ; time ./Bench 2 10000000 330000000 real 0m5.580s user 0m5.540s sys 0m0.032s stefan@stefans:~/hackedbuilder$ ghc -v0 --make -O2 -fforce-recomp -DBUILDER=Builder7 -DUNROLL Bench.hs ; time ./Bench 2 10000000 330000000 real 0m2.948s user 0m2.908s sys 0m0.036s stefan@stefans:~/hackedbuilder$ ghc -v0 --make -O2 -fforce-recomp -DBUILDER=Builder1 Bench.hs ; time ./Bench 2 10000000 330000000 real 0m55.708s user 0m54.695s sys 0m0.208s stefan@stefans:~/hackedbuilder$ ghc -v0 --make -O2 -fforce-recomp -DBUILDER=Builder1 -DUNROLL Bench.hs ; time ./Bench 2 10000000 330000000 real 0m25.888s user 0m25.546s sys 0m0.156s stefan@stefans:~/hackedbuilder$ gcc -O2 -march=pentium4 CBuilder.c -o CBuilder ; time ./CBuilder 10000000 real 0m0.861s user 0m0.860s sys 0m0.000s Stefam From simonpj at microsoft.com Thu Apr 5 03:15:07 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Apr 5 03:13:57 2007 Subject: What I learned from my first serious attempt low-level Haskell programming In-Reply-To: <20070404231131.GA4967@localhost.localdomain> References: <20070404231131.GA4967@localhost.localdomain> Message-ID: | 5. State# threads clog the optimizer quite effectively. Replacing | st(n-1)# with realWorld# everywhere I could count on data | dependencies to do the same job doubled performance. The idea is that the optimiser should allow you to write at a high level, and do the book keeping for you. When it doesn't, I like to know, and preferably fix. If you had a moment to boil out a small, reproducible example of this kind of optimisation failure (with as few dependencies as poss), then I'll look to see if the optimiser can be cleverer. | | 6. The inliner is a bit too greedy. Removing the slow-path code from | singleton doesn't help because popSingleton is only used once; but | if I explicitly {-# NOINLINE popSingleton #-}, the code for | singleton itself becomes much smaller, and inlinable (15% perf | gain). Plus the new singleton doesn't allocate memory, so I can | use even MORE realWorld#s. That's a hard one! Inlining functions that are called just once is a huge win usually. I don't know how to spot what you did in an automated way. thanks Simon From simonmarhaskell at gmail.com Thu Apr 5 03:52:52 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Apr 5 03:51:40 2007 Subject: What I learned from my first serious attempt low-level Haskell programming In-Reply-To: References: <20070404231131.GA4967@localhost.localdomain> Message-ID: <4614AAD4.5030907@gmail.com> Stefan O'Rear wrote: > 2. Parameters are very expensive. Our type of functions that build > (ignoring CPS for the time being) was MBA# -> Int# -> [ByteString], > where the Int# is the current write pointer. Adding an extra Int# > to cache the size of the array (rather than calling sMBA# each > time) slowed the code down ~2x. Conversely, moving the write > pointer into the byte array (storing it in bytes 0#, 1#, 2#, and > 3#) sped the code by 4x. If you were measuring on x86 then parameters are passed on the stack, which may be expensive. On x86_64 the first 3 arguments are passed in registers, which is usually a win, but if the function immediately does an eval they need to be saved on the stack anyway. Still, 4x sounds like a lot, perhaps you managed to avoid a stack check in the inner loop or something. > 3. MBA# is just as fast as Addr#, and garbage collected to boot. Not really surprising, that. > 4. You can't keep track of which version of the code is which, what is > a regression, and what is an enhancement. Don't even try. Next > time I try something like this I will make as much use of darcs as > possible. Absolutely - if you'd used darcs, then we could peer in more detail at changes that you thought gave counter-intuitive results. Simon Peyton-Jones wrote: > | 5. State# threads clog the optimizer quite effectively. Replacing > | st(n-1)# with realWorld# everywhere I could count on data > | dependencies to do the same job doubled performance. > > The idea is that the optimiser should allow you to write at a high level, and do the book keeping for you. When it doesn't, I like to know, and preferably fix. > > If you had a moment to boil out a small, reproducible example of this kind of optimisation failure (with as few dependencies as poss), then I'll look to see if the optimiser can be cleverer. Yes, and *please* add some of this folklore to the performance wiki at http://haskell.org/haskellwiki/Performance, if you have the time. Cheers, Simon From rob at mits.coop Thu Apr 5 05:14:25 2007 From: rob at mits.coop (Robert Marlow) Date: Thu Apr 5 05:13:14 2007 Subject: Proposal: ByteString based datagram communication (Ticket #1238 ) In-Reply-To: <1174403822.3736.347.camel@localhost> References: <1174403822.3736.347.camel@localhost> Message-ID: <1175764465.3652.10.camel@localhost> Hi all I'm back and am keen to work on getting this patch accepted. Concerns I've so far seen raised include 1. bos: It breaks the existing stable API I need more information on this; I can't see what's broken unless the change of sendTo and recvFrom to datagram functions is what is considered broken. I'd argue the current sendTo and recvFrom functions are what is broken in terms of usefulness and how their functionality fits their names. This patch fixes that. 2. bos: It restricts to AF_INET As far as my testing has shown it should also work with AF_UNIX. To get it working with AF_UNIX the patch also includes a bugfix in Network.Socket. As such, the patch should hopefully reduce the current AF_INET restriction. 3. dons: Similar work has been done on HAppS and HaskellNet I'm keen to integrate any ideas from these platforms. I'm discussing it with S. Alexander Jacobson. If anyone can outline some good ideas from these platforms that should be included in the patch I'll gladly look into it. However, It's meant to be a simple change to make sendTo and recvFrom act as expected of network utilities with those names while providing convenient and efficient datagram utilities similar to what exists for stream based connections rather than add too many features. 4. me: It's not tested as well as I'd like I'm having trouble testing with hugs. runhugs -98 ./Setup.hs build returns 'ERROR "dist/build/Network/BSD.hs" - Can't find imported module "GHC.IOBase"'. Something screwy with hsc2hs or cpphs? I don't have windows so still haven't tested that. Can any Windows users help please? On Wed, 2007-03-21 at 00:17 +0900, Robert Marlow wrote: > I've made a proposal to add ByteString based datagram communication to > Network.Socket and Network. Details are at: > > http://hackage.haskell.org/trac/ghc/ticket/1238#preview > > I rushed to get this done before I go on a trip tomorrow so I haven't > completed testing and won't be available to discuss it for the next 9 > days. As such, if discussion is needed, an extended deadline would be > appreciated. > > Testing windows is a bit awkward for me since I don't have a windows > machine, so if anyone can test that platform I'd be very appreciative. > I'll try to work through the problems I was having with hugs and test > when I get back unless someone else wants to test it first. > > Thanks. > -- Robert Marlow MITS Co-operative Limited http://www.mits.coop/ From ross at soi.city.ac.uk Thu Apr 5 05:26:24 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Apr 5 05:25:11 2007 Subject: Proposal: ByteString based datagram communication (Ticket #1238 ) In-Reply-To: <1175764465.3652.10.camel@localhost> References: <1174403822.3736.347.camel@localhost> <1175764465.3652.10.camel@localhost> Message-ID: <20070405092624.GA5420@soi.city.ac.uk> On Thu, Apr 05, 2007 at 06:14:25PM +0900, Robert Marlow wrote: > 4. me: It's not tested as well as I'd like > I'm having trouble testing with hugs. runhugs -98 ./Setup.hs build > returns 'ERROR "dist/build/Network/BSD.hs" - Can't find imported > module "GHC.IOBase"'. Something screwy with hsc2hs or cpphs? I think it's because the GHC version of hsc2hs uses ghc as its C compiler, which sets __GLASGOW_HASKELL__. You should be able to work around this by adding --with-hsc2hs=/usr/local/bin/hsc2hs-hugs or similar to setup configure when building for Hugs. From john at repetae.net Thu Apr 5 05:32:22 2007 From: john at repetae.net (John Meacham) Date: Thu Apr 5 05:31:08 2007 Subject: Proposal: ByteString based datagram communication (Ticket #1238 ) In-Reply-To: <1175764465.3652.10.camel@localhost> References: <1174403822.3736.347.camel@localhost> <1175764465.3652.10.camel@localhost> Message-ID: <20070405093222.GB16785@momenergy.repetae.net> you might want to consider any API consequences of supporting DCCP http://en.wikipedia.org/wiki/Datagram_Congestion_Control_Protocol I am not saying full DCCP support is needed off the bat, but it would be nice if at some point in the future the API could be extended gracefully to support it as well as UDP as far as unreliable datagram style communication goes. John -- John Meacham - ?repetae.net?john? From rob at mits.coop Thu Apr 5 05:57:24 2007 From: rob at mits.coop (Robert Marlow) Date: Thu Apr 5 05:56:15 2007 Subject: Proposal: ByteString based datagram communication (Ticket #1238 ) In-Reply-To: <20070405092624.GA5420@soi.city.ac.uk> References: <1174403822.3736.347.camel@localhost> <1175764465.3652.10.camel@localhost> <20070405092624.GA5420@soi.city.ac.uk> Message-ID: <1175767044.3652.18.camel@localhost> Gah, I tried that a couple of times and it made no difference. I tried it again after getting your email and it did something different. Your email must have been the magic key it was waiting for. Computers can be mysterious. Anyway, the difference unfortunately isn't that it now works. Instead it spits the same error it gave me when I tried running hsc2hs-hugs on BSD.hsc directly: $ runhugs -98 ./Setup.hs build Preprocessing library network-2.0... Network/BSD_hsc_make.c:1:49: error: /usr/share/hsc2hs-0.67/template-hsc.h: No such file or directory BSD.hsc: In function ?main?: BSD.hsc:578: warning: incompatible implicit declaration of built-in function ?printf? BSD.hsc:571: error: ?stdout? undeclared (first use in this function) BSD.hsc:571: error: (Each undeclared identifier is reported only once BSD.hsc:571: error: for each function it appears in.) BSD.hsc:150: error: expected expression before ?struct? BSD.hsc:151: error: expected expression before ?struct? BSD.hsc:154: error: expected expression before ?struct? BSD.hsc:155: error: expected expression before ?struct? BSD.hsc:254: error: expected expression before ?struct? BSD.hsc:255: error: expected expression before ?struct? BSD.hsc:265: error: expected expression before ?struct? BSD.hsc:348: error: expected expression before ?struct? BSD.hsc:349: error: expected expression before ?struct? BSD.hsc:352: error: expected expression before ?struct? BSD.hsc:354: error: expected expression before ?struct? BSD.hsc:453: error: expected expression before ?struct? BSD.hsc:454: error: expected expression before ?struct? BSD.hsc:457: error: expected expression before ?struct? BSD.hsc:458: error: expected expression before ?struct? compiling Network/BSD_hsc_make.c failed command was: /usr/bin/gcc -c -I/usr/lib/hugs/include -Iinclude Network/BSD_hsc_make.c -o Network/BSD_hsc_make.o ./Setup.hs: got error code while preprocessing: Network.BSD Any ideas? On Thu, 2007-04-05 at 10:26 +0100, Ross Paterson wrote: > On Thu, Apr 05, 2007 at 06:14:25PM +0900, Robert Marlow wrote: > > 4. me: It's not tested as well as I'd like > > I'm having trouble testing with hugs. runhugs -98 ./Setup.hs build > > returns 'ERROR "dist/build/Network/BSD.hs" - Can't find imported > > module "GHC.IOBase"'. Something screwy with hsc2hs or cpphs? > > I think it's because the GHC version of hsc2hs uses ghc as its C compiler, > which sets __GLASGOW_HASKELL__. You should be able to work around this > by adding --with-hsc2hs=/usr/local/bin/hsc2hs-hugs or similar to setup > configure when building for Hugs. > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries -- Robert Marlow MITS Co-operative Limited http://www.mits.coop/ From rob at mits.coop Thu Apr 5 06:23:00 2007 From: rob at mits.coop (Robert Marlow) Date: Thu Apr 5 06:21:55 2007 Subject: Proposal: ByteString based datagram communication (Ticket #1238 ) In-Reply-To: <20070405093222.GB16785@momenergy.repetae.net> References: <1174403822.3736.347.camel@localhost> <1175764465.3652.10.camel@localhost> <20070405093222.GB16785@momenergy.repetae.net> Message-ID: <1175768581.3652.38.camel@localhost> I think this is a bit of a sidetrack from the goal of this patch but I agree; It would definitely be nice to be able to easily extend the API in such a manner. My goal in this particular patch was to give a set of (primarily UDP) datagram functions with an interface analogous to what existed for the stream (TCP) functions. TCP and UDP are currently the primary network technologies used today. Though DCCP (and ICMP) would be nice too. My knee-jerk opinion is that the current use of HostName and PortID already assume IPv4 protocols such as TCP and UDP more than they could. Unix socket functions for example make no use of the HostName argument at all and the UnixSocket constructor just doesn't sound like it fits the name of the type "PortID" to me. Consequently, I think making the Network module more flexible for extension would involve getting rid of the current addressing scheme and implementing some new Address type which includes not just the address, but the protocol used. So something like data Address = TCP HostName PortNumber | UDP HostName PortNumber | DCCP HostName PortNumber | UnixSocket FilePath -- Maybe also inet6: | TCP6 HostName6 PortNumber | UDP6 HostName6 PortNumber and so forth. Of course this is beyond the scope of this patch. On Thu, 2007-04-05 at 02:32 -0700, John Meacham wrote: > you might want to consider any API consequences of supporting DCCP > > http://en.wikipedia.org/wiki/Datagram_Congestion_Control_Protocol > > I am not saying full DCCP support is needed off the bat, but it would be > nice if at some point in the future the API could be extended gracefully > to support it as well as UDP as far as unreliable datagram style > communication goes. > > John -- Robert Marlow MITS Co-operative Limited http://www.mits.coop/ From ross at soi.city.ac.uk Thu Apr 5 06:47:10 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Apr 5 06:45:58 2007 Subject: Proposal: ByteString based datagram communication (Ticket #1238 ) In-Reply-To: <1175767044.3652.18.camel@localhost> References: <1174403822.3736.347.camel@localhost> <1175764465.3652.10.camel@localhost> <20070405092624.GA5420@soi.city.ac.uk> <1175767044.3652.18.camel@localhost> Message-ID: <20070405104710.GB5420@soi.city.ac.uk> On Thu, Apr 05, 2007 at 06:57:24PM +0900, Robert Marlow wrote: > Anyway, the difference unfortunately isn't that it now works. Instead it > spits the same error it gave me when I tried running hsc2hs-hugs on > BSD.hsc directly: > > $ runhugs -98 ./Setup.hs build > Preprocessing library network-2.0... > Network/BSD_hsc_make.c:1:49: > error: /usr/share/hsc2hs-0.67/template-hsc.h: No such file or directory How odd. It works for me from a vanilla hugs98-Sep2006 build. Are you using a pre-packaged version? From bulat.ziganshin at gmail.com Thu Apr 5 06:50:49 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Apr 5 06:57:20 2007 Subject: [Haskell-cafe] What I learned from my first serious attempt low-level Haskell programming In-Reply-To: <20070404231131.GA4967@localhost.localdomain> References: <20070404231131.GA4967@localhost.localdomain> Message-ID: <1722205210.20070405145049@gmail.com> Hello Stefan, Thursday, April 5, 2007, 3:11:31 AM, you wrote: > 2. Parameters are very expensive. you should look at the asm code GHC generates. afair parameters are kept in stack and copied on each call (to the same place!). such sort of things are also very dependent on backend used - was it a ASM or C one? btw, it would be great if you will share your experience on haskell wiki -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Thu Apr 5 07:08:22 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Apr 5 07:09:29 2007 Subject: Proposal: ByteString based datagram communication (Ticket #1238 ) In-Reply-To: <1175764465.3652.10.camel@localhost> References: <1174403822.3736.347.camel@localhost> <1175764465.3652.10.camel@localhost> Message-ID: <49928550.20070405150822@gmail.com> Hello Robert, Thursday, April 5, 2007, 1:14:25 PM, you wrote: > 1. bos: It breaks the existing stable API > I need more information on this; I can't see what's broken unless the > change of sendTo and recvFrom to datagram functions is what is > considered broken. I'd argue the current sendTo and recvFrom > functions are what is broken in terms of usefulness and how their > functionality fits their names. This patch fixes that. but why you provide ByteString-only API?? i think that more common idiom is to provide String functions here and use somewhat like Network.ByteString, Network.ByteString.Lazy modules to provide ByteString/ByteStringLazy equivalents of String function from Network.hs -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From igloo at earth.li Thu Apr 5 08:00:32 2007 From: igloo at earth.li (Ian Lynagh) Date: Thu Apr 5 07:59:18 2007 Subject: darcs patch: Fix precedence passing for patterns in L... (and 1 more) In-Reply-To: References: Message-ID: <20070405120032.GA17915@matrix.chaos.earth.li> He Stefan, On Mon, Apr 02, 2007 at 08:39:27AM -0700, Stefan O'Rear wrote: > > Mon Apr 2 08:26:34 PDT 2007 Stefan O'Rear > * Fix precedence passing for patterns in LamE (fixes \((:) x xs) -> x misprinting) > > Mon Apr 2 08:28:54 PDT 2007 Stefan O'Rear > * Pretty-print an empty list of fundeps without '|' (should fix #1260) I've applied these, and the patches in your other mail, to HEAD and 6.6 branch; thanks! Ian From jyasskin at gmail.com Thu Apr 5 10:06:28 2007 From: jyasskin at gmail.com (Jeffrey Yasskin) Date: Thu Apr 5 10:05:13 2007 Subject: What I learned from my first serious attempt low-level Haskell programming In-Reply-To: References: <20070404231131.GA4967@localhost.localdomain> Message-ID: <5d44f72f0704050706n4840b68ev7a89a5d92366991a@mail.gmail.com> On 4/5/07, Simon Peyton-Jones wrote: > | 6. The inliner is a bit too greedy. Removing the slow-path code from > | singleton doesn't help because popSingleton is only used once; but > | if I explicitly {-# NOINLINE popSingleton #-}, the code for > | singleton itself becomes much smaller, and inlinable (15% perf > | gain). Plus the new singleton doesn't allocate memory, so I can > | use even MORE realWorld#s. > > That's a hard one! Inlining functions that are called just once is a huge win usually. I don't know how to spot what you did in an automated way. > I believe gcc uses __builtin_expect() (http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Other-Builtins.html#index-g_t_005f_005fbuiltin_005fexpect-2393) to let the programmer say that a branch is unlikely to be taken (i.e. is the slow path). If such a thing were available in GHC, Stefan wouldn't even have needed to pull the slow path code from singleton; the compiler could have done it for him. -- Namast?, Jeffrey Yasskin From stefanor at cox.net Thu Apr 5 10:38:42 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Thu Apr 5 10:37:31 2007 Subject: [Haskell-cafe] What I learned from my first serious attempt low-level Haskell programming In-Reply-To: <1722205210.20070405145049@gmail.com> References: <20070404231131.GA4967@localhost.localdomain> <1722205210.20070405145049@gmail.com> Message-ID: <20070405143842.GA3379@localhost.localdomain> On Thu, Apr 05, 2007 at 02:50:49PM +0400, Bulat Ziganshin wrote: > Hello Stefan, > > Thursday, April 5, 2007, 3:11:31 AM, you wrote: > > > 2. Parameters are very expensive. > > you should look at the asm code GHC generates. afair parameters are > kept in stack and copied on each call (to the same place!). such sort > of things are also very dependent on backend used - was it a ASM or C > one? Yes, I will update the wiki. ghc -O2, where stefan@stefans:~$ ghc -V The Glorious Glasgow Haskell Compilation System, version 6.7.20070402 stefan@stefans:~$ uname -a Linux stefans 2.6.18-3-686 #1 SMP Sun Dec 10 19:37:06 UTC 2006 i686 GNU/Linux stefan@stefans:~$ cpuid eax in eax ebx ecx edx 00000000 00000002 756e6547 6c65746e 49656e69 00000001 00000f24 00010809 00000000 3febfbff 00000002 665b5001 00000000 00000000 007b7040 80000000 80000004 00000000 00000000 00000000 80000001 00000000 00000000 00000000 00000000 80000002 20202020 20202020 20202020 6e492020 80000003 286c6574 50202952 69746e65 52286d75 80000004 20342029 20555043 30302e32 007a4847 Vendor ID: "GenuineIntel"; CPUID level 2 Intel-specific functions: Version 00000f24: Type 0 - Original OEM Family 15 - Pentium 4 Extended family 0 Model 2 - Stepping 4 Reserved 0 Brand index: 9 [not in table] Extended brand string: " Intel(R) Pentium(R) 4 CPU 2.00GHz" CLFLUSH instruction cache line size: 8 Hyper threading siblings: 1 Feature flags 3febfbff: FPU Floating Point Unit VME Virtual 8086 Mode Enhancements DE Debugging Extensions PSE Page Size Extensions TSC Time Stamp Counter MSR Model Specific Registers PAE Physical Address Extension MCE Machine Check Exception CX8 COMPXCHG8B Instruction APIC On-chip Advanced Programmable Interrupt Controller present and enabled SEP Fast System Call MTRR Memory Type Range Registers PGE PTE Global Flag MCA Machine Check Architecture CMOV Conditional Move and Compare Instructions FGPAT Page Attribute Table PSE-36 36-bit Page Size Extension CLFSH CFLUSH instruction DS Debug store ACPI Thermal Monitor and Clock Ctrl MMX MMX instruction set FXSR Fast FP/MMX Streaming SIMD Extensions save/restore SSE Streaming SIMD Extensions instruction set SSE2 SSE2 extensions SS Self Snoop HT Hyper Threading TM Thermal monitor TLB and cache info: 50: Instruction TLB: 4KB and 2MB or 4MB pages, 64 entries 5b: Data TLB: 4KB and 4MB pages, 64 entries 66: 1st-level data cache: 8KB, 4-way set assoc, 64 byte line size 40: No 2nd-level cache, or if 2nd-level cache exists, no 3rd-level cache 70: Trace cache: 12K-micro-op, 4-way set assoc 7b: 2nd-level cache: 512KB, 8-way set assoc, sectored, 64 byte line size Stefan From rob at mits.coop Thu Apr 5 11:26:44 2007 From: rob at mits.coop (Robert Marlow) Date: Thu Apr 5 11:25:34 2007 Subject: Proposal: ByteString based datagram communication (Ticket #1238 ) In-Reply-To: <49928550.20070405150822@gmail.com> References: <1174403822.3736.347.camel@localhost> <1175764465.3652.10.camel@localhost> <49928550.20070405150822@gmail.com> Message-ID: <1175786804.3652.58.camel@localhost> Hi Bulat On Thu, 2007-04-05 at 15:08 +0400, Bulat Ziganshin wrote: > but why you provide ByteString-only API?? i think that more common > idiom is to provide String functions here and use somewhat like > Network.ByteString, Network.ByteString.Lazy modules to provide > ByteString/ByteStringLazy equivalents of String function from > Network.hs Mostly because I wanted ByteStrings so that's what I implemented :) Good point though. I've uploaded a replacement patch changing the Network functions to use String and adding Network.ByteString and Network.ByteString.Lazy. Thanks for the suggestion. Ideally it'd be nice if this all used some sort of String typeclass interface. But this should do for now. -- Robert Marlow MITS Co-operative Limited http://www.mits.coop/ From jyasskin at gmail.com Thu Apr 5 12:32:33 2007 From: jyasskin at gmail.com (Jeffrey Yasskin) Date: Thu Apr 5 12:31:18 2007 Subject: Proposal: reduce base from the top In-Reply-To: <46122AAE.7060405@gmail.com> References: <46122AAE.7060405@gmail.com> Message-ID: <5d44f72f0704050932j6a8be1fbxca30626bdb625149@mail.gmail.com> On 4/3/07, Simon Marlow wrote: > Control.Applicative > Data.Foldable, Data.Traversable > Data.Map, Data.IntMap, Data.Set, Data.IntSet > Data.Sequence, Data.Tree > Data.HashTable > Data.Graph > ---> new package collections? containers? or split further? > (dep. on array, generics, concurrent) Applicative seems more related to Functor, Monad, and Arrow than to the collections. Even its haddock page mentions parsers before Traversable. I think Control.Applicative should stay in base or follow Control.Arrow if that moves somewhere else. -- Namast?, Jeffrey Yasskin From bos at serpentine.com Thu Apr 5 13:54:47 2007 From: bos at serpentine.com (Bryan O'Sullivan) Date: Thu Apr 5 13:53:32 2007 Subject: Proposal: ByteString based datagram communication (Ticket #1238 ) In-Reply-To: <1175768581.3652.38.camel@localhost> References: <1174403822.3736.347.camel@localhost> <1175764465.3652.10.camel@localhost> <20070405093222.GB16785@momenergy.repetae.net> <1175768581.3652.38.camel@localhost> Message-ID: <461537E7.2070608@serpentine.com> Robert Marlow wrote: > My knee-jerk opinion is that the current use of HostName and PortID > already assume IPv4 protocols such as TCP and UDP more than they could. They have TCP baked in, but not IPv4. I posted a patch yesterday that generalises the functions in Network to work with IPv6 as well as v4, and it required no API changes. > Consequently, I think making the > Network module more flexible for extension would involve getting rid of > the current addressing scheme and implementing some new Address type > which includes not just the address, but the protocol used. I don't think there's much point in this. The Network module is not especially well put together, but it's at least stable. It would be more profitable to work on the network-alt package or something else instead of trying to remould the existing API, while breaking it in the process. <4614AAD4.5030907@gmail.com> Message-ID: <018601c777ae$b02702f0$103a8351@cr3lt> > Stefan O'Rear wrote: > > 2. Parameters are very expensive. Our type of functions that build > > (ignoring CPS for the time being) was MBA# -> Int# -> [ByteString], > > where the Int# is the current write pointer. Adding an extra Int# > > to cache the size of the array (rather than calling sMBA# each > > time) slowed the code down ~2x. Conversely, moving the write > > pointer into the byte array (storing it in bytes 0#, 1#, 2#, and > > 3#) sped the code by 4x. > > If you were measuring on x86 then parameters are passed on the stack, which may > be expensive. On x86_64 the first 3 arguments are passed in registers, which is > usually a win, but if the function immediately does an eval they need to be > saved on the stack anyway. Still, 4x sounds like a lot, perhaps you managed to > avoid a stack check in the inner loop or something. just out of curiosity: what does GHC do with stack parameters in loops/tail calls? there tends to be a conflict as the old set of parameters is needed to build the new one for the recursive call/next loop iteration, while one wants to get rid of the old set before doing the call. unless one keeps the parameter frames away from the stack, or can figure out a safe order in which to overwrite the parameters in the frame, that seems to imply some copying, even though that may be cheap for few/small parameters per frame. many years ago, i saw an abstract machine and RISC processor design aiming for good fp support that used two parameter stacks instead of one for just this reason. instead of moving stack frames around on a single stack, parameters were read from one stack, and built up on the other, followed by a cheap stack switch before the call. perhaps something like this might be of use here, too? claus From lennart at augustsson.net Thu Apr 5 15:10:11 2007 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Apr 5 15:09:20 2007 Subject: [Haskell-cafe] Re: What I learned from my first serious attempt low-level Haskell programming In-Reply-To: <018601c777ae$b02702f0$103a8351@cr3lt> References: <20070404231131.GA4967@localhost.localdomain> <4614AAD4.5030907@gmail.com> <018601c777ae$b02702f0$103a8351@cr3lt> Message-ID: It's not that hard to figure out an order to permute the arguments on the stack before a tail call that minimizes that number of moves and temporary locations. Lmlc did this 20 years ago. :) -- Lennart On Apr 5, 2007, at 19:17 , Claus Reinke wrote: >> Stefan O'Rear wrote: >> > 2. Parameters are very expensive. Our type of functions that build >> > (ignoring CPS for the time being) was MBA# -> Int# -> >> [ByteString], >> > where the Int# is the current write pointer. Adding an extra >> Int# >> > to cache the size of the array (rather than calling sMBA# each >> > time) slowed the code down ~2x. Conversely, moving the write >> > pointer into the byte array (storing it in bytes 0#, 1#, 2#, and >> > 3#) sped the code by 4x. >> If you were measuring on x86 then parameters are passed on the >> stack, which may be expensive. On x86_64 the first 3 arguments >> are passed in registers, which is usually a win, but if the >> function immediately does an eval they need to be saved on the >> stack anyway. Still, 4x sounds like a lot, perhaps you managed to >> avoid a stack check in the inner loop or something. > > just out of curiosity: what does GHC do with stack parameters in > loops/tail calls? > > there tends to be a conflict as the old set of parameters is needed > to build the new > one for the recursive call/next loop iteration, while one wants to > get rid of the old set before doing the call. unless one keeps the > parameter frames away from the stack, > or can figure out a safe order in which to overwrite the parameters > in the frame, > that seems to imply some copying, even though that may be cheap for > few/small > parameters per frame. > > many years ago, i saw an abstract machine and RISC processor design > aiming for good fp support that used two parameter stacks instead > of one for just this reason. > > instead of moving stack frames around on a single stack, parameters > were read > from one stack, and built up on the other, followed by a cheap > stack switch before > the call. perhaps something like this might be of use here, too? > > claus > > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries From ashley at semantic.org Thu Apr 5 16:52:28 2007 From: ashley at semantic.org (Ashley Yakeley) Date: Thu Apr 5 16:51:30 2007 Subject: Proposal: reduce base from the top In-Reply-To: <5d44f72f0704050932j6a8be1fbxca30626bdb625149@mail.gmail.com> References: <46122AAE.7060405@gmail.com> <5d44f72f0704050932j6a8be1fbxca30626bdb625149@mail.gmail.com> Message-ID: Jeffrey Yasskin wrote: > On 4/3/07, Simon Marlow wrote: >> Control.Applicative >> Data.Foldable, Data.Traversable >> Data.Map, Data.IntMap, Data.Set, Data.IntSet >> Data.Sequence, Data.Tree >> Data.HashTable >> Data.Graph >> ---> new package collections? containers? or split further? >> (dep. on array, generics, concurrent) > > Applicative seems more related to Functor, Monad, and Arrow than to > the collections. Even its haddock page mentions parsers before > Traversable. I think Control.Applicative should stay in base or follow > Control.Arrow if that moves somewhere else. Agreed, and I think Foldable and Traversable too. Also, Monad should one day be a subclass of Applicative, IMO: . The rest are collections or containers. -- Ashley Yakeley From duncan.coutts at worc.ox.ac.uk Thu Apr 5 19:52:51 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Apr 5 19:51:55 2007 Subject: Proposal: ByteString based datagram communication (Ticket #1238 ) In-Reply-To: <1175786804.3652.58.camel@localhost> References: <1174403822.3736.347.camel@localhost> <1175764465.3652.10.camel@localhost> <49928550.20070405150822@gmail.com> <1175786804.3652.58.camel@localhost> Message-ID: <1175817171.28130.29.camel@localhost> On Fri, 2007-04-06 at 00:26 +0900, Robert Marlow wrote: > Hi Bulat > > On Thu, 2007-04-05 at 15:08 +0400, Bulat Ziganshin wrote: > > but why you provide ByteString-only API?? i think that more common > > idiom is to provide String functions here and use somewhat like > > Network.ByteString, Network.ByteString.Lazy modules to provide > > ByteString/ByteStringLazy equivalents of String function from > > Network.hs > > Mostly because I wanted ByteStrings so that's what I implemented :) > > Good point though. I've uploaded a replacement patch changing the > Network functions to use String and adding Network.ByteString and > Network.ByteString.Lazy. Thanks for the suggestion. I'm not sure this really makes sense. In most situations there is an obvious candidate amongst String, strict ByteString and lazy ByteString. In this case, for datagram communication the obvious choice is indeed strict ByteString. Correct me if I'm wrong but datagrams are relatively small contiguous chunks and they arrive in our memory space all in one go. So they are not at all like a continuous stream of data which is what a lazy ByteString models. So there would never be any advantage to using a lazy ByteString in this case, it would always just have one chunk. Similarly, for String, one has to go via a strict contiguous chunk representation in the first place so any String interface would be a trivial wrapper on a ByteString representation. Remember that the types are trivially inter-convertible with a single function call[1]. I'm not sure that we need two whole extra module to replace a single pack/unpack call in a calling module. It's exactly this kind of thing that makes me worry about people creating a Stringlike class. By passing the operations in via a class rather than converting representations on the boundary we are in danger of loosing all the performance benefits we were after in the first place. I'm sure it makes more sense to provide a class to give us a string equivalent of fromIntegral. That way operations that want to provide an api that works on any string can chose the best internal representation and just use the conversion on the boundary. That way we only need to inline the conversion into the calling program to make it fast. As with fromIntegral, that conversion can often be optimised or turned into a no-op. For performance, class dictionary use should be kept as near to the 'surface' as possible. For example, consider this standard List module function: elemIndex :: Eq a => a -> [a] -> Maybe Int elemIndex x = findIndex (x==) This is not a naive definition. It is very cunning. If we wrote a full version of elemIndex in the style of findIndex but using == at the appropriate point then to optimise uses of elemIndex where we know the particular Eq class instance we'd have to inline the whole of elemIndex. This isn't a tiny amount of code and GHC is normally disinclined to do that. So we'd end up passing an Eq dictionary. Disaster! Instead, with the above definition we've lifted the use of the class right to the surface. Now elemIndex looks tiny and ghc will inline it in the calling context where we know the Eq instance. So now we just build a little specialised (x==) function and make a call to the findIndex function. So we get minimal code duplication and pretty fast results. And all this happens without having to bludgeon the compiler with INLINE or SPECIALISE pragmas. In other words it works just fine on ordinary user code. Ok, enough ranting. Duncan [1] Well two to get between strict and lazy bytestrings, but that's kind of deliberate to encourage people to think twice about doing that From jyasskin at gmail.com Thu Apr 5 20:29:23 2007 From: jyasskin at gmail.com (Jeffrey Yasskin) Date: Thu Apr 5 20:28:06 2007 Subject: Proposal: reduce base from the top In-Reply-To: References: <46122AAE.7060405@gmail.com> <5d44f72f0704050932j6a8be1fbxca30626bdb625149@mail.gmail.com> Message-ID: <5d44f72f0704051729u318b2e49qf895085831185a03@mail.gmail.com> On 4/5/07, Ashley Yakeley wrote: > Agreed, and I think Foldable and Traversable too. Anything that's Foldable or Traversable is kind of inherently a collection, so I'd support putting them in the collections package. Or do you know of potential instances that aren't collections? > Also, Monad should one > day be a subclass of Applicative, IMO: > . I agree, but not in this change. ;) -- Namast?, Jeffrey Yasskin From rob at mits.coop Thu Apr 5 20:41:57 2007 From: rob at mits.coop (Robert Marlow) Date: Thu Apr 5 20:41:00 2007 Subject: Proposal: ByteString based datagram communication (Ticket #1238 ) In-Reply-To: <1175817171.28130.29.camel@localhost> References: <1174403822.3736.347.camel@localhost> <1175764465.3652.10.camel@localhost> <49928550.20070405150822@gmail.com> <1175786804.3652.58.camel@localhost> <1175817171.28130.29.camel@localhost> Message-ID: <1175820118.3652.74.camel@localhost> I suspected in my sleepy state last night that overwriting all instances of my original patch with this new one would probably come back to bite me. I probably shouldn't have ignored that gut instinct. Thanks for the rant, Duncan. That clears up a bunch of things for me regarding how ByteStrings are intended to be used. I had written the original patch with lazy bytestrings because I had integration with Data.Binary in mind and wanted to make it as simple for that as possible. But I do see the merit in your argument for just using strict ByteStrings; it didn't feel quite right making trivial conversions between strict and lazy bytestrings when I was doing it. So then. If I revert to a patch similar to the one I originally had only using strict ByteStrings would it raise any further concerns (besides out-of-scope concerns such as a nice coherent string class interface). -- Robert Marlow MITS Co-operative Limited http://www.mits.coop/ From ndmitchell at gmail.com Fri Apr 6 05:55:02 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri Apr 6 05:53:44 2007 Subject: openTempFile only defined on GHC In-Reply-To: <4610FDEE.9060405@gmail.com> References: <404396ef0703311051p29bc4088ga8f866ca7f6e3221@mail.gmail.com> <4610D817.3030308@gmail.com> <20070402132003.51fd2533.Malcolm.Wallace@cs.york.ac.uk> <4610FDEE.9060405@gmail.com> Message-ID: <404396ef0704060255y2acd6478tb9fd27c711c0f819@mail.gmail.com> Hi > Perhaps as a first step, rather than just omitting them from the export list > where they aren't supported, they should be replaced by dummy definitions that > emit a helpful error message? Like canonicalizeFilePath, which has a dummy implementation everywhere? It's frustrating to have a standard base library which isn't standard and portable. I realise that the reason that this was added was for race-free temporary file creation, but until they are available on Hugs, my code will use a race-full implementation everywhere, including GHC. Could we perhaps have an implementation of this function for all other compilers: -- Note: openTempFile is not available on Hugs, which sucks openTempFileLocal :: FilePath -> String -> IO (FilePath, Handle) openTempFileLocal dir template = do i <- randomRIO (1000::Int,9999) let (file,ext) = splitExtension template s = dir (file ++ show i) <.> ext b <- doesFileExist s if b then openTempFileLocal dir template else do h <- openFile s ReadWriteMode return (s, h) That's what I use everywhere. > I suspect there are many such examples in the base package, FWIW. nch98 doesn't > implement various bits of System.IO.Error, for example. Hugs has a very > different version of Control.Concurrent. I think these should be made very explicit in the documentation. Control.Concurrent is understandable, things like file creation methods aren't - a user will be annoyed (and I was) to find that their program written according to the documentation doesn't work. Thanks Neil From bulat.ziganshin at gmail.com Fri Apr 6 10:28:47 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Apr 6 10:30:12 2007 Subject: Proposal: ByteString based datagram communication (Ticket #1238 ) In-Reply-To: <1175817171.28130.29.camel@localhost> References: <1174403822.3736.347.camel@localhost> <1175764465.3652.10.camel@localhost> <49928550.20070405150822@gmail.com> <1175786804.3652.58.camel@localhost> <1175817171.28130.29.camel@localhost> Message-ID: <509471711.20070406182847@gmail.com> Hello Duncan, Friday, April 6, 2007, 3:52:51 AM, you wrote: > In most situations there is an obvious candidate amongst String, strict > ByteString and lazy ByteString. In this case, for datagram communication > the obvious choice is indeed strict ByteString. you see from the POV of *implementor* and for this case you are probably perfectly right. but from POV of user, in most cases, speed doesn't matter and i want to use just the types what are most convenient for me. if i work with strings here, i want to be able to get strings from any sources and send strings to any receivers. learning which libs provide string api, which ByteString one and so on is not interesting, adding conversions between all those types clutters the code it seems easier for me to just import Network if i want to use standard string type, or Network.ByteString which, i know, provides exactly the same operations, only on ByteStrings instead of memoizing which operations was easier to implement in which type due to some internal reasons just imagine that we got to exclude concat :: [ByteString] -> ByteString operation because it's natural return type is lazy ByteString so for me the best variant is to *implement* these operations using strict ByteStrings and provide wrappers which deal with other types automatic conversion of arguments and results using typeclass is really bad idea, i agree/ may be, it would become better with some kind of defaulting, where, say, lazy UTF8-encoded FPS will be default type for such class -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From rob at mits.coop Fri Apr 6 21:35:36 2007 From: rob at mits.coop (Robert Marlow) Date: Fri Apr 6 21:34:24 2007 Subject: Proposal: ByteString based datagram communication (Ticket #1238 ) In-Reply-To: <509471711.20070406182847@gmail.com> References: <1174403822.3736.347.camel@localhost> <1175764465.3652.10.camel@localhost> <49928550.20070405150822@gmail.com> <1175786804.3652.58.camel@localhost> <1175817171.28130.29.camel@localhost> <509471711.20070406182847@gmail.com> Message-ID: <1175909736.3652.121.camel@localhost> I see your point, but if we extend this line of reasoning, every time a new String-based API is created, the author may be looking at having to provide 3-5 separate APIs to handle all the (current) String types available. I think Duncan's proposal of a solution analogous to fromIntegral is correct. Your arguments are applicable to APIs which use Int rather than Integer as a datatype. We don't provide Data.List.Integer for Integer based indexing because we have a simple conversion mechanism in fromIntegral. Likewise, I think the solution for simplifying String interfaces is to provide some sort of convertString utility (such as http://hpaste.org/1276 ). With convertString anybody who wants a String or lazy ByteString interface to Network can simply write their own wrappers using that utility without too much difficulty. As can be seen in the current patch, even without convertString, the wrappers are fairly trivial. Such trivial wrappers don't really warrant cluttering the API so much. On Fri, 2007-04-06 at 18:28 +0400, Bulat Ziganshin wrote: > you see from the POV of *implementor* and for this case you are > probably perfectly right. but from POV of user, in most cases, speed > doesn't matter and i want to use just the types what are most > convenient for me. if i work with strings here, i want to be able to > get strings from any sources and send strings to any receivers. > learning which libs provide string api, which ByteString one and so on > is not interesting, adding conversions between all those types > clutters the code > > it seems easier for me to just import Network if i want to use > standard string type, or Network.ByteString which, i know, provides > exactly the same operations, only on ByteStrings instead of memoizing > which operations was easier to implement in which type due to some > internal reasons > > just imagine that we got to exclude concat :: [ByteString] -> ByteString > operation because it's natural return type is lazy ByteString > > so for me the best variant is to *implement* these operations using > strict ByteStrings and provide wrappers which deal with other types > > automatic conversion of arguments and results using typeclass is > really bad idea, i agree/ may be, it would become better with some > kind of defaulting, where, say, lazy UTF8-encoded FPS will be default > type for such class > -- Robert Marlow MITS Co-operative Limited http://www.mits.coop/ From rob at mits.coop Fri Apr 6 22:26:39 2007 From: rob at mits.coop (Robert Marlow) Date: Fri Apr 6 22:25:22 2007 Subject: Proposal: ByteString based datagram communication (Ticket #1238 ) In-Reply-To: <1174403822.3736.347.camel@localhost> References: <1174403822.3736.347.camel@localhost> Message-ID: <1175912799.3652.123.camel@localhost> I've reverted this patch to be similar to the original one posted (ie, with just Network instead of Network.ByteString*) only using strict ByteStrings instead of lazy ones. Any further concerns about this patch? -- Robert Marlow MITS Co-operative Limited http://www.mits.coop/ From rob at mits.coop Fri Apr 6 22:40:54 2007 From: rob at mits.coop (Robert Marlow) Date: Fri Apr 6 22:39:36 2007 Subject: Proposal: ByteString based datagram communication (Ticket #1238 ) In-Reply-To: <1175909736.3652.121.camel@localhost> References: <1174403822.3736.347.camel@localhost> <1175764465.3652.10.camel@localhost> <49928550.20070405150822@gmail.com> <1175786804.3652.58.camel@localhost> <1175817171.28130.29.camel@localhost> <509471711.20070406182847@gmail.com> <1175909736.3652.121.camel@localhost> Message-ID: <1175913654.3652.131.camel@localhost> Disclaimer: I'm not trying to raise convertString as a potential patch right now. I mention it merely to indicate that a convenient interface for Network belongs in a more general string solution and is outside the scope of this patch. On Sat, 2007-04-07 at 10:35 +0900, Robert Marlow wrote: > Likewise, I think the solution for simplifying String > interfaces is to provide some sort of convertString utility (such as > http://hpaste.org/1276 ). > > With convertString anybody who wants a String or lazy ByteString > interface to Network can simply write their own wrappers using that > utility without too much difficulty. -- Robert Marlow MITS Co-operative Limited http://www.mits.coop/ From igloo at earth.li Sat Apr 7 11:57:11 2007 From: igloo at earth.li (Ian Lynagh) Date: Sat Apr 7 11:55:51 2007 Subject: Proposal [Trac #1212]: add IPv6 support to network library In-Reply-To: <46142A48.7010900@serpentine.com> References: <45F268D0.8090504@serpentine.com> <200704011250.11061.sven.panne@aedion.de> <4611FFDE.3010206@serpentine.com> <200704031052.04743.sven.panne@aedion.de> <46142A48.7010900@serpentine.com> Message-ID: <20070407155711.GA29937@matrix.chaos.earth.li> Just a little nit: On Wed, Apr 04, 2007 at 03:44:24PM -0700, Bryan O'Sullivan wrote: > hunk ./Network.hs 1 > -{-# OPTIONS_GHC -cpp #-} > +{-# OPTIONS -cpp #-} http://www.haskell.org/ghc/docs/latest/html/users_guide/pragmas.html#options-pragma says: Previous versions of GHC accepted OPTIONS rather than OPTIONS_GHC, but that is now deprecated. and hugs (for one, not sure about other impls) doesn't support -cpp. I think {-# LANGUAGE CPP #-} is the prefered way of doing this. Thanks Ian From dominic.steinitz at blueyonder.co.uk Sat Apr 7 14:17:56 2007 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Sat Apr 7 14:28:20 2007 Subject: ANN: Haskell Cryptographic Library 4.0.3 Message-ID: <200704071917.57214.dominic.steinitz@blueyonder.co.uk> I should like to announce the release of a new version of the Haskell Cryptographic Library based on the proposal at http://www.haskell.org/haskellwiki/Crypto_Library_Proposal. See http://www.haskell.org/crypto/ for more details. There is now no dependency on NewBinary. The downside is the library contains no support for ASN.1 which will be released in separate package. Dominic. From bos at serpentine.com Sat Apr 7 19:52:33 2007 From: bos at serpentine.com (Bryan O'Sullivan) Date: Sat Apr 7 19:51:10 2007 Subject: Proposal [Trac #1212]: add IPv6 support to network library In-Reply-To: <20070407155711.GA29937@matrix.chaos.earth.li> References: <45F268D0.8090504@serpentine.com> <200704011250.11061.sven.panne@aedion.de> <4611FFDE.3010206@serpentine.com> <200704031052.04743.sven.panne@aedion.de> <46142A48.7010900@serpentine.com> <20070407155711.GA29937@matrix.chaos.earth.li> Message-ID: <46182EC1.9040807@serpentine.com> Ian Lynagh wrote: > > I think > > {-# LANGUAGE CPP #-} > > is the prefered way of doing this. Wonderful, thank you. References: <1174403822.3736.347.camel@localhost> <1175764465.3652.10.camel@localhost> <20070405092624.GA5420@soi.city.ac.uk> <1175767044.3652.18.camel@localhost> <20070405104710.GB5420@soi.city.ac.uk> Message-ID: <1176118627.3652.196.camel@localhost> Ok, I seem to have managed to get hugs to install the network library. Ross: thanks, it was indeed a pre-packaged version (for debian). Compiling hugs from scratch seemed to help. I've now tested the patch against hugs and can confirm its compatibility. For windows I've only managed to get as far as confirming compilation. -- Robert Marlow MITS Co-operative Limited http://www.mits.coop/ From simonmarhaskell at gmail.com Tue Apr 10 05:17:22 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Apr 10 05:15:55 2007 Subject: What I learned from my first serious attempt low-level Haskell programming In-Reply-To: References: <20070404231131.GA4967@localhost.localdomain> <4614AAD4.5030907@gmail.com> <018601c777ae$b02702f0$103a8351@cr3lt> Message-ID: <461B5622.4030709@microsoft.com> Lennart Augustsson wrote: > It's not that hard to figure out an order to permute the arguments on > the stack before a tail call that minimizes that number of moves and > temporary locations. Lmlc did this 20 years ago. :) Right, and that's what GHC does too, with a strongly-connected-component analysis of the dependencies between assignments of the args for the tail call. Cheers, Simon From simonmarhaskell at gmail.com Tue Apr 10 06:13:10 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Apr 10 06:11:42 2007 Subject: openTempFile only defined on GHC In-Reply-To: <404396ef0704060255y2acd6478tb9fd27c711c0f819@mail.gmail.com> References: <404396ef0703311051p29bc4088ga8f866ca7f6e3221@mail.gmail.com> <4610D817.3030308@gmail.com> <20070402132003.51fd2533.Malcolm.Wallace@cs.york.ac.uk> <4610FDEE.9060405@gmail.com> <404396ef0704060255y2acd6478tb9fd27c711c0f819@mail.gmail.com> Message-ID: <461B6336.2080508@gmail.com> Neil Mitchell wrote: > Hi > >> Perhaps as a first step, rather than just omitting them from the >> export list >> where they aren't supported, they should be replaced by dummy >> definitions that >> emit a helpful error message? > > Like canonicalizeFilePath, which has a dummy implementation > everywhere? It's frustrating to have a standard base library which > isn't standard and portable. I realise that the reason that this was > added was for race-free temporary file creation, but until they are > available on Hugs, my code will use a race-full implementation > everywhere, including GHC. > > Could we perhaps have an implementation of this function for all other > compilers: > > -- Note: openTempFile is not available on Hugs, which sucks > openTempFileLocal :: FilePath -> String -> IO (FilePath, Handle) > openTempFileLocal dir template = do > i <- randomRIO (1000::Int,9999) > let (file,ext) = splitExtension template > s = dir (file ++ show i) <.> ext > b <- doesFileExist s > if b then openTempFileLocal dir template else do > h <- openFile s ReadWriteMode > return (s, h) > > That's what I use everywhere. What does the "local" in openTempFileLocal mean? I'd be perfectly happy to have non-race-free implementations of openTempFile for certain compilers/platforms as long as we document it (not that we document openTempFile properly at all at the moment, which is a bug). Also note that you can't use or <.> here, because filepath is not in base :-) >> I suspect there are many such examples in the base package, FWIW. >> nch98 doesn't >> implement various bits of System.IO.Error, for example. Hugs has a very >> different version of Control.Concurrent. > > I think these should be made very explicit in the documentation. > Control.Concurrent is understandable, things like file creation > methods aren't - a user will be annoyed (and I was) to find that their > program written according to the documentation doesn't work. I quite agree. Care to send a patch, or open a ticket? Cheers, Simon From ndmitchell at gmail.com Tue Apr 10 06:38:12 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Apr 10 06:36:41 2007 Subject: openTempFile only defined on GHC In-Reply-To: <461B6336.2080508@gmail.com> References: <404396ef0703311051p29bc4088ga8f866ca7f6e3221@mail.gmail.com> <4610D817.3030308@gmail.com> <20070402132003.51fd2533.Malcolm.Wallace@cs.york.ac.uk> <4610FDEE.9060405@gmail.com> <404396ef0704060255y2acd6478tb9fd27c711c0f819@mail.gmail.com> <461B6336.2080508@gmail.com> Message-ID: <404396ef0704100338r7d01ee40i2d5cd3b918384aca@mail.gmail.com> Hi > What does the "local" in openTempFileLocal mean? Do not conflict with the name openTempFile - a copy local to this project - no real mean