From ketil+haskell at ii.uib.no Fri Feb 1 02:52:02 2008 From: ketil+haskell at ii.uib.no (Ketil Malde) Date: Fri Feb 1 02:51:28 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <1508723353.20080131161308@gmail.com> (Bulat Ziganshin's message of "Thu\, 31 Jan 2008 16\:13\:08 +0300") References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> <20080129175243.GA18863@scytale.galois.com> <479F6CBD.3090009@imn.htwk-leipzig.de> <259254796.20080129225150@gmail.com> <47A1ADEE.80407@gmail.com> <90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com> <1508723353.20080131161308@gmail.com> Message-ID: <87r6fxazbx.fsf@nmd9999.imr.no> Bulat Ziganshin writes: Bulat Ziganshin writes: > the right way to deal with [text encoding] "modifiers" is to attach > them to the Handle itself like this: > > f <- openFile "name" >>= withLocking >>= withEncoding utf8 This is nice! I think the Haskell Way of interpreting bytes as Latin-1 - while unfortunate in today's multi-everything environment - is something we just have to live with. Too much code expects this behavior, and too many tasks require just reading ASCII to be burdened with complications of locales and character sets. Attaching modifiers to handles appears to solve the problem of retaining 100% backwards compatibility, while opening for dealing with modern character sets. Somebody raised the question of reading a Content-type field, etc: would it be possible to "rewind" a handle after setting encoding? For Content-type fields, I suspect the header is usually limited to ASCII anyway, so adding decoding for subsequent text is probably sufficient. But how about a 'withDefaultEncoding' modifier that inspects the first two (or four?) bytes for a Unicode BOM, and either sets decoding accordingly and continues, or sets encoding according to locale *and* lets the user read the first bytes when reading from the handle. -k -- If I haven't seen further, it is by standing in the footprints of giants From rl at cse.unsw.edu.au Fri Feb 1 03:03:36 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Fri Feb 1 03:02:57 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <1508723353.20080131161308@gmail.com> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> <20080129175243.GA18863@scytale.galois.com> <479F6CBD.3090009@imn.htwk-leipzig.de> <259254796.20080129225150@gmail.com> <47A1ADEE.80407@gmail.com> <90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com> <1508723353.20080131161308@gmail.com> Message-ID: <47A2D258.7050704@cse.unsw.edu.au> Bulat Ziganshin wrote: > > the right way to deal with "modifiers" is to attach them to the Handle > itself like this: > > f <- openFile "name" >>= withLocking >>= withEncoding utf8 IMO, global state is never "the right way" if it can be avoided. It will always lead to problems. Especially in a functional language like Haskell. Roman From johan.tibell at gmail.com Fri Feb 1 03:56:09 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri Feb 1 03:55:23 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <87r6fxazbx.fsf@nmd9999.imr.no> References: <478B90A4.4090807@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> <20080129175243.GA18863@scytale.galois.com> <479F6CBD.3090009@imn.htwk-leipzig.de> <259254796.20080129225150@gmail.com> <47A1ADEE.80407@gmail.com> <90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com> <1508723353.20080131161308@gmail.com> <87r6fxazbx.fsf@nmd9999.imr.no> Message-ID: <90889fe70802010056n48f9250eo579137c0542a05d7@mail.gmail.com> > I think the Haskell Way of interpreting bytes as Latin-1 - while > unfortunate in today's multi-everything environment - is something we > just have to live with. Too much code expects this behavior, and too > many tasks require just reading ASCII to be burdened with > complications of locales and character sets. Why do we have to live with it? I understand why we ended up with the situation we have today. Most languages have/had the same problem. It's being fixed in other languages like Python. Not fixing it makes it a huge pain to deal with Strings from different sources (e.g. libraries) since you don't know if the content is Unicode code points (which String is defined as containing) or raw bytes because the programmer used the wrong type. > .... But how about a 'withDefaultEncoding' modifier that > inspects the first two (or four?) bytes for a Unicode BOM, and either > sets decoding accordingly and continues, or sets encoding according > to locale *and* lets the user read the first bytes when reading from > the handle. The BOM mark is not always present and is not enough to decide which encoding was used. You could invent and encoding of Unicode that doesn't use one. Some recommended reading (for everyone): http://www.joelonsoftware.com/articles/Unicode.html -- Johan From wnoise at ofb.net Fri Feb 1 04:01:24 2008 From: wnoise at ofb.net (Aaron Denney) Date: Fri Feb 1 04:00:56 2008 Subject: Proposal: Add concatMapM function (#2042) References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> <20080129175243.GA18863@scytale.galois.com> <479F6CBD.3090009@imn.htwk-leipzig.de> <259254796.20080129225150@gmail.com> <47A1ADEE.80407@gmail.com> <90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com> <1508723353.20080131161308@gmail.com> <47A2D258.7050704@cse.unsw.edu.au> Message-ID: On 2008-02-01, Roman Leshchinskiy wrote: > Bulat Ziganshin wrote: >> >> the right way to deal with "modifiers" is to attach them to the Handle >> itself like this: >> >> f <- openFile "name" >>= withLocking >>= withEncoding utf8 > > IMO, global state is never "the right way" if it can be avoided. It will > always lead to problems. Especially in a functional language like Haskell. This isn't global state, but local to the handle, and only affects where the handle is passed in. It's just extending an opaque data type. -- Aaron Denney -><- From Alistair_Bayley at invescoperpetual.co.uk Fri Feb 1 04:16:47 2008 From: Alistair_Bayley at invescoperpetual.co.uk (Bayley, Alistair) Date: Fri Feb 1 04:16:42 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <87r6fxazbx.fsf@nmd9999.imr.no> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com><404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com><20080129175243.GA18863@scytale.galois.com><479F6CBD.3090009@imn.htwk-leipzig.de><259254796.20080129225150@gmail.com> <47A1ADEE.80407@gmail.com><90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com><1508723353.20080131161308@gmail.com> <87r6fxazbx.fsf@nmd9999.imr.no> Message-ID: <125EACD0CAE4D24ABDB4D148C4593DA9049E9277@GBLONXMB02.corp.amvescap.net> > From: libraries-bounces@haskell.org > [mailto:libraries-bounces@haskell.org] On Behalf Of Ketil Malde > > Somebody raised the question of reading a Content-type field, etc: > would it be possible to "rewind" a handle after setting encoding? For > Content-type fields, I suspect the header is usually limited to ASCII > anyway, so adding decoding for subsequent text is probably > sufficient. I think this is relevant: http://www.haskell.org/pipermail/haskell-cafe/2004-September/006801.html Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ***************************************************************** From rl at cse.unsw.edu.au Fri Feb 1 04:44:06 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Fri Feb 1 04:43:26 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> <20080129175243.GA18863@scytale.galois.com> <479F6CBD.3090009@imn.htwk-leipzig.de> <259254796.20080129225150@gmail.com> <47A1ADEE.80407@gmail.com> <90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com> <1508723353.20080131161308@gmail.com> <47A2D258.7050704@cse.unsw.edu.au> Message-ID: <47A2E9E6.6070208@cse.unsw.edu.au> Aaron Denney wrote: > On 2008-02-01, Roman Leshchinskiy wrote: >> Bulat Ziganshin wrote: >>> the right way to deal with "modifiers" is to attach them to the Handle >>> itself like this: >>> >>> f <- openFile "name" >>= withLocking >>= withEncoding utf8 >> IMO, global state is never "the right way" if it can be avoided. It will >> always lead to problems. Especially in a functional language like Haskell. > > This isn't global state, but local to the handle, and only affects where > the handle is passed in. It's just extending an opaque data type. If I can destructively change the encoding assocated with a Handle, then it's global state. Roman From simonmarhaskell at gmail.com Fri Feb 1 05:31:37 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri Feb 1 05:31:00 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <125EACD0CAE4D24ABDB4D148C4593DA9049E9277@GBLONXMB02.corp.amvescap.net> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com><404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com><20080129175243.GA18863@scytale.galois.com><479F6CBD.3090009@imn.htwk-leipzig.de><259254796.20080129225150@gmail.com> <47A1ADEE.80407@gmail.com><90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com><1508723353.20080131161308@gmail.com> <87r6fxazbx.fsf@nmd9999.imr.no> <125EACD0CAE4D24ABDB4D148C4593DA9049E9277@GBLONXMB02.corp.amvescap.net> Message-ID: <47A2F509.9020706@gmail.com> Bayley, Alistair wrote: >> From: libraries-bounces@haskell.org >> [mailto:libraries-bounces@haskell.org] On Behalf Of Ketil Malde >> >> Somebody raised the question of reading a Content-type field, etc: >> would it be possible to "rewind" a handle after setting encoding? For >> Content-type fields, I suspect the header is usually limited to ASCII >> anyway, so adding decoding for subsequent text is probably >> sufficient. > > > I think this is relevant: > > http://www.haskell.org/pipermail/haskell-cafe/2004-September/006801.html We've talked a lot in the past about a stream-layering IO abstraction. I'd forgotten about Oleg's post, thanks. Here are some others. There's the prototype I worked on: http://www.haskell.org/~simonmar/io/System.IO.html There's Bulat's Stream library, which is pretty complete: http://haskell.org/haskellwiki/Library/Streams And Takano Akio's version, in which he divides the type classes into smaller pieces. This is closer to the direction I thought we should go: http://yogimo.sakura.ne.jp/ssc/ Right now though, I'm not sure all this is going in the right direction. Dealing with all those mutable buffers is quite a headache (for the library writer, not the user), and lazy bytestrings have shown us that there are simpler ways to get good I/O performance. What's more, as Duncan Coutts has pointed out to me on more than one occasion, it's much easier to layer streams when the streams are lazy lists. As much as I hate to say it, there's a lot to be said for lazy I/O in this respect. However, lazy I/O has other problems - deterministically catching errors, unpredictable resource usage, unpredictable interaction with other I/O, and so on. Is there a nice solution? Something else we might look at is Oleg's left folds: http://okmij.org/ftp/Haskell/#fold-stream http://www.haskell.org/pipermail/haskell/2003-September/012741.html Cheers, Simon From bulat.ziganshin at gmail.com Fri Feb 1 05:34:28 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Feb 1 05:34:56 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <47A2D258.7050704@cse.unsw.edu.au> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> <20080129175243.GA18863@scytale.galois.com> <479F6CBD.3090009@imn.htwk-leipzig.de> <259254796.20080129225150@gmail.com> <47A1ADEE.80407@gmail.com> <90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com> <1508723353.20080131161308@gmail.com> <47A2D258.7050704@cse.unsw.edu.au> Message-ID: <4410520824.20080201133428@gmail.com> Hello Roman, Friday, February 1, 2008, 11:03:36 AM, you wrote: >> the right way to deal with "modifiers" is to attach them to the Handle >> itself like this: >> >> f <- openFile "name" >>= withLocking >>= withEncoding utf8 > IMO, global state is never "the right way" if it can be avoided. It will > always lead to problems. Especially in a functional language like Haskell. so you propose something like this: s <- readString "/path/filename" TextMode "utf8" line_num ? :) please read http://haskell.org/haskellwiki/Library/Streams - it's not what you have imagined reading this example -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From simonmarhaskell at gmail.com Fri Feb 1 05:46:33 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri Feb 1 05:45:51 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <47A2F509.9020706@gmail.com> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com><404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com><20080129175243.GA18863@scytale.galois.com><479F6CBD.3090009@imn.htwk-leipzig.de><259254796.20080129225150@gmail.com> <47A1ADEE.80407@gmail.com><90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com><1508723353.20080131161308@gmail.com> <87r6fxazbx.fsf@nmd9999.imr.no> <125EACD0CAE4D24ABDB4D148C4593DA9049E9277@GBLONXMB02.corp.amvescap.net> <47A2F509.9020706@gmail.com> Message-ID: <47A2F889.7000107@gmail.com> Simon Marlow wrote: > Bayley, Alistair wrote: >>> From: libraries-bounces@haskell.org >>> [mailto:libraries-bounces@haskell.org] On Behalf Of Ketil Malde >>> >>> Somebody raised the question of reading a Content-type field, etc: >>> would it be possible to "rewind" a handle after setting encoding? For >>> Content-type fields, I suspect the header is usually limited to ASCII >>> anyway, so adding decoding for subsequent text is probably >>> sufficient. >> >> >> I think this is relevant: >> >> http://www.haskell.org/pipermail/haskell-cafe/2004-September/006801.html > > We've talked a lot in the past about a stream-layering IO abstraction. > I'd forgotten about Oleg's post, thanks. > > Here are some others. There's the prototype I worked on: > > http://www.haskell.org/~simonmar/io/System.IO.html > > There's Bulat's Stream library, which is pretty complete: > > http://haskell.org/haskellwiki/Library/Streams > > And Takano Akio's version, in which he divides the type classes into > smaller pieces. This is closer to the direction I thought we should go: > > http://yogimo.sakura.ne.jp/ssc/ I should also mention John Goerzen's HVIO library: http://hackage.haskell.org/packages/archive/MissingH/1.0.0/doc/html/System-IO-HVIO.html Cheers, Simon From johan.tibell at gmail.com Fri Feb 1 06:08:26 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri Feb 1 06:07:41 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <47A2F509.9020706@gmail.com> References: <478B90A4.4090807@gmail.com> <479F6CBD.3090009@imn.htwk-leipzig.de> <259254796.20080129225150@gmail.com> <47A1ADEE.80407@gmail.com> <90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com> <1508723353.20080131161308@gmail.com> <87r6fxazbx.fsf@nmd9999.imr.no> <125EACD0CAE4D24ABDB4D148C4593DA9049E9277@GBLONXMB02.corp.amvescap.net> <47A2F509.9020706@gmail.com> Message-ID: <90889fe70802010308i1a906087q3d3106197e877456@mail.gmail.com> > Right now though, I'm not sure all this is going in the right direction. > Dealing with all those mutable buffers is quite a headache (for the library > writer, not the user), and lazy bytestrings have shown us that there are > simpler ways to get good I/O performance. What's more, as Duncan Coutts > has pointed out to me on more than one occasion, it's much easier to layer > streams when the streams are lazy lists. As much as I hate to say it, > there's a lot to be said for lazy I/O in this respect. However, lazy I/O > has other problems - deterministically catching errors, unpredictable > resource usage, unpredictable interaction with other I/O, and so on. Is > there a nice solution? Something else we might look at is Oleg's left folds: > > http://okmij.org/ftp/Haskell/#fold-stream > http://www.haskell.org/pipermail/haskell/2003-September/012741.html I initially used lazy I/O with lazy bytestrings in my web server but I'm changing that behvior to use left folds instead precisely because of the reasons you (and Oleg) mentioned. Unfortunately, that means I need a incremental Parsec for bytestrings (I think) so there's yet another library to write. Oh well. :) -- Johan From bulat.ziganshin at gmail.com Fri Feb 1 06:02:25 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Feb 1 06:27:11 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <47A2F509.9020706@gmail.com> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com><404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com><20080129175243.GA18863@scytale.galois.com><479F6CBD.3090009@imn.htwk-leipzig.de><259254796.20080129225150@gmail.com> <47A1ADEE.80407@gmail.com><90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com><1508723353.20080131161308@gmail.com> <87r6fxazbx.fsf@nmd9999.imr.no> <125EACD0CAE4D24ABDB4D148C4593DA9049E9277@GBLONXMB02.corp.amvescap.net> <47A2F509.9020706@gmail.com> Message-ID: <18410652986.20080201140225@gmail.com> Hello Simon, Friday, February 1, 2008, 1:31:37 PM, you wrote: > Right now though, I'm not sure all this is going in the right direction. > Dealing with all those mutable buffers is quite a headache (for the library > writer, not the user), and lazy bytestrings have shown us that there are > simpler ways to get good I/O performance. What's more, as Duncan Coutts > has pointed out to me on more than one occasion, it's much easier to layer > streams when the streams are lazy lists. As much as I hate to say it, > there's a lot to be said for lazy I/O in this respect. However, lazy I/O > has other problems - deterministically catching errors, unpredictable > resource usage, unpredictable interaction with other I/O, and so on. also add lack of multithreading/locking support and questionable interaction with C libs. i still think that the proper solution is to provide imperative i/o library as the basis and build lazy bytestring one on the top of it. most users will use high-level library unfortunately, BS and Streams libs were never integrated together -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Fri Feb 1 06:11:00 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Feb 1 06:27:22 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <90889fe70802010056n48f9250eo579137c0542a05d7@mail.gmail.com> References: <478B90A4.4090807@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> <20080129175243.GA18863@scytale.galois.com> <479F6CBD.3090009@imn.htwk-leipzig.de> <259254796.20080129225150@gmail.com> <47A1ADEE.80407@gmail.com> <90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com> <1508723353.20080131161308@gmail.com> <87r6fxazbx.fsf@nmd9999.imr.no> <90889fe70802010056n48f9250eo579137c0542a05d7@mail.gmail.com> Message-ID: <19210299389.20080201141100@gmail.com> Hello Johan, Friday, February 1, 2008, 11:56:09 AM, you wrote: >> I think the Haskell Way of interpreting bytes as Latin-1 - while >> unfortunate in today's multi-everything environment - is something we >> just have to live with. Too much code expects this behavior, and too >> many tasks require just reading ASCII to be burdened with >> complications of locales and character sets. > Why do we have to live with it? I understand why we ended up with the > situation we have today. Most languages have/had the same problem. the problem is just over-complication of existing Handle implementation - it's about 2kloc of high-messed code. taking into account that it lacks a lot of other required features, it's quite meaningless to spend a lot of time fixing it for just one particular problem i've implemented 2 versions of Streams library which includes everything i know about i/o (i.e. no networking, overlapped i/o or iconv) and started to implement its 3rd version which includes bytestring i/o but then switched to more interesting project. Streams is still the most complete haskell i/o library and quite useful. its main drawback is lack of docs, especially for second version, but to some degree you can understand it just by analogy with System.IO interfaces -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Fri Feb 1 06:25:52 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Feb 1 06:27:32 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <87r6fxazbx.fsf@nmd9999.imr.no> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> <20080129175243.GA18863@scytale.galois.com> <479F6CBD.3090009@imn.htwk-leipzig.de> <259254796.20080129225150@gmail.com> <47A1ADEE.80407@gmail.com> <90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com> <1508723353.20080131161308@gmail.com> <87r6fxazbx.fsf@nmd9999.imr.no> Message-ID: <428207430.20080201142552@gmail.com> Hello Ketil, Friday, February 1, 2008, 10:52:02 AM, you wrote: >> f <- openFile "name" >>= withLocking >>= withEncoding utf8 > Attaching modifiers to handles appears to solve the problem of > retaining 100% backwards compatibility, while opening for dealing with > modern character sets. may be it's too draconian restriction but i proposed just to use new library in the new code. we can provide easy way to switch from Handles by providing emulation module System.Stream.IO which exports things with the old names - Handle, hGetContents... - but new implementation > Somebody raised the question of reading a Content-type field, etc: > would it be possible to "rewind" a handle after setting encoding? For > Content-type fields, I suspect the header is usually limited to ASCII > anyway, so adding decoding for subsequent text is probably > sufficient. But how about a 'withDefaultEncoding' modifier that > inspects the first two (or four?) bytes for a Unicode BOM, and either > sets decoding accordingly and continues, or sets encoding according > to locale *and* lets the user read the first bytes when reading from > the handle. core of my library is *interfaces*, not implementations. openFile provides a getByte/putByte interfaces and also trivial getChar/putChar which just reads/writes one byte. withEncoding modifier provides another getChar/putChar implementations what process several bytes at once. you can dress file to one or another modifier at any moment, its internal read/write pointer isn't affected: f <- openFile "name" content <- readLine f -- read first line using Latin-1 f' <- withEncoding (lookup content) f str <- readLine f' -- read second line using encoding given on first line -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Fri Feb 1 06:30:56 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Feb 1 06:31:25 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <47A2F889.7000107@gmail.com> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com><404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com><20080129175243.GA18863@scytale.galois.com><479F6CBD.3090009@imn.htwk-leipzig.de><259254796.20080129225150@gmail.com> <47A1ADEE.80407@gmail.com><90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com><1508723353.20080131161308@gmail.com> <87r6fxazbx.fsf@nmd9999.imr.no> <125EACD0CAE4D24ABDB4D148C4593DA9049E9277@GBLONXMB02.corp.amvescap.net> <47A2F509.9020706@gmail.com> <47A2F889.7000107@gmail.com> Message-ID: <153911645.20080201143056@gmail.com> Hello Simon, Friday, February 1, 2008, 1:46:33 PM, you wrote: >> We've talked a lot in the past about a stream-layering IO abstraction. >> There's Bulat's Stream library, which is pretty complete: >> >> http://haskell.org/haskellwiki/Library/Streams >> >> And Takano Akio's version, in which he divides the type classes into >> smaller pieces. This is closer to the direction I thought we should go: >> >> http://yogimo.sakura.ne.jp/ssc/ > I should also mention John Goerzen's HVIO library: > http://hackage.haskell.org/packages/archive/MissingH/1.0.0/doc/html/System-IO-HVIO.html to clear up things, HVIO was a basis for Streams, and Streams was a basis for SSC -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From ketil+haskell at ii.uib.no Fri Feb 1 08:29:02 2008 From: ketil+haskell at ii.uib.no (Ketil Malde) Date: Fri Feb 1 08:28:27 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <428207430.20080201142552@gmail.com> (Bulat Ziganshin's message of "Fri\, 1 Feb 2008 14\:25\:52 +0300") References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> <20080129175243.GA18863@scytale.galois.com> <479F6CBD.3090009@imn.htwk-leipzig.de> <259254796.20080129225150@gmail.com> <47A1ADEE.80407@gmail.com> <90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com> <1508723353.20080131161308@gmail.com> <87r6fxazbx.fsf@nmd9999.imr.no> <428207430.20080201142552@gmail.com> Message-ID: <87hcgsajq9.fsf@nmd9999.imr.no> Bulat Ziganshin writes: > may be it's too draconian restriction but i proposed just to use new > library in the new code. For backwards compatibility, I agree it would be preferable to retain the current default implementation, but opinions appear to differ. Whatever. > f <- openFile "name" > content <- readLine f -- read first line using Latin-1 > f' <- withEncoding (lookup content) f > str <- readLine f' -- read second line using encoding given on first line This is clear enough, but for the BOM-dependent decoding, you may have to do the equivalent of having the next call to 'readLine' re-read the first line instead. -k -- If I haven't seen further, it is by standing in the footprints of giants From rl at cse.unsw.edu.au Fri Feb 1 08:30:14 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Fri Feb 1 08:29:34 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <4410520824.20080201133428@gmail.com> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> <20080129175243.GA18863@scytale.galois.com> <479F6CBD.3090009@imn.htwk-leipzig.de> <259254796.20080129225150@gmail.com> <47A1ADEE.80407@gmail.com> <90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com> <1508723353.20080131161308@gmail.com> <47A2D258.7050704@cse.unsw.edu.au> <4410520824.20080201133428@gmail.com> Message-ID: <47A31EE6.9080409@cse.unsw.edu.au> Bulat Ziganshin wrote: > Hello Roman, > > Friday, February 1, 2008, 11:03:36 AM, you wrote: > >>> the right way to deal with "modifiers" is to attach them to the Handle >>> itself like this: >>> >>> f <- openFile "name" >>= withLocking >>= withEncoding utf8 > >> IMO, global state is never "the right way" if it can be avoided. It will >> always lead to problems. Especially in a functional language like Haskell. > > so you propose something like this: > > s <- readString "/path/filename" TextMode "utf8" line_num No. In my view, file handles and encodings exist on completely different levels of abstraction. The former are (or ought to be) simply an interface to the underlying OS capabilities. The latter would be part of a high-level I/O library which shouldn't even have the concept of a handle (and should use typed I/O). Also, it doesn't always make sense to associate an encoding with an entire file. For instance, a Russian-Greek dictionary might use ISO 8859-5 for Russian words and ISO 8859-7 for Greek ones. Roman From lemming at henning-thielemann.de Fri Feb 1 09:07:44 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Feb 1 09:06:57 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <47A31EE6.9080409@cse.unsw.edu.au> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> <20080129175243.GA18863@scytale.galois.com> <479F6CBD.3090009@imn.htwk-leipzig.de> <259254796.20080129225150@gmail.com> <47A1ADEE.80407@gmail.com> <90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com> <1508723353.20080131161308@gmail.com> <47A2D258.7050704@cse.unsw.edu.au> <4410520824.20080201133428@gmail.com> <47A31EE6.9080409@cse.unsw.edu.au> Message-ID: On Sat, 2 Feb 2008, Roman Leshchinskiy wrote: > Bulat Ziganshin wrote: > > Hello Roman, > > > > Friday, February 1, 2008, 11:03:36 AM, you wrote: > > > >>> the right way to deal with "modifiers" is to attach them to the Handle > >>> itself like this: > >>> > >>> f <- openFile "name" >>= withLocking >>= withEncoding utf8 > > > >> IMO, global state is never "the right way" if it can be avoided. It will > >> always lead to problems. Especially in a functional language like Haskell. > > > > so you propose something like this: > > > > s <- readString "/path/filename" TextMode "utf8" line_num > > No. In my view, file handles and encodings exist on completely different > levels of abstraction. What about changing the subject in order to preserve the thread for further contributions to the concatMapM issue? From bulat.ziganshin at gmail.com Fri Feb 1 09:36:54 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Feb 1 11:10:32 2008 Subject: i/o encodings In-Reply-To: <87hcgsajq9.fsf@nmd9999.imr.no> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> <20080129175243.GA18863@scytale.galois.com> <479F6CBD.3090009@imn.htwk-leipzig.de> <259254796.20080129225150@gmail.com> <47A1ADEE.80407@gmail.com> <90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com> <1508723353.20080131161308@gmail.com> <87r6fxazbx.fsf@nmd9999.imr.no> <428207430.20080201142552@gmail.com> <87hcgsajq9.fsf@nmd9999.imr.no> Message-ID: <1707666901.20080201173654@gmail.com> Hello Ketil, Friday, February 1, 2008, 4:29:02 PM, you wrote: >> may be it's too draconian restriction but i proposed just to use new >> library in the new code. > For backwards compatibility, I agree it would be preferable to retain > the current default implementation, but opinions appear to differ. > Whatever. the problem is not abstract "backward compatibility" but programs that switches from the old lib to the new one. they should get exactly the old services for old names - in order to not rewrite program new programs what need new behavior just need to import new interface which may provide UTF-8 encoding for text files by default >> f <- openFile "name" >> content <- readLine f -- read first line using Latin-1 >> f' <- withEncoding (lookup content) f >> str <- readLine f' -- read second line using encoding given on first line > This is clear enough, but for the BOM-dependent decoding, you may have > to do the equivalent of having the next call to 'readLine' re-read the > first line instead. it's not a problem - file pointer is retained in f and f' just interprets the bytes it read: f <- openFile "name" bom <- readBytes 4 f -- read first 4 bytes vRewind f f' <- withEncoding (lookup bom) f str <- readLine f' -- read first line using BOM encoding -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bos at serpentine.com Fri Feb 1 12:30:53 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Fri Feb 1 12:30:07 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <87r6fxazbx.fsf@nmd9999.imr.no> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> <20080129175243.GA18863@scytale.galois.com> <479F6CBD.3090009@imn.htwk-leipzig.de> <259254796.20080129225150@gmail.com> <47A1ADEE.80407@gmail.com> <90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com> <1508723353.20080131161308@gmail.com> <87r6fxazbx.fsf@nmd9999.imr.no> Message-ID: <47A3574D.2060103@serpentine.com> Ketil Malde wrote: > But how about a 'withDefaultEncoding' modifier that > inspects the first two (or four?) bytes for a Unicode BOM, and either > sets decoding accordingly and continues, or sets encoding according > to locale *and* lets the user read the first bytes when reading from > the handle. I really don't like the idea of gluing notions of encoding and decoding to Handles, because Handles are so limited in their usefulness. Even something as simple as reading an encrypted file defeats this approach. Never mind stream sockets, datagram sockets, memory mapped files, or any of a dozen other ways of getting data that will have an encoding. References: <478B90A4.4090807@gmail.com> <479F6CBD.3090009@imn.htwk-leipzig.de> <259254796.20080129225150@gmail.com> <47A1ADEE.80407@gmail.com> <90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com> <1508723353.20080131161308@gmail.com> <87r6fxazbx.fsf@nmd9999.imr.no> <125EACD0CAE4D24ABDB4D148C4593DA9049E9277@GBLONXMB02.corp.amvescap.net> <47A2F509.9020706@gmail.com> <90889fe70802010308i1a906087q3d3106197e877456@mail.gmail.com> Message-ID: <47A35856.8050106@serpentine.com> Johan Tibell wrote: > I initially used lazy I/O with lazy bytestrings in my web server but > I'm changing that behvior to use left folds instead precisely because > of the reasons you (and Oleg) mentioned. Unfortunately, that means I > need a incremental Parsec for bytestrings (I think) so there's yet > another library to write. It wouldn't be hard to take bytestringparser and perform the same transformation on it as Adam Langley did with his IncrementalGet parser for strict-binary. I've been skipping it due to lack of time, but it's an obviously right thing to do. <479F1801.20801@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> <20080129175243.GA18863@scytale.galois.com> <479F6CBD.3090009@imn.htwk-leipzig.de> <259254796.20080129225150@gmail.com> <47A1ADEE.80407@gmail.com> <90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com> <1508723353.20080131161308@gmail.com> <47A2D258.7050704@cse.unsw.edu.au> <47A2E9E6.6070208@cse.unsw.edu.au> Message-ID: On 2008-02-01, Roman Leshchinskiy wrote: > Aaron Denney wrote: >> On 2008-02-01, Roman Leshchinskiy wrote: >>> Bulat Ziganshin wrote: >>>> the right way to deal with "modifiers" is to attach them to the Handle >>>> itself like this: >>>> >>>> f <- openFile "name" >>= withLocking >>= withEncoding utf8 >>> IMO, global state is never "the right way" if it can be avoided. It will >>> always lead to problems. Especially in a functional language like Haskell. >> >> This isn't global state, but local to the handle, and only affects where >> the handle is passed in. It's just extending an opaque data type. > > If I can destructively change the encoding assocated with a Handle, then > it's global state. Right. But the example given doesn't necessarily have that. x <- [5, 6] >>= (return .) (+ 1) No modification is going on, but return of new values. I don't know how Bulat's stream library is implemented, but I expected a new handle wrapping the old to be returned. -- Aaron Denney -><- From agl at imperialviolet.org Fri Feb 1 20:06:55 2008 From: agl at imperialviolet.org (Adam Langley) Date: Fri Feb 1 20:06:07 2008 Subject: Incremental parsing and left folds In-Reply-To: <47A35856.8050106@serpentine.com> References: <478B90A4.4090807@gmail.com> <259254796.20080129225150@gmail.com> <47A1ADEE.80407@gmail.com> <90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com> <1508723353.20080131161308@gmail.com> <87r6fxazbx.fsf@nmd9999.imr.no> <125EACD0CAE4D24ABDB4D148C4593DA9049E9277@GBLONXMB02.corp.amvescap.net> <47A2F509.9020706@gmail.com> <90889fe70802010308i1a906087q3d3106197e877456@mail.gmail.com> <47A35856.8050106@serpentine.com> Message-ID: <396556a20802011706qecf6842we792616bd067dd4c@mail.gmail.com> On Feb 1, 2008 9:35 AM, Bryan O'Sullivan wrote: > It wouldn't be hard to take bytestringparser and perform the same > transformation on it as Adam Langley did with his IncrementalGet parser > for strict-binary. I've been skipping it due to lack of time, but it's > an obviously right thing to do. I think the hurdle here would be that you can't easily rollback the state. Normally, in a parser one can just take the current state and revert to that if a parsing path fails. However, in an incremental parser, of the style of IncrementalGet, rolling back the state would mean that the additional data which has been supplied to the parser, via continuations, will be lost and needs to be resupplied. That's a non-solution because the caller shouldn't need to know anything about the internals of the parser. I think one could get around this by having a couple of states, the latter being a list of all the additional ByteStrings that the parser has received. Then, after having prospectively failed a certain parse path, the failure must include the list of additional data, which can be merged into the new state for the next prospective path. This failure value must be internal and, at the top level, translated into a more user-friendly failure. Unless something special is done, this also means that the incremental parser couldn't walk over huge streams of data, because it would still be holding all the input in case it gets reverted. Of course, the top level cannot be reverted, so maybe it's worth special casing this. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org 650-283-9641 From david at loisch.de Sat Feb 2 06:41:44 2008 From: david at loisch.de (David Leuschner) Date: Sat Feb 2 06:40:55 2008 Subject: darcs patch: Figure out timezone offset from timezone name Message-ID: Sat Feb 2 12:33:17 CET 2008 David Leuschner * Figure out timezone offset from timezone name -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 10435 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/libraries/attachments/20080202/e14f4820/attachment.bin From johan.tibell at gmail.com Sat Feb 2 13:34:18 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Sat Feb 2 13:33:29 2008 Subject: i/o encodings In-Reply-To: <1707666901.20080201173654@gmail.com> References: <478B90A4.4090807@gmail.com> <259254796.20080129225150@gmail.com> <47A1ADEE.80407@gmail.com> <90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com> <1508723353.20080131161308@gmail.com> <87r6fxazbx.fsf@nmd9999.imr.no> <428207430.20080201142552@gmail.com> <87hcgsajq9.fsf@nmd9999.imr.no> <1707666901.20080201173654@gmail.com> Message-ID: <90889fe70802021034k33b60fe4rb614196de02d55b0@mail.gmail.com> On Feb 1, 2008 3:36 PM, Bulat Ziganshin wrote: > Hello Ketil, > > Friday, February 1, 2008, 4:29:02 PM, you wrote: > > >> may be it's too draconian restriction but i proposed just to use new > >> library in the new code. > > > For backwards compatibility, I agree it would be preferable to retain > > the current default implementation, but opinions appear to differ. > > Whatever. > > the problem is not abstract "backward compatibility" but programs that > switches from the old lib to the new one. they should get exactly the > old services for old names - in order to not rewrite program Couldn't we handle backward compability by having say a 1.x line and a 2.x line of a library and push fixes to both? I'm afraid that libraries will turn into a mess eventually if they must support all old software in new versions. -- Johan From alexander.dunlap at gmail.com Sat Feb 2 13:35:19 2008 From: alexander.dunlap at gmail.com (Alexander Dunlap) Date: Sat Feb 2 13:34:35 2008 Subject: Readline read_history and write_history addition In-Reply-To: <2608b8a80801230519v72388283xf35f1de120571ca2@mail.gmail.com> References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> <57526e770801191543u71ad5c52r2edd09387c8fe870@mail.gmail.com> <6d74b0d20801211027v621580b2k6584eb3b24bf8320@mail.gmail.com> <57526e770801212034g790f1671p38d47b681bd687bb@mail.gmail.com> <20080122221326.GA20619@matrix.chaos.earth.li> <2608b8a80801221549k41b193cq303a3847f98554e1@mail.gmail.com> <20080123005111.GA25334@matrix.chaos.earth.li> <2608b8a80801230435u6a18fb7bh1046cc446120d75@mail.gmail.com> <20080123125724.GA2912@matrix.chaos.earth.li> <2608b8a80801230519v72388283xf35f1de120571ca2@mail.gmail.com> Message-ID: <57526e770802021035u170e47cey77edea12eaa5c340@mail.gmail.com> On Jan 23, 2008 5:19 AM, Yitzchak Gale wrote: > > > Those are asynchronous phenomena. > > > I'm not sure what you mean by that? > > It's a synchronous exception. > > Sorry. I meant external. In the following sense: > > The semantics of the program explicitly involve > it in a larger external system, in a way that it > might make sense to allow exceptions to propagate > out to the external system. > > With readline history, it is clear that we must handle > all conditions internally, so this condition is not met. > Since E1-3 are also not met, we should not throw > IO exceptions. > > -Yitz > The deadline for comments has passed and it seems like there isn't any opposition to adding this to the library. The only thing that remains is to make a decision on the exceptions vs. IO Bool thing. It seems like most are in favor of throwing an exception. For instances where an exception would be too intrusive, I don't see how it would be too hard to write a wrapper function that would have exactly the same monad requirements as the original function but return an IO Bool instead of an error, e.g. > tryReadHistory = catch readHistory (\e -> ... So where do we go from here? Alex From gale at sefer.org Sat Feb 2 14:30:28 2008 From: gale at sefer.org (Yitzchak Gale) Date: Sat Feb 2 14:29:39 2008 Subject: Readline read_history and write_history addition In-Reply-To: <57526e770802021035u170e47cey77edea12eaa5c340@mail.gmail.com> References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> <6d74b0d20801211027v621580b2k6584eb3b24bf8320@mail.gmail.com> <57526e770801212034g790f1671p38d47b681bd687bb@mail.gmail.com> <20080122221326.GA20619@matrix.chaos.earth.li> <2608b8a80801221549k41b193cq303a3847f98554e1@mail.gmail.com> <20080123005111.GA25334@matrix.chaos.earth.li> <2608b8a80801230435u6a18fb7bh1046cc446120d75@mail.gmail.com> <20080123125724.GA2912@matrix.chaos.earth.li> <2608b8a80801230519v72388283xf35f1de120571ca2@mail.gmail.com> <57526e770802021035u170e47cey77edea12eaa5c340@mail.gmail.com> Message-ID: <2608b8a80802021130i2b4486c3m74bc6ef7fdd2c425@mail.gmail.com> Alexander Dunlap wrote: > For instances where an exception would be too intrusive, I don't see > how it would be too hard to write a wrapper function In a library that does not have direct access to the IO monad, it would be not just hard - it would be impossible. That is because of type restrictions in the current versions of catch, block, and friends. For example, if you are writing a library that exports something like: class MonadIO m => MyMonad m where... you can't block or catch exceptions, so you have to limit yourself as much as possible to operations that are unlikely to throw IO exceptions. Otherwise, you have to pass on responsibility to users of the library, which makes the library much less useful. That, in turn, would make the use of readline very awkward and complex - or in some cases even impossible - in programs based on monad transformers, one of the most beautiful and powerful idioms in Haskell. What a shame. (The other case is the one Ian mentioned, but as he points out, that could be considered a bug in the library.) On the other hand, it would never be too intrusive to write a wrapper providing an exception if that is really required. So that would be more general. The question becomes: given all of the other bindings in this readline library, is there any conceivable simple usage of readline that would usually not raise exceptions? If not, we should try to fix that. Otherwise, the situation is hopeless anyway, so then it would sadly not make any difference what we do with this particular binding. Regards, Yitz From dons at galois.com Sat Feb 2 14:36:33 2008 From: dons at galois.com (Don Stewart) Date: Sat Feb 2 14:35:45 2008 Subject: darcs patch: Figure out timezone offset from timezone name In-Reply-To: References: Message-ID: <20080202193633.GC23937@scytale.galois.com> david: > Sat Feb 2 12:33:17 CET 2008 David Leuschner > * Figure out timezone offset from timezone name This should be forwarded to the time library maintainer, Bjorn Bringert. From igloo at earth.li Sat Feb 2 14:48:31 2008 From: igloo at earth.li (Ian Lynagh) Date: Sat Feb 2 14:47:49 2008 Subject: darcs patch: Figure out timezone offset from timezone name In-Reply-To: <20080202193633.GC23937@scytale.galois.com> References: <20080202193633.GC23937@scytale.galois.com> Message-ID: <20080202194831.GA1827@matrix.chaos.earth.li> On Sat, Feb 02, 2008 at 11:36:33AM -0800, Donald Bruce Stewart wrote: > david: > > Sat Feb 2 12:33:17 CET 2008 David Leuschner > > * Figure out timezone offset from timezone name > > This should be forwarded to the time library maintainer, Bjorn Bringert. It's Ashley Yakeley according to the Cabal file. Thanks Ian From duncan.coutts at worc.ox.ac.uk Sat Feb 2 14:49:11 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Feb 2 14:48:22 2008 Subject: darcs patch: Figure out timezone offset from timezone name In-Reply-To: <20080202193633.GC23937@scytale.galois.com> References: <20080202193633.GC23937@scytale.galois.com> Message-ID: <1201981751.13130.168.camel@localhost> On Sat, 2008-02-02 at 11:36 -0800, Don Stewart wrote: > david: > > Sat Feb 2 12:33:17 CET 2008 David Leuschner > > * Figure out timezone offset from timezone name > > This should be forwarded to the time library maintainer, Bjorn Bringert. If that is the case then he should probably update the email address that darcs uses: http://darcs.haskell.org/packages/time/_darcs/prefs/email It is currently set to this list. Duncan From judah.jacobson at gmail.com Sat Feb 2 15:03:55 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Sat Feb 2 15:03:19 2008 Subject: Readline read_history and write_history addition In-Reply-To: <2608b8a80802021130i2b4486c3m74bc6ef7fdd2c425@mail.gmail.com> References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> <57526e770801212034g790f1671p38d47b681bd687bb@mail.gmail.com> <20080122221326.GA20619@matrix.chaos.earth.li> <2608b8a80801221549k41b193cq303a3847f98554e1@mail.gmail.com> <20080123005111.GA25334@matrix.chaos.earth.li> <2608b8a80801230435u6a18fb7bh1046cc446120d75@mail.gmail.com> <20080123125724.GA2912@matrix.chaos.earth.li> <2608b8a80801230519v72388283xf35f1de120571ca2@mail.gmail.com> <57526e770802021035u170e47cey77edea12eaa5c340@mail.gmail.com> <2608b8a80802021130i2b4486c3m74bc6ef7fdd2c425@mail.gmail.com> Message-ID: <6d74b0d20802021203x7ae35e0fjaee1a1c961731856@mail.gmail.com> On Sat, Feb 2, 2008 at 11:30 AM, Yitzchak Gale wrote: > Alexander Dunlap wrote: > > For instances where an exception would be too intrusive, I don't see > > how it would be too hard to write a wrapper function > > In a library that does not have direct access to the IO > monad, it would be not just hard - it would be impossible. > That is because of type restrictions in the current versions > of catch, block, and friends. You haven't said why something like the following would not be sufficient: readHistoryM :: MonadIO m => String -> m Bool readHistoryM file = liftIO $ do result <- try (readHistory file) return (result == Right ()) -Judah From bjorn at bringert.net Sat Feb 2 15:17:33 2008 From: bjorn at bringert.net (Bjorn Bringert) Date: Sat Feb 2 15:16:43 2008 Subject: darcs patch: Figure out timezone offset from timezone name In-Reply-To: <1201981751.13130.168.camel@localhost> References: <20080202193633.GC23937@scytale.galois.com> <1201981751.13130.168.camel@localhost> Message-ID: On Feb 2, 2008 8:49 PM, Duncan Coutts wrote: > > On Sat, 2008-02-02 at 11:36 -0800, Don Stewart wrote: > > david: > > > Sat Feb 2 12:33:17 CET 2008 David Leuschner > > > * Figure out timezone offset from timezone name > > > > This should be forwarded to the time library maintainer, Bjorn Bringert. > > If that is the case then he should probably update the email address > that darcs uses: > > http://darcs.haskell.org/packages/time/_darcs/prefs/email > > It is currently set to this list. > > Duncan I also thought that Ashley Yakeley was the maintainer. I have written the code that this patch concerns though. The patch seems nice, but there are some problems: - Time zone information is not static. - Time zone names are sometimes ambiguous. Shouldn't we really use the OS time zone database for this? /Bj?rn From gale at sefer.org Sat Feb 2 16:14:28 2008 From: gale at sefer.org (Yitzchak Gale) Date: Sat Feb 2 16:13:39 2008 Subject: Readline read_history and write_history addition In-Reply-To: <6d74b0d20802021203x7ae35e0fjaee1a1c961731856@mail.gmail.com> References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> <20080122221326.GA20619@matrix.chaos.earth.li> <2608b8a80801221549k41b193cq303a3847f98554e1@mail.gmail.com> <20080123005111.GA25334@matrix.chaos.earth.li> <2608b8a80801230435u6a18fb7bh1046cc446120d75@mail.gmail.com> <20080123125724.GA2912@matrix.chaos.earth.li> <2608b8a80801230519v72388283xf35f1de120571ca2@mail.gmail.com> <57526e770802021035u170e47cey77edea12eaa5c340@mail.gmail.com> <2608b8a80802021130i2b4486c3m74bc6ef7fdd2c425@mail.gmail.com> <6d74b0d20802021203x7ae35e0fjaee1a1c961731856@mail.gmail.com> Message-ID: <2608b8a80802021314k7bcbc643n22d4ee53e6506d73@mail.gmail.com> Alexander Dunlap wrote: >>> For instances where an exception would be too intrusive, I don't see >>> how it would be too hard to write a wrapper function I wrote: >> In a library that does not have direct access to the IO >> monad, it would be not just hard - it would be impossible. >> That is because of type restrictions in the current versions >> of catch, block, and friends. Judah Jacobson wrote: > You haven't said why something like the following would not be sufficient: > > readHistoryM :: MonadIO m => String -> m Bool > readHistoryM file = liftIO $ do > result <- try (readHistory file) > return (result == Right ()) Because a library - other than readline itself - can't force its users to do that. OK. Here's a simplified real-world example. Say you want to write a simple library that interfaces the text-to-speech facilities available on multiple platforms. To play nicely with programs written in a monadic style, the interface might be something like: class MonadIO m => Speech m where sayText :: String -> m () runSpeech :: m a -> IO a instance Speech SomeSpeechSystem where sayText t = ... runSpeech x = do liftIO startSomeSpeechSystem ret <- x liftIO stopSomeSpeechSystem return ret Unfortunately, bracket is not available. So if x throws an uncaught IO exception, you may leave around zombies, database corruption, missiles armed for launch, etc. Well, if your speech system doesn't arm any missiles, you may consider it a reasonable risk to use this library in programs that could throw an IO exception on some rare error condition. But the proposal here is to raise the exception in a common situation that will definitely occur in regular usage. That may be fine in Java or Python, but it is a bad idea for IO exceptions in Haskell. Alexander Dunlap wrote: > So why couldn't you have a Utils.hs file that imports System.IO and > provides the wrapper around readHistory? Then you can use the > tryReadHistory function in your MonadIO-exporting module _exactly_ the > same way as the original readHistory function. You can. But if you are writing a library, your users might not. Regards, Yitz From alexander.dunlap at gmail.com Sat Feb 2 16:17:44 2008 From: alexander.dunlap at gmail.com (Alexander Dunlap) Date: Sat Feb 2 16:16:54 2008 Subject: Fwd: Readline read_history and write_history addition In-Reply-To: <57526e770802021317p1ebe5821y523e103963f311af@mail.gmail.com> References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> <20080123005111.GA25334@matrix.chaos.earth.li> <2608b8a80801230435u6a18fb7bh1046cc446120d75@mail.gmail.com> <20080123125724.GA2912@matrix.chaos.earth.li> <2608b8a80801230519v72388283xf35f1de120571ca2@mail.gmail.com> <57526e770802021035u170e47cey77edea12eaa5c340@mail.gmail.com> <2608b8a80802021130i2b4486c3m74bc6ef7fdd2c425@mail.gmail.com> <6d74b0d20802021203x7ae35e0fjaee1a1c961731856@mail.gmail.com> <2608b8a80802021314k7bcbc643n22d4ee53e6506d73@mail.gmail.com> <57526e770802021317p1ebe5821y523e103963f311af@mail.gmail.com> Message-ID: <57526e770802021317i5038126bue53572e64d6131ae@mail.gmail.com> On Feb 2, 2008 1:14 PM, Yitzchak Gale wrote: > Alexander Dunlap wrote: > >>> For instances where an exception would be too intrusive, I don't see > >>> how it would be too hard to write a wrapper function > > I wrote: > >> In a library that does not have direct access to the IO > >> monad, it would be not just hard - it would be impossible. > >> That is because of type restrictions in the current versions > >> of catch, block, and friends. > > Judah Jacobson wrote: > > You haven't said why something like the following would not be sufficient: > > > > readHistoryM :: MonadIO m => String -> m Bool > > readHistoryM file = liftIO $ do > > result <- try (readHistory file) > > return (result == Right ()) > > Because a library - other than readline itself - can't > force its users to do that. > > OK. Here's a simplified real-world example. Say you want to > write a simple library that interfaces the text-to-speech facilities > available on multiple platforms. To play nicely with programs > written in a monadic style, the interface might be something like: > > class MonadIO m => Speech m where > sayText :: String -> m () > runSpeech :: m a -> IO a > > instance Speech SomeSpeechSystem where > sayText t = ... > runSpeech x = do > liftIO startSomeSpeechSystem > ret <- x > liftIO stopSomeSpeechSystem > return ret > > Unfortunately, bracket is not available. So if x throws an > uncaught IO exception, you may leave around zombies, > database corruption, missiles armed for launch, etc. > > Well, if your speech system doesn't arm any missiles, > you may consider it a reasonable risk to use this > library in programs that could throw an IO exception > on some rare error condition. > > But the proposal here is to raise the exception in a > common situation that will definitely occur in regular > usage. That may be fine in Java or Python, but it > is a bad idea for IO exceptions in Haskell. > > Alexander Dunlap wrote: > > So why couldn't you have a Utils.hs file that imports System.IO and > > provides the wrapper around readHistory? Then you can use the > > tryReadHistory function in your MonadIO-exporting module _exactly_ the > > same way as the original readHistory function. > > You can. But if you are writing a library, your users > might not. > > Regards, > Yitz > I don't understand. Why don't you compile the functions we are suggesting _into the library_? Alex From agl at imperialviolet.org Sat Feb 2 16:34:24 2008 From: agl at imperialviolet.org (Adam Langley) Date: Sat Feb 2 16:33:34 2008 Subject: Incremental parsing and left folds In-Reply-To: <396556a20802011706qecf6842we792616bd067dd4c@mail.gmail.com> References: <478B90A4.4090807@gmail.com> <47A1ADEE.80407@gmail.com> <90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com> <1508723353.20080131161308@gmail.com> <87r6fxazbx.fsf@nmd9999.imr.no> <125EACD0CAE4D24ABDB4D148C4593DA9049E9277@GBLONXMB02.corp.amvescap.net> <47A2F509.9020706@gmail.com> <90889fe70802010308i1a906087q3d3106197e877456@mail.gmail.com> <47A35856.8050106@serpentine.com> <396556a20802011706qecf6842we792616bd067dd4c@mail.gmail.com> Message-ID: <396556a20802021334u1c79814dx36cf60f9dd6b0cf4@mail.gmail.com> On Feb 1, 2008 5:06 PM, Adam Langley wrote: > I think one could get around this by having a couple of states, the > latter being a list of all the additional ByteStrings that the parser > has received. Then, after having prospectively failed a certain parse > path, the failure must include the list of additional data, which can > be merged into the new state for the next prospective path. This > failure value must be internal and, at the top level, translated into > a more user-friendly failure. That was actually bit tougher than I thought, but I got something working: http://www.imperialviolet.org/Incremental.hs Half the bottom functions are still commented out because I got bored, but the plus operator works (I think). I managed a couple of simple tests that I threw at it. I'm pretty sure the cutContinuation is a terrible hack but, apart from having continuations in both directions, it was the best that I could come up with. However, I obvious don't understand Parsec because I made the try operator redundant, and I'm pretty sure that shouldn't have happened. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org 650-283-9641 From judah.jacobson at gmail.com Sat Feb 2 17:05:50 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Sat Feb 2 17:05:00 2008 Subject: Readline read_history and write_history addition In-Reply-To: <2608b8a80802021314k7bcbc643n22d4ee53e6506d73@mail.gmail.com> References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> <2608b8a80801221549k41b193cq303a3847f98554e1@mail.gmail.com> <20080123005111.GA25334@matrix.chaos.earth.li> <2608b8a80801230435u6a18fb7bh1046cc446120d75@mail.gmail.com> <20080123125724.GA2912@matrix.chaos.earth.li> <2608b8a80801230519v72388283xf35f1de120571ca2@mail.gmail.com> <57526e770802021035u170e47cey77edea12eaa5c340@mail.gmail.com> <2608b8a80802021130i2b4486c3m74bc6ef7fdd2c425@mail.gmail.com> <6d74b0d20802021203x7ae35e0fjaee1a1c961731856@mail.gmail.com> <2608b8a80802021314k7bcbc643n22d4ee53e6506d73@mail.gmail.com> Message-ID: <6d74b0d20802021405p56c80f91gf806e2fbca4d4b65@mail.gmail.com> On Sat, Feb 2, 2008 at 1:14 PM, Yitzchak Gale wrote: > Alexander Dunlap wrote: > >>> For instances where an exception would be too intrusive, I don't see > >>> how it would be too hard to write a wrapper function > > > I wrote: > >> In a library that does not have direct access to the IO > >> monad, it would be not just hard - it would be impossible. > >> That is because of type restrictions in the current versions > >> of catch, block, and friends. > > > Judah Jacobson wrote: > > You haven't said why something like the following would not be sufficient: > > > > readHistoryM :: MonadIO m => String -> m Bool > > readHistoryM file = liftIO $ do > > result <- try (readHistory file) > > return (result == Right ()) > > Because a library - other than readline itself - can't > force its users to do that. > > OK. Here's a simplified real-world example. Say you want to > write a simple library that interfaces the text-to-speech facilities > available on multiple platforms. To play nicely with programs > written in a monadic style, the interface might be something like: > > class MonadIO m => Speech m where > sayText :: String -> m () > runSpeech :: m a -> IO a > > instance Speech SomeSpeechSystem where > sayText t = ... > runSpeech x = do > liftIO startSomeSpeechSystem > ret <- x > liftIO stopSomeSpeechSystem > return ret > > Unfortunately, bracket is not available. So if x throws an > uncaught IO exception, you may leave around zombies, > database corruption, missiles armed for launch, etc. I've already demonstrated how a library writer can solve that problem in: http://www.haskell.org/pipermail/libraries/2008-January/009034.html -Judah From gale at sefer.org Sat Feb 2 17:08:37 2008 From: gale at sefer.org (Yitzchak Gale) Date: Sat Feb 2 17:07:46 2008 Subject: Readline read_history and write_history addition In-Reply-To: <57526e770802021317i5038126bue53572e64d6131ae@mail.gmail.com> References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> <2608b8a80801230435u6a18fb7bh1046cc446120d75@mail.gmail.com> <20080123125724.GA2912@matrix.chaos.earth.li> <2608b8a80801230519v72388283xf35f1de120571ca2@mail.gmail.com> <57526e770802021035u170e47cey77edea12eaa5c340@mail.gmail.com> <2608b8a80802021130i2b4486c3m74bc6ef7fdd2c425@mail.gmail.com> <6d74b0d20802021203x7ae35e0fjaee1a1c961731856@mail.gmail.com> <2608b8a80802021314k7bcbc643n22d4ee53e6506d73@mail.gmail.com> <57526e770802021317p1ebe5821y523e103963f311af@mail.gmail.com> <57526e770802021317i5038126bue53572e64d6131ae@mail.gmail.com> Message-ID: <2608b8a80802021408g71b7b57ev96542b88068c470c@mail.gmail.com> Alexander Dunlap wrote: > I don't understand. Why don't you compile the functions we are > suggesting _into the library_? The wrapper in either direction is a trivial one liner. The question is: what will be the standard advertised API? If we provide an exception-based idiom for this, we could indirectly cause a system-damaging crash in some seemingly unrelated part of someone's program. That is why I am suggesting that we not include any functions that raise exceptions in non-error conditions. The argument against the above might be as follows: The current limitations in the IO exception system just mean that Haskell is not quite completely ready yet for the monad transformer style. Perhaps. It would make me a bit sad to add one more way that its usefulness is limited, though. I don't think that the difference between raising an exception and other idioms is important enough in this case to make the readline library one of those ways. Thanks, Yitz From gale at sefer.org Sat Feb 2 17:58:45 2008 From: gale at sefer.org (Yitzchak Gale) Date: Sat Feb 2 17:57:56 2008 Subject: Readline read_history and write_history addition In-Reply-To: <6d74b0d20802021405p56c80f91gf806e2fbca4d4b65@mail.gmail.com> References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> <20080123005111.GA25334@matrix.chaos.earth.li> <2608b8a80801230435u6a18fb7bh1046cc446120d75@mail.gmail.com> <20080123125724.GA2912@matrix.chaos.earth.li> <2608b8a80801230519v72388283xf35f1de120571ca2@mail.gmail.com> <57526e770802021035u170e47cey77edea12eaa5c340@mail.gmail.com> <2608b8a80802021130i2b4486c3m74bc6ef7fdd2c425@mail.gmail.com> <6d74b0d20802021203x7ae35e0fjaee1a1c961731856@mail.gmail.com> <2608b8a80802021314k7bcbc643n22d4ee53e6506d73@mail.gmail.com> <6d74b0d20802021405p56c80f91gf806e2fbca4d4b65@mail.gmail.com> Message-ID: <2608b8a80802021458o77015d47o3d72a3b9a23919c5@mail.gmail.com> Judah Jacobson wrote: > I've already demonstrated how a library writer can solve that problem in: > http://www.haskell.org/pipermail/libraries/2008-January/009034.html Yes, that is indeed very nice. But I don't think it is a practical solution right now. I'll explain why I think that under a different subject. Regards, Yitz From gale at sefer.org Sat Feb 2 18:27:44 2008 From: gale at sefer.org (Yitzchak Gale) Date: Sat Feb 2 18:26:53 2008 Subject: MonadIO and IO exceptions Message-ID: <2608b8a80802021527l107575cdya1a4e2dcfa8f9aa3@mail.gmail.com> Judah Jacobson wrote: > I've already demonstrated how a library writer can solve that problem in: > http://www.haskell.org/pipermail/libraries/2008-January/009034.html Yes, that is indeed very nice. But I don't think it is a practical solution right now, for the following reasons: It requires that users be in a special monad; it doesn't work for regular MonadIO. So it isn't really a practical solution until it gets into MTL and people start porting their code. Providing an instance for MonadIO1 (or whatever we would call it) is an extra step for monad writers that may often be skipped. Also, there are obviously many other more complex cases beyond a simple bracket. How general is this technique? As you point out, even for bracket it does not work unless the "after" action is IO. What other restrictions are there in the general case? Perhaps we could fix those problems by also providing liftIOk for all kinds k that occur in the signatures of various functions in Control.Exception. But that would make the new monad even more unwieldy. As I suggested before, I think the best solution would be to define the functions of Control.Exception in terms of lower-level primitives that could then be used to define the functions directly for other monads. Perhaps something like this would be general enough to cover everything: -- Delay any exception and put in buffer startDelayingExceptions :: IO () -- Stop delaying exceptions stopDelayingExceptions :: IO () -- Retrieve delayed exception and clear buffer getDelayedException :: IO (Maybe Exception) There would be one exception buffer per thread. New exceptions would replace old ones, so users of this mechanism would be required to catch as catch can. Based on Simon Marlow's observation in our previous discussion on this topic, we would still want to leave around the current primitives as a special case optimization for IO. Regards, Yitz From bertram.felgenhauer at googlemail.com Sat Feb 2 19:02:18 2008 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Sat Feb 2 19:01:34 2008 Subject: Readline read_history and write_history addition In-Reply-To: <2608b8a80802021314k7bcbc643n22d4ee53e6506d73@mail.gmail.com> References: <20080122221326.GA20619@matrix.chaos.earth.li> <2608b8a80801221549k41b193cq303a3847f98554e1@mail.gmail.com> <20080123005111.GA25334@matrix.chaos.earth.li> <2608b8a80801230435u6a18fb7bh1046cc446120d75@mail.gmail.com> <20080123125724.GA2912@matrix.chaos.earth.li> <2608b8a80801230519v72388283xf35f1de120571ca2@mail.gmail.com> <57526e770802021035u170e47cey77edea12eaa5c340@mail.gmail.com> <2608b8a80802021130i2b4486c3m74bc6ef7fdd2c425@mail.gmail.com> <6d74b0d20802021203x7ae35e0fjaee1a1c961731856@mail.gmail.com> <2608b8a80802021314k7bcbc643n22d4ee53e6506d73@mail.gmail.com> Message-ID: <20080203000218.GA5177@zombie.inf.tu-dresden.de> Yitzchak Gale wrote: > OK. Here's a simplified real-world example. Say you want to > write a simple library that interfaces the text-to-speech facilities > available on multiple platforms. To play nicely with programs > written in a monadic style, the interface might be something like: > > class MonadIO m => Speech m where > sayText :: String -> m () > runSpeech :: m a -> IO a You meant ma -> m a here, right? > instance Speech SomeSpeechSystem where > sayText t = ... > runSpeech x = do > liftIO startSomeSpeechSystem > ret <- x > liftIO stopSomeSpeechSystem > return ret I think MonadIO is the wrong type class here. For example, ListT IO is an instance of MonadIO, and may cause stopSomeSpeechSystem to be never called, or several times, per startSomeSpeechSytem call, which is clearly not what you wanted (this is still true for the 'ListT done right' versions of ListT). ContT should also be interesting. > But the proposal here is to raise the exception in a > common situation that will definitely occur in regular > usage. That may be fine in Java or Python, but it > is a bad idea for IO exceptions in Haskell. I agree with that though. regards, Bertram From ben.franksen at online.de Sun Feb 3 07:48:49 2008 From: ben.franksen at online.de (Ben Franksen) Date: Sun Feb 3 15:34:11 2008 Subject: Incremental parsing and left folds References: <478B90A4.4090807@gmail.com> <259254796.20080129225150@gmail.com> <47A1ADEE.80407@gmail.com> <90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com> <1508723353.20080131161308@gmail.com> <87r6fxazbx.fsf@nmd9999.imr.no> <125EACD0CAE4D24ABDB4D148C4593DA9049E9277@GBLONXMB02.corp.amvescap.net> <47A2F509.9020706@gmail.com> <90889fe70802010308i1a906087q3d3106197e877456@mail.gmail.com> <47A35856.8050106@serpentine.com> <396556a20802011706qecf6842we792616bd067dd4c@mail.gmail.com> Message-ID: Adam Langley wrote: > On Feb 1, 2008 9:35 AM, Bryan O'Sullivan wrote: >> It wouldn't be hard to take bytestringparser and perform the same >> transformation on it as Adam Langley did with his IncrementalGet parser >> for strict-binary. I've been skipping it due to lack of time, but it's >> an obviously right thing to do. > > I think the hurdle here would be that you can't easily rollback the > state. Normally, in a parser one can just take the current state and > revert to that if a parsing path fails. However, in an incremental > parser, of the style of IncrementalGet, rolling back the state would > mean that the additional data which has been supplied to the parser, > via continuations, will be lost and needs to be resupplied. That's a > non-solution because the caller shouldn't need to know anything about > the internals of the parser. > > I think one could get around this by having a couple of states, the > latter being a list of all the additional ByteStrings that the parser > has received. Then, after having prospectively failed a certain parse > path, the failure must include the list of additional data, which can > be merged into the new state for the next prospective path. This > failure value must be internal and, at the top level, translated into > a more user-friendly failure. > > Unless something special is done, this also means that the incremental > parser couldn't walk over huge streams of data, because it would still > be holding all the input in case it gets reverted. Of course, the top > level cannot be reverted, so maybe it's worth special casing this. Would 'Parallel Parsing Processes' help here? See http://www.haskell.org/haskellwiki/Research_papers/Functional_pearls For a version that is easy to understand and implement, see Chuan-kai Lin's Unimo paper available from the author's home page. Cheers Ben From bjorn at bringert.net Sun Feb 3 17:25:08 2008 From: bjorn at bringert.net (Bjorn Bringert) Date: Sun Feb 3 17:24:15 2008 Subject: darcs patch: Figure out timezone offset from timezone name In-Reply-To: References: <20080202193633.GC23937@scytale.galois.com> <1201981751.13130.168.camel@localhost> Message-ID: On Feb 2, 2008 9:17 PM, Bjorn Bringert wrote: > On Feb 2, 2008 8:49 PM, Duncan Coutts wrote: > > > > On Sat, 2008-02-02 at 11:36 -0800, Don Stewart wrote: > > > david: > > > > Sat Feb 2 12:33:17 CET 2008 David Leuschner > > > > * Figure out timezone offset from timezone name > > > > > > This should be forwarded to the time library maintainer, Bjorn Bringert. > > > > If that is the case then he should probably update the email address > > that darcs uses: > > > > http://darcs.haskell.org/packages/time/_darcs/prefs/email > > > > It is currently set to this list. > > > > Duncan > > I also thought that Ashley Yakeley was the maintainer. I have written > the code that this patch concerns though. The patch seems nice, but > there are some problems: > > - Time zone information is not static. > - Time zone names are sometimes ambiguous. > > Shouldn't we really use the OS time zone database for this? David and I have discussed this, and it seems like this hard-coded timezone database is in any case better than the current incorrect behavior. In the majority of cases it will do the right thing, instead of being almost always incorrect as it is now. I have pushed the patch now, but there are some improvements that could be made: - There are no test cases that test this. The Arbitrary TimeZone instance in test/TestParseTime.hs doesn't generate time zone names, so time zone name handling doesn't get tested. - The timezone table is rather long, and uses plain 'lookup'. OTOH, introducing a dependency on the 'containers' package seems excessive just to do faster lookup. /Bjorn From isaacdupree at charter.net Sun Feb 3 20:07:43 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Sun Feb 3 20:06:53 2008 Subject: darcs patch: Figure out timezone offset from timezone name In-Reply-To: References: <20080202193633.GC23937@scytale.galois.com> <1201981751.13130.168.camel@localhost> Message-ID: <47A6655F.2000407@charter.net> Bjorn Bringert wrote: > - The timezone table is rather long, and uses plain 'lookup'. OTOH, > introducing a dependency on the 'containers' package seems excessive > just to do faster lookup. it doesn't seem excessive to me -- one of the main things 'containers' implements is fast(ish) lookup. But you mean the way it's looking up amongst a fixed/hard-coded set of keys? -Isaac From rl at cse.unsw.edu.au Sun Feb 3 20:18:43 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Sun Feb 3 20:17:58 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> <20080129175243.GA18863@scytale.galois.com> <479F6CBD.3090009@imn.htwk-leipzig.de> <259254796.20080129225150@gmail.com> <47A1ADEE.80407@gmail.com> <90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com> <1508723353.20080131161308@gmail.com> <47A2D258.7050704@cse.unsw.edu.au> <47A2E9E6.6070208@cse.unsw.edu.au> Message-ID: <47A667F3.2020707@cse.unsw.edu.au> Aaron Denney wrote: > On 2008-02-01, Roman Leshchinskiy wrote: >> Aaron Denney wrote: >>> On 2008-02-01, Roman Leshchinskiy wrote: >>>> Bulat Ziganshin wrote: >>>>> the right way to deal with "modifiers" is to attach them to the Handle >>>>> itself like this: >>>>> >>>>> f <- openFile "name" >>= withLocking >>= withEncoding utf8 >>>> IMO, global state is never "the right way" if it can be avoided. It will >>>> always lead to problems. Especially in a functional language like Haskell. >>> This isn't global state, but local to the handle, and only affects where >>> the handle is passed in. It's just extending an opaque data type. >> If I can destructively change the encoding assocated with a Handle, then >> it's global state. > > Right. But the example given doesn't necessarily have that. > > x <- [5, 6] >>= (return .) (+ 1) > > No modification is going on, but return of new values. True, but that is a very obfuscated way of doing this. If the handle is not modified destructively, then there is no need for withLocking etc. to be monadic. Roman From s.clover at gmail.com Sun Feb 3 22:19:29 2008 From: s.clover at gmail.com (Sterling Clover) Date: Sun Feb 3 22:18:37 2008 Subject: Zombie sh instances in System.Process In-Reply-To: <47A667F3.2020707@cse.unsw.edu.au> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> <20080129175243.GA18863@scytale.galois.com> <479F6CBD.3090009@imn.htwk-leipzig.de> <259254796.20080129225150@gmail.com> <47A1ADEE.80407@gmail.com> <90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com> <1508723353.20080131161308@gmail.com> <47A2D258.7050704@cse.unsw.edu.au> <47A2E9E6.6070208@cse.unsw.edu.au> <47A667F3.2020707@cse.unsw.edu.au> Message-ID: <384255A9-9192-45D1-9D05-7CCF4DF1D8C4@gmail.com> I was initially building strictify on top of System.Process.runInteractiveCommand. However, I soon ran into a fairly significant issue with the interface. Even once the process I was calling had terminated, and I had explicitly closed all its buffers, a zombie sh process was left around from it. As I was spawning, sequentially, lots of processes, this soon consumed too many resources and errored out. As I understand it, the sh process is used for redirection (in fact, I ended up implementing a variant of the same thing on top of System.Posix.Process eventually) and needs to stick around for a while, so that issues with lazyIO don't prevent the handles provided by command from terminating before we've read everything we want to. However, at the same time, it seems like a terrible idea to have these buffers stick around *forever*. I dug into the haskell code, but didn't look at the foreign C calls it was based on. This behavior seems pretty clearly broken to me, but I'm not sure what the exact solution should be. Possibly providing an explicit API method to shut the process down? Possibly blocking on polling its buffers and terminating the sh instance once all three buffers are explicitly or implicitly closed? --Sterl. From agl at imperialviolet.org Mon Feb 4 00:40:30 2008 From: agl at imperialviolet.org (Adam Langley) Date: Mon Feb 4 00:39:39 2008 Subject: Incremental parsing and left folds In-Reply-To: <396556a20802021334u1c79814dx36cf60f9dd6b0cf4@mail.gmail.com> References: <478B90A4.4090807@gmail.com> <90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com> <1508723353.20080131161308@gmail.com> <87r6fxazbx.fsf@nmd9999.imr.no> <125EACD0CAE4D24ABDB4D148C4593DA9049E9277@GBLONXMB02.corp.amvescap.net> <47A2F509.9020706@gmail.com> <90889fe70802010308i1a906087q3d3106197e877456@mail.gmail.com> <47A35856.8050106@serpentine.com> <396556a20802011706qecf6842we792616bd067dd4c@mail.gmail.com> <396556a20802021334u1c79814dx36cf60f9dd6b0cf4@mail.gmail.com> Message-ID: <396556a20802032140w4aafbc44o943e25ef12d73789@mail.gmail.com> On Feb 2, 2008 1:34 PM, Adam Langley wrote: > I'm pretty sure the cutContinuation is a terrible hack but, apart from > having continuations in both directions, it was the best that I could > come up with. However, I obvious don't understand Parsec because I > made the try operator redundant, and I'm pretty sure that shouldn't > have happened. Well, I still think that it's a pretty big hack, but since I'd worked out how to do choice in an incremental parser I added it to binary-strict in darcs. http://darcs.imperialviolet.org/darcsweb.cgi?r=binary-strict;a=summary specifically: http://darcs.imperialviolet.org/darcsweb.cgi?r=binary-strict;a=headblob;f=/src/Data/Binary/Strict/IncrementalGet.hs And since I had the choice operator, I added some other parsing stuff (many, <|> etc) to IncrementalGet and Get, than abstracted it out with a class http://darcs.imperialviolet.org/darcsweb.cgi?r=binary-strict;a=headblob;f=/src/Data/Binary/Strict/Class.hs Now you can write parsers which work in both strict and incremental modes. If you remove the monomorphism restriction, they can do both in the same module. As a test I'm writing an HTTP parser (one which handles all the RFC stuff that no one ever believes is valid - like newlines in lists) and it seems to be working pretty well. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org 650-283-9641 From gale at sefer.org Mon Feb 4 06:19:51 2008 From: gale at sefer.org (Yitzchak Gale) Date: Mon Feb 4 06:18:57 2008 Subject: Zombie sh instances in System.Process In-Reply-To: <384255A9-9192-45D1-9D05-7CCF4DF1D8C4@gmail.com> References: <478B90A4.4090807@gmail.com> <47A1ADEE.80407@gmail.com> <90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com> <1508723353.20080131161308@gmail.com> <47A2D258.7050704@cse.unsw.edu.au> <47A2E9E6.6070208@cse.unsw.edu.au> <47A667F3.2020707@cse.unsw.edu.au> <384255A9-9192-45D1-9D05-7CCF4DF1D8C4@gmail.com> Message-ID: <2608b8a80802040319j34c5052eye3d70fd6d94e2ec1@mail.gmail.com> Sterling Clover wrote: > Even once the process I > was calling had terminated, and I had explicitly closed all its > buffers, a zombie sh process was left around from it. Make sure to call waitForProcess on each process handle when you are finished with it. Regards, Yitz From simonmarhaskell at gmail.com Mon Feb 4 06:53:34 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Feb 4 06:52:41 2008 Subject: Readline read_history and write_history addition In-Reply-To: <2608b8a80802021314k7bcbc643n22d4ee53e6506d73@mail.gmail.com> References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> <20080122221326.GA20619@matrix.chaos.earth.li> <2608b8a80801221549k41b193cq303a3847f98554e1@mail.gmail.com> <20080123005111.GA25334@matrix.chaos.earth.li> <2608b8a80801230435u6a18fb7bh1046cc446120d75@mail.gmail.com> <20080123125724.GA2912@matrix.chaos.earth.li> <2608b8a80801230519v72388283xf35f1de120571ca2@mail.gmail.com> <57526e770802021035u170e47cey77edea12eaa5c340@mail.gmail.com> <2608b8a80802021130i2b4486c3m74bc6ef7fdd2c425@mail.gmail.com> <6d74b0d20802021203x7ae35e0fjaee1a1c961731856@mail.gmail.com> <2608b8a80802021314k7bcbc643n22d4ee53e6506d73@mail.gmail.com> Message-ID: <47A6FCBE.4090101@gmail.com> Yitzchak Gale wrote: > Alexander Dunlap wrote: >>>> For instances where an exception would be too intrusive, I don't see >>>> how it would be too hard to write a wrapper function > > I wrote: >>> In a library that does not have direct access to the IO >>> monad, it would be not just hard - it would be impossible. >>> That is because of type restrictions in the current versions >>> of catch, block, and friends. > > Judah Jacobson wrote: >> You haven't said why something like the following would not be sufficient: >> >> readHistoryM :: MonadIO m => String -> m Bool >> readHistoryM file = liftIO $ do >> result <- try (readHistory file) >> return (result == Right ()) > > Because a library - other than readline itself - can't > force its users to do that. > > OK. Here's a simplified real-world example. Say you want to > write a simple library that interfaces the text-to-speech facilities > available on multiple platforms. To play nicely with programs > written in a monadic style, the interface might be something like: > > class MonadIO m => Speech m where > sayText :: String -> m () > runSpeech :: m a -> IO a Here's my (slightly provocative) take on this: a MonadIO instance is not a complete wrapper around the IO monad, because it doesn't provide catch. It is not the responsibility of a library that provides IO functions to account for defficient wrappers of IO with no way to catch exceptions. The problem is in the IO wrapper, not the library that throws exceptions. However, I do agree that exceptions should generally be used for exceptional conditions, rather than for general control-flow. This is an example of a *good* reason to avoid an exception: because to use an exception for a non-exceptional condition is poor style. Avoiding exceptions because MonadIO has trouble with them is not a good enough reason, IMO. We should fix MonadIO instead. Cheers, Simon From gale at sefer.org Mon Feb 4 09:06:22 2008 From: gale at sefer.org (Yitzchak Gale) Date: Mon Feb 4 09:05:27 2008 Subject: Readline read_history and write_history addition In-Reply-To: <47A6FCBE.4090101@gmail.com> References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> <20080123005111.GA25334@matrix.chaos.earth.li> <2608b8a80801230435u6a18fb7bh1046cc446120d75@mail.gmail.com> <20080123125724.GA2912@matrix.chaos.earth.li> <2608b8a80801230519v72388283xf35f1de120571ca2@mail.gmail.com> <57526e770802021035u170e47cey77edea12eaa5c340@mail.gmail.com> <2608b8a80802021130i2b4486c3m74bc6ef7fdd2c425@mail.gmail.com> <6d74b0d20802021203x7ae35e0fjaee1a1c961731856@mail.gmail.com> <2608b8a80802021314k7bcbc643n22d4ee53e6506d73@mail.gmail.com> <47A6FCBE.4090101@gmail.com> Message-ID: <2608b8a80802040606mdb73f20n6090d1b437d5202@mail.gmail.com> Simon Marlow wrote: > Here's my (slightly provocative) take on this: a MonadIO instance is not a > complete wrapper around the IO monad, because it doesn't provide catch. That's true. > It is not the responsibility of a library that provides IO functions to > account for defficient wrappers of IO with no way to catch exceptions. The > problem is in the IO wrapper, not the library that throws exceptions. Makes sense. > However, I do agree that exceptions should generally be used for > exceptional conditions, rather than for general control-flow. This is an > example of a *good* reason to avoid an exception: because to use an > exception for a non-exceptional condition is poor style. That is also my opinion. Some people have disagreed. So this should be the focus of the decision then. Thanks, Yitz From bulat.ziganshin at gmail.com Mon Feb 4 02:41:53 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Feb 4 09:53:04 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <47A667F3.2020707@cse.unsw.edu.au> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> <20080129175243.GA18863@scytale.galois.com> <479F6CBD.3090009@imn.htwk-leipzig.de> <259254796.20080129225150@gmail.com> <47A1ADEE.80407@gmail.com> <90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com> <1508723353.20080131161308@gmail.com> <47A2D258.7050704@cse.unsw.edu.au> <47A2E9E6.6070208@cse.unsw.edu.au> <47A667F3.2020707@cse.unsw.edu.au> Message-ID: <1324598313.20080204104153@gmail.com> Hello Roman, Monday, February 4, 2008, 4:18:43 AM, you wrote: > True, but that is a very obfuscated way of doing this. If the handle is > not modified destructively, then there is no need for withLocking etc. > to be monadic. withLocking = fmap WithLocking newMVar -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From gale at sefer.org Mon Feb 4 09:59:07 2008 From: gale at sefer.org (Yitzchak Gale) Date: Mon Feb 4 09:58:11 2008 Subject: Fixing MonadIO Message-ID: <2608b8a80802040659wef2d357j537e601d0b1ad5bb@mail.gmail.com> Simon Marlow wrote: > Avoiding > exceptions because MonadIO has trouble with them is not a good enough > reason, IMO. We should fix MonadIO instead. I'm all for it! Below is a summary of the three approaches that have been proposed, as far as I can remember: 1. Make the functions in Control.Exception more polymorphic. This is part of the more general program of providing polymorphic IO described in Haskell' ticket 110. Brian Hulley attached to that ticket a version of Control.Exception that does this by introducing the MonadException subclass of MonadIO. http://hackage.haskell.org/trac/haskell-prime/attachment/ticket/110/Exception.txt 2. In another branch from this thread, I suggested adding only the following three low-level exception handling functions to Control.Exception: startDelayingExceptions stopDelayingExceptions getDelayedException This would allow exception handling to be extended arbitrarily in other libraries, with only a small addition to Control.Exception. Simon Marlow pointed out that this mechanism would lose certain optimizations that exist, e.g., for preserving tail-recursion in block. That would be a cost of this generality. (Obviously we would retain the current mechanism for IO itself.) http://www.haskell.org/pipermail/libraries/2008-February/009159.html 3. Earlier in this thread, Judah Jacobson proposed adding additional liftIO functions to MonadIO, or a subclass, that match the kinds of the exception handling functions of Control.Exception. The kinds that would be needed are: For block and unblock: * -> * For catch: * -> (* -> *) -> * For setUncaughtExceptionHandler: (* -> *) -> * The liftIO for catch is the most general, so it could be reused for the others, but that would look a little ad hoc. This approach has the advantage that it does not require any change at all to Control.Exception, but it puts more of a burden on monad authors. http://www.haskell.org/pipermail/libraries/2008-January/009034.html Any other approaches? Any opinions about which of these would be best? Thanks, Yitz From simonmarhaskell at gmail.com Mon Feb 4 11:25:18 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Feb 4 11:24:58 2008 Subject: Fixing MonadIO In-Reply-To: <2608b8a80802040659wef2d357j537e601d0b1ad5bb@mail.gmail.com> References: <2608b8a80802040659wef2d357j537e601d0b1ad5bb@mail.gmail.com> Message-ID: <47A73C6E.1090600@gmail.com> Yitzchak Gale wrote: > Simon Marlow wrote: >> Avoiding >> exceptions because MonadIO has trouble with them is not a good enough >> reason, IMO. We should fix MonadIO instead. > > I'm all for it! > > Below is a summary of the three approaches > that have been proposed, as far as I can remember: > > 1. Make the functions in Control.Exception more polymorphic. > This is part of the more general program of providing polymorphic > IO described in Haskell' ticket 110. Brian Hulley attached to that > ticket a version of Control.Exception that does this by introducing > the MonadException subclass of MonadIO. > > http://hackage.haskell.org/trac/haskell-prime/attachment/ticket/110/Exception.txt Correct me if I'm wrong, but it doesn't seem to be necessary to modify Control.Exception directly in order to adopt this proposal. The new module could be provided as Control.Monad.IO.Exception (for example) in the mtl package. No changes to the base package are required to make this functionality available to everyone. Right? If so, this seems like the smoothest way to address the problem. Cheers, Simon From dons at galois.com Mon Feb 4 13:34:12 2008 From: dons at galois.com (Don Stewart) Date: Mon Feb 4 13:33:36 2008 Subject: Zombie sh instances in System.Process In-Reply-To: <2608b8a80802040319j34c5052eye3d70fd6d94e2ec1@mail.gmail.com> References: <47A1ADEE.80407@gmail.com> <90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com> <1508723353.20080131161308@gmail.com> <47A2D258.7050704@cse.unsw.edu.au> <47A2E9E6.6070208@cse.unsw.edu.au> <47A667F3.2020707@cse.unsw.edu.au> <384255A9-9192-45D1-9D05-7CCF4DF1D8C4@gmail.com> <2608b8a80802040319j34c5052eye3d70fd6d94e2ec1@mail.gmail.com> Message-ID: <20080204183412.GB32486@scytale.galois.com> gale: > Sterling Clover wrote: > > Even once the process I > > was calling had terminated, and I had explicitly closed all its > > buffers, a zombie sh process was left around from it. > > Make sure to call waitForProcess on each process handle > when you are finished with it. Or even consider using say, newpopen, which wraps this up for you, http://www.cse.unsw.edu.au/~dons/code/newpopen/ From judah.jacobson at gmail.com Mon Feb 4 16:49:18 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Mon Feb 4 16:48:22 2008 Subject: Readline read_history and write_history addition In-Reply-To: <2608b8a80802040606mdb73f20n6090d1b437d5202@mail.gmail.com> References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> <2608b8a80801230435u6a18fb7bh1046cc446120d75@mail.gmail.com> <20080123125724.GA2912@matrix.chaos.earth.li> <2608b8a80801230519v72388283xf35f1de120571ca2@mail.gmail.com> <57526e770802021035u170e47cey77edea12eaa5c340@mail.gmail.com> <2608b8a80802021130i2b4486c3m74bc6ef7fdd2c425@mail.gmail.com> <6d74b0d20802021203x7ae35e0fjaee1a1c961731856@mail.gmail.com> <2608b8a80802021314k7bcbc643n22d4ee53e6506d73@mail.gmail.com> <47A6FCBE.4090101@gmail.com> <2608b8a80802040606mdb73f20n6090d1b437d5202@mail.gmail.com> Message-ID: <6d74b0d20802041349v1597c25cq4fdd55f4c9a9b904@mail.gmail.com> On Mon, Feb 4, 2008 at 6:06 AM, Yitzchak Gale wrote: > Simon Marlow wrote: > > However, I do agree that exceptions should generally be used for > > exceptional conditions, rather than for general control-flow. This is an > > example of a *good* reason to avoid an exception: because to use an > > exception for a non-exceptional condition is poor style. > > That is also my opinion. Some people have disagreed. > So this should be the focus of the decision then. I also agree that exceptions should only be used for exceptional conditions; but I do think that this is one of those situations. I'll try to explain why below. (Thanks, Yitzchak, for forking off the thread about fixing limitations of MonadIO.) I assume that the following conditions are already considered exceptional (I haven't ever heard anyone complain that they throw an exception): - readFile : read a nonexistent file - writeFile : write to a file in a nonexistent directory - getEnv: retrieve an unset environmental variable - System.Console.Readline.readInitFile: read a nonexistent .inputrc file I think of readHistory and writeHistory as analogues to the above functions. So calling writeHistory when the directory doesn't exist should produce an exception. And if you call readHistory, either check first that the file exists, or else expect that an exception will sometimes be thrown (just as is already the case for readFile). Packages like shellac-readline can wrap the two steps of "only readHistory if file exists" in a higher-level abstraction; but System.Console.Readline itself should just be a thin binding to the readline APIs. All that being said, this is a relatively minor issue, so if many people are strongly opposed to throwing an exception even after what I've said above, I'll accept the consensus decision. Barring that, however, I'm in favor of the interface already used by other, similar functions in the libraries. Thanks, -Judah From judah.jacobson at gmail.com Mon Feb 4 19:53:28 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Mon Feb 4 19:52:30 2008 Subject: Fixing MonadIO In-Reply-To: <47A73C6E.1090600@gmail.com> References: <2608b8a80802040659wef2d357j537e601d0b1ad5bb@mail.gmail.com> <47A73C6E.1090600@gmail.com> Message-ID: <6d74b0d20802041653ldb3c285o95b4158da4a0a4ac@mail.gmail.com> On Mon, Feb 4, 2008 at 8:25 AM, Simon Marlow wrote: > Yitzchak Gale wrote: > > Simon Marlow wrote: > >> Avoiding > >> exceptions because MonadIO has trouble with them is not a good enough > >> reason, IMO. We should fix MonadIO instead. > > > > I'm all for it! > > > > Below is a summary of the three approaches > > that have been proposed, as far as I can remember: > > > > 1. Make the functions in Control.Exception more polymorphic. > > This is part of the more general program of providing polymorphic > > IO described in Haskell' ticket 110. Brian Hulley attached to that > > ticket a version of Control.Exception that does this by introducing > > the MonadException subclass of MonadIO. > > > > http://hackage.haskell.org/trac/haskell-prime/attachment/ticket/110/Exception.txt > > Correct me if I'm wrong, but it doesn't seem to be necessary to modify > Control.Exception directly in order to adopt this proposal. The new module > could be provided as Control.Monad.IO.Exception (for example) in the mtl > package. No changes to the base package are required to make this > functionality available to everyone. Right? > > If so, this seems like the smoothest way to address the problem. Of the three possibilities listed by Yitzchak, I'm most in favor of adding Brian Hulley's module to the mtl package. (In particular, I've decided that I like it more than my own, earlier proposal.) The only change that I'd make would be to remove setUncaughtExceptionHandler from the MonadException class; it's GHC-specific, and I'm not sure how useful having it in arbitrary MonadIO would be anyway. Best, -Judah From ashley at semantic.org Mon Feb 4 23:28:56 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Mon Feb 4 23:27:59 2008 Subject: darcs patch: Figure out timezone offset from timezone name In-Reply-To: References: <20080202193633.GC23937@scytale.galois.com> <1201981751.13130.168.camel@localhost> Message-ID: <47A7E608.2030402@semantic.org> Bjorn Bringert wrote: > David and I have discussed this, and it seems like this hard-coded > timezone database is in any case better than the current incorrect > behavior. In the majority of cases it will do the right thing, instead > of being almost always incorrect as it is now. I have pushed the patch > now, but there are some improvements that could be made: I think this is wrong. Time-zones change quite frequently, and now any program compiled with 'time' will be incorrect the next time some government changes its zone. It's for a similar reason that no leap-second table is included in the package. I always prefer not to provide information than provide misinformation. That said, this file is Bjorn's part of the package. Is there an alternative approach? Is there some way we can query the tz database? I looked into this earlier but didn't find an obvious way. -- Ashley Yakeley From s.clover at gmail.com Mon Feb 4 23:34:06 2008 From: s.clover at gmail.com (Sterling Clover) Date: Mon Feb 4 23:33:13 2008 Subject: Zombie sh instances in System.Process In-Reply-To: <20080204183412.GB32486@scytale.galois.com> References: <47A1ADEE.80407@gmail.com> <90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com> <1508723353.20080131161308@gmail.com> <47A2D258.7050704@cse.unsw.edu.au> <47A2E9E6.6070208@cse.unsw.edu.au> <47A667F3.2020707@cse.unsw.edu.au> <384255A9-9192-45D1-9D05-7CCF4DF1D8C4@gmail.com> <2608b8a80802040319j34c5052eye3d70fd6d94e2ec1@mail.gmail.com> <20080204183412.GB32486@scytale.galois.com> Message-ID: <7A6A58B4-3E79-432B-AA0F-890A2815488E@gmail.com> Hmm... I thought I had been doing everything right, but now trying to reproduce this issue, I find I can't. It must have been the waitForProcess issue. Thanks for the advice, and sorry to trouble the list with this. --Sterl On Feb 4, 2008, at 1:34 PM, Don Stewart wrote: > gale: >> Sterling Clover wrote: >>> Even once the process I >>> was calling had terminated, and I had explicitly closed all its >>> buffers, a zombie sh process was left around from it. >> >> Make sure to call waitForProcess on each process handle >> when you are finished with it. > > Or even consider using say, newpopen, which wraps this up > for you, > > http://www.cse.unsw.edu.au/~dons/code/newpopen/ From cgibbard at gmail.com Tue Feb 5 00:03:38 2008 From: cgibbard at gmail.com (Cale Gibbard) Date: Tue Feb 5 00:02:43 2008 Subject: Minor issue with mapAccumR Message-ID: <89ca3d1f0802042103m3e72f6f7y3ad5f5552093ef5e@mail.gmail.com> I'm not sure whether this would be considered worth fixing right away, or if we should wait until some other major compatibility breaking language change to fix it, but it appears that somehow the parameters to the function passed to mapAccumR are flipped relative to their natural order. To show what I mean, here is some code: Prelude Data.List> mapAccumR (\x y -> (concat ["(f ",x," ",y,")"], concat ["(g ",x," ",y,")"])) "z" ["1","2","3"] ("(f (f (f z 3) 2) 1)",["(g (f (f z 3) 2) 1)","(g (f z 3) 2)","(g z 3)"]) You can see here that the list is flipped over in the process, even though the right fold structure is there, it ends up looking like a left fold over the reverse of the list. One would want the law: fst . mapAccumR f z = foldr (fst . f) z to be true, but instead we have: fst . mapAccumR (flip f) z = foldr (fst . f) z You can see that structurally if we flip the parameters in the above example: Prelude Data.List> mapAccumR (\y x -> (concat ["(f ",x," ",y,")"], concat ["(g ",x," ",y,")"])) "z" ["1","2","3"] ("(f 1 (f 2 (f 3 z)))",["(g 1 (f 2 (f 3 z)))","(g 2 (f 3 z))","(g 3 z)"]) I also have some diagrams on http://cale.yi.org/index.php/Fold_Diagrams (near the end) displaying the difference, and that's where I first noticed it. Are many people using mapAccumR? How much would it hurt to change it? - Cale From david at loisch.de Tue Feb 5 03:05:19 2008 From: david at loisch.de (David Leuschner) Date: Tue Feb 5 03:04:30 2008 Subject: darcs patch: Figure out timezone offset from timezone name In-Reply-To: <47A7E608.2030402@semantic.org> References: <20080202193633.GC23937@scytale.galois.com> <1201981751.13130.168.camel@localhost> <47A7E608.2030402@semantic.org> Message-ID: <20080205080519.GA14096@dl.factis.vpn> >> David and I have discussed this, and it seems like this hard-coded >> timezone database is in any case better than the current incorrect >> behavior. In the majority of cases it will do the right thing, instead >> of being almost always incorrect as it is now. I have pushed the patch >> now, but there are some improvements that could be made: > > I think this is wrong. Time-zones change quite frequently, and now any > program compiled with 'time' will be incorrect the next time some > government changes its zone. Which time zone is used at what time indeed changes frequently but I am not aware of any case where the meaning of a time zone _name_ changed. CEST always refers to +0200 although the periods during which this time zone is used changes. The patch doesn't try to figure out which time zone should be used for a certain place at a certain time. It only maps the names that are typically used to refer to time zones to their time offset. > Is there an alternative approach? Is there some way we can query the tz > database? I looked into this earlier but didn't find an obvious way. Querying the time zone database doesn't help in this case. It only provides information which time zone was (or should be) used at a certain place at a certain time. This patch changes only the way time zone names including a time zone name are parsed. Ambiguity really is a problem (and for that reason it would be best to not use time zone names at all). Quoting from a mail to Bj?rn: > Ambiguity of names really is a problem because PST can refer to "Pacific > Standard Time" which is -07:00 as well as "Pakistan Standard Time" which > is +05:00. But even here detailed time zone information doesn't provide > any help as the meaning doesn't depend on where the computer doing the > decoding is located but where the formatted timestamp originated > from. (And in which context it appeared. For example RFC822 clearly > indicates that PST should mean -07:00). To accomodate for this all > parsing functions should probably return lists of valid interpretations > but that would break the library interface. > > At the moment the library doesn't even indicate, that it could not > interpret the time zone and silently returns nonsense like > > TimeZone 0 False "CEST" > > which is just wrong because "CEST" has an offset of 120 minutes. As a final note PostgreSQL has excellent time and time zone handling and uses exactly this approach. They deal with ambiguity by allowing the database administrator to use localised mapping tables, see http://www.postgresql.org/docs/8.1/static/datetime-keywords.html Cheers, David -- David Leuschner Meisenweg 7 79211 Denzlingen Tel. 07666/912466 From ashley at semantic.org Tue Feb 5 03:20:36 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Tue Feb 5 03:19:39 2008 Subject: darcs patch: Figure out timezone offset from timezone name In-Reply-To: <20080205080519.GA14096@dl.factis.vpn> References: <20080202193633.GC23937@scytale.galois.com> <1201981751.13130.168.camel@localhost> <47A7E608.2030402@semantic.org> <20080205080519.GA14096@dl.factis.vpn> Message-ID: <47A81C54.2050502@semantic.org> David Leuschner wrote: > Which time zone is used at what time indeed changes frequently but I am > not aware of any case where the meaning of a time zone _name_ changed. What's your source for time-zone names? -- Ashley Yakeley From david at loisch.de Tue Feb 5 03:23:55 2008 From: david at loisch.de (David Leuschner) Date: Tue Feb 5 03:22:59 2008 Subject: darcs patch: Figure out timezone offset from timezone name In-Reply-To: <47A81C54.2050502@semantic.org> References: <20080202193633.GC23937@scytale.galois.com> <1201981751.13130.168.camel@localhost> <47A7E608.2030402@semantic.org> <20080205080519.GA14096@dl.factis.vpn> <47A81C54.2050502@semantic.org> Message-ID: <20080205082355.GB14096@dl.factis.vpn> >> Which time zone is used at what time indeed changes frequently but I am >> not aware of any case where the meaning of a time zone _name_ changed. > > What's your source for time-zone names? I just realised I forgot to add a comment in the patch. It's the table from the PostgreSQL manual http://www.postgresql.org/docs/8.1/static/datetime-keywords.html Cheers, David -- David Leuschner Meisenweg 7 79211 Denzlingen Tel. 07666/912466 From ashley at semantic.org Tue Feb 5 03:34:54 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Tue Feb 5 03:33:57 2008 Subject: darcs patch: Figure out timezone offset from timezone name In-Reply-To: <20080205082355.GB14096@dl.factis.vpn> References: <20080202193633.GC23937@scytale.galois.com> <1201981751.13130.168.camel@localhost> <47A7E608.2030402@semantic.org> <20080205080519.GA14096@dl.factis.vpn> <47A81C54.2050502@semantic.org> <20080205082355.GB14096@dl.factis.vpn> Message-ID: <1202200494.6723.32.camel@glastonbury> On Tue, 2008-02-05 at 09:23 +0100, David Leuschner wrote: > >> Which time zone is used at what time indeed changes frequently but I am > >> not aware of any case where the meaning of a time zone _name_ changed. > > > > What's your source for time-zone names? > > I just realised I forgot to add a comment in the patch. It's the table > from the PostgreSQL manual > > http://www.postgresql.org/docs/8.1/static/datetime-keywords.html OK, we should certainly include a link in the source. But why this particular set? Where did PostgreSQL get them from? I Googled and found this: http://www.worldtimezone.com/wtz-names/timezonenames.html http://www.worldtimezone.com/wtz-names/wtz-vet.html Venezuela Time certainly has changed offset. The question is, is "VET" somehow less standard as an abbreviation than the ones in the PostgreSQL list? Alternatively, are the ones listed less liable to change? -- Ashley Yakeley From simonmarhaskell at gmail.com Tue Feb 5 04:38:14 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Feb 5 04:37:19 2008 Subject: Readline read_history and write_history addition In-Reply-To: <6d74b0d20802041349v1597c25cq4fdd55f4c9a9b904@mail.gmail.com> References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> <2608b8a80801230435u6a18fb7bh1046cc446120d75@mail.gmail.com> <20080123125724.GA2912@matrix.chaos.earth.li> <2608b8a80801230519v72388283xf35f1de120571ca2@mail.gmail.com> <57526e770802021035u170e47cey77edea12eaa5c340@mail.gmail.com> <2608b8a80802021130i2b4486c3m74bc6ef7fdd2c425@mail.gmail.com> <6d74b0d20802021203x7ae35e0fjaee1a1c961731856@mail.gmail.com> <2608b8a80802021314k7bcbc643n22d4ee53e6506d73@mail.gmail.com> <47A6FCBE.4090101@gmail.com> <2608b8a80802040606mdb73f20n6090d1b437d5202@mail.gmail.com> <6d74b0d20802041349v1597c25cq4fdd55f4c9a9b904@mail.gmail.com> Message-ID: <47A82E86.2080300@gmail.com> Judah Jacobson wrote: > On Mon, Feb 4, 2008 at 6:06 AM, Yitzchak Gale wrote: >> Simon Marlow wrote: >> > However, I do agree that exceptions should generally be used for >> > exceptional conditions, rather than for general control-flow. This is an >> > example of a *good* reason to avoid an exception: because to use an >> > exception for a non-exceptional condition is poor style. >> >> That is also my opinion. Some people have disagreed. >> So this should be the focus of the decision then. > > I also agree that exceptions should only be used for exceptional > conditions; but I do think that this is one of those situations. I'll > try to explain why below. (Thanks, Yitzchak, for forking off the > thread about fixing limitations of MonadIO.) > > I assume that the following conditions are already considered > exceptional (I haven't ever heard anyone complain that they throw an > exception): > - readFile : read a nonexistent file > - writeFile : write to a file in a nonexistent directory > - getEnv: retrieve an unset environmental variable FWIW, this was hotly debated at the time, and I do believe we made the wrong decision w.r.t. getEnv, mainly because I always end up writing "try $ getEnv", or I forget the try and have to fix the bug later. Cheers, Simon From david at loisch.de Tue Feb 5 07:26:25 2008 From: david at loisch.de (David Leuschner) Date: Tue Feb 5 07:25:30 2008 Subject: darcs patch: Figure out timezone offset from timezone name In-Reply-To: <1202200494.6723.32.camel@glastonbury> References: <20080202193633.GC23937@scytale.galois.com> <1201981751.13130.168.camel@localhost> <47A7E608.2030402@semantic.org> <20080205080519.GA14096@dl.factis.vpn> <47A81C54.2050502@semantic.org> <20080205082355.GB14096@dl.factis.vpn> <1202200494.6723.32.camel@glastonbury> Message-ID: <20080205122625.GC14096@dl.factis.vpn> > > I just realised I forgot to add a comment in the patch. It's the table > > from the PostgreSQL manual > > > > http://www.postgresql.org/docs/8.1/static/datetime-keywords.html > > OK, we should certainly include a link in the source. But why this > particular set? Where did PostgreSQL get them from? > > I Googled and found this: > http://www.worldtimezone.com/wtz-names/timezonenames.html > http://www.worldtimezone.com/wtz-names/wtz-vet.html > > Venezuela Time certainly has changed offset. The question is, is "VET" > somehow less standard as an abbreviation than the ones in the PostgreSQL > list? The meaning of some abbreviations in specified in RFCs (for example RFC822 defines EST,EDT,CST,CDT,MST,MDT,PST,PDT,GMT and UT). I think the important point is, that the patch doesn't break anything. Previously the time module returned wrong time offsets for EVERY timezone name except UT and GMT. The patch improves on this by returning a time zone offset that most probably is correct. Due to ambiguity and the obviously very seldom occuring changes in the meaning of time zone names (probably the ones in the list won't be affected anyway) the new code might also return a wrong value. But for all those cases the old code would have returned a wrong value anyway. I think it's better to get it right most of the times than to always return the wrong values. It would be even better if we would return lists of possible interpretations and let the user decide which interpretation to choose. But that would require a major API change. Cheers, David -- David Leuschner Meisenweg 7 79211 Denzlingen Tel. 07666/912466 From gale at sefer.org Tue Feb 5 08:56:09 2008 From: gale at sefer.org (Yitzchak Gale) Date: Tue Feb 5 08:55:11 2008 Subject: Fixing MonadIO In-Reply-To: <6d74b0d20802041653ldb3c285o95b4158da4a0a4ac@mail.gmail.com> References: <2608b8a80802040659wef2d357j537e601d0b1ad5bb@mail.gmail.com> <47A73C6E.1090600@gmail.com> <6d74b0d20802041653ldb3c285o95b4158da4a0a4ac@mail.gmail.com> Message-ID: <2608b8a80802050556t7b3e4eaejda2eb907769b67ef@mail.gmail.com> Simon Marlow wrote: >> The new module >> could be provided as Control.Monad.IO.Exception (for example) in the mtl >> package... this seems like the smoothest way to address the problem. Judah Jacobson wrote: > Of the three possibilities listed by Yitzchak, I'm most in favor of > adding Brian Hulley's module to the mtl package. (In particular, I've > decided that I like it more than my own, earlier proposal.) The comments in Brian Hulley's module warn that we need to address some issues raised by Oleg before actually adopting this proposal. I'll be out for a few days, I'll try to look at it after that if no one else gets to it. Thanks, Yitz From lemming at henning-thielemann.de Tue Feb 5 09:25:12 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Feb 5 09:24:19 2008 Subject: Minor issue with mapAccumR In-Reply-To: <89ca3d1f0802042103m3e72f6f7y3ad5f5552093ef5e@mail.gmail.com> References: <89ca3d1f0802042103m3e72f6f7y3ad5f5552093ef5e@mail.gmail.com> Message-ID: On Tue, 5 Feb 2008, Cale Gibbard wrote: > Are many people using mapAccumR? How much would it hurt to change it? I cannot remember having ever used mapAccumR, but I used mapAccumL where I used mapM on State monad before, in order to avoid dependency on MTL (and thus non-Haskell-98 features). From valery.vv at gmail.com Tue Feb 5 12:02:48 2008 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Tue Feb 5 12:01:51 2008 Subject: lambdabot setup Message-ID: Dear, lazy programmers, Please let me know the proper place to report lambdabot bugs, and feel free to ignore the rest of message. Are you still reading? In this case you may want to know that *** I've successfully installed lambdabot with GHC 6.9! :) *** Kudos to Cale & the IRC crowd for making my day [http://tunes.org/~nef/logs/haskell/08.02.04]. Boring part: $ darcs get http://code.haskell.org/lambdabot $ cd lambdabot $ runhaskell Setup configure --prefix=$HOME --user $ runhaskell Setup build $ touch LICENSE # see the patch attached $ runhaskell Setup install Interesting part: $ lambdabot -e 'hoogle map' Initialising plugins ...........Plugin.Djinn: couldn't find djinn binary ...........................sending message to bogus server: IrcMessage {msgServer = "freenode", msgLBName = "urk!", msgPrefix = "", msgCommand = "NAMES", msgParams = [""]} .................. done. A Hoogle error occured. Exception: all servers detached exception: State/seen: openBinaryFile: does not exist (No such file or directory) $ hoogle map Could not find hoogle database, looked for: hoogle.txt In order to make `hoogle' binary usable, one should copy `hoogle.txt' file to "$(dirname $(which hoogle))/" directory: $ cp State/hoogle.txt ~/bin/ # FIXME $ hoogle map [...success...] To my believe, it's a package's responsibility to copy data files to proper locations (during `runhaskell Setup install' step). And hoogle _plugin_ still doesn't work though. $ lambdabot Initialising plugins ...........Plugin.Djinn: couldn't find djinn binary ...........................sending message to bogus server: IrcMessage {msgServer = "freenode", msgLBName = "urk!", msgPrefix = "", msgCommand = "NAMES", msgParams = [""]} .................. done. lambdabot> hoogle map A Hoogle error occured. lambdabot> lambdabot: user error () Exception: all servers detached Thank you. -- vvv PS: Tue Feb 5 18:38:55 EET 2008 "Valery V. Vorotyntsev" * `LICENSE' file added Tue Feb 5 18:37:12 EET 2008 "Valery V. Vorotyntsev" * lambdabot.cabal: add `build-type' to make Cabal happy -------------- next part -------------- New patches: [lambdabot.cabal: add `build-type' to make Cabal happy "Valery V. Vorotyntsev" **20080205163712] { hunk ./lambdabot.cabal 19 +build-type: Simple } [`LICENSE' file added "Valery V. Vorotyntsev" **20080205163855] { addfile ./LICENSE hunk ./LICENSE 1 + GNU LESSER GENERAL PUBLIC LICENSE + Version 2.1, February 1999 + + Copyright (C) 1991, 1999 Free Software Foundation, Inc. + 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + +[This is the first released version of the Lesser GPL. It also counts + as the successor of the GNU Library Public License, version 2, hence + the version number 2.1.] + + Preamble + + The licenses for most software are designed to take away your +freedom to share and change it. By contrast, the GNU General Public +Licenses are intended to guarantee your freedom to share and change +free software--to make sure the software is free for all its users. + + This license, the Lesser General Public License, applies to some +specially designated software packages--typically libraries--of the +Free Software Foundation and other authors who decide to use it. You +can use it too, but we suggest you first think carefully about whether +this license or the ordinary General Public License is the better +strategy to use in any particular case, based on the explanations below. + + When we speak of free software, we are referring to freedom of use, +not price. Our General Public Licenses are designed to make sure that +you have the freedom to distribute copies of free software (and charge +for this service if you wish); that you receive source code or can get +it if you want it; that you can change the software and use pieces of +it in new free programs; and that you are informed that you can do +these things. + + To protect your rights, we need to make restrictions that forbid +distributors to deny you these rights or to ask you to surrender these +rights. These restrictions translate to certain responsibilities for +you if you distribute copies of the library or if you modify it. + + For example, if you distribute copies of the library, whether gratis +or for a fee, you must give the recipients all the rights that we gave +you. You must make sure that they, too, receive or can get the source +code. If you link other code with the library, you must provide +complete object files to the recipients, so that they can relink them +with the library after making changes to the library and recompiling +it. And you must show them these terms so they know their rights. + + We protect your rights with a two-step method: (1) we copyright the +library, and (2) we offer you this license, which gives you legal +permission to copy, distribute and/or modify the library. + + To protect each distributor, we want to make it very clear that +there is no warranty for the free library. Also, if the library is +modified by someone else and passed on, the recipients should know +that what they have is not the original version, so that the original +author's reputation will not be affected by problems that might be +introduced by others. + + Finally, software patents pose a constant threat to the existence of +any free program. We wish to make sure that a company cannot +effectively restrict the users of a free program by obtaining a +restrictive license from a patent holder. Therefore, we insist that +any patent license obtained for a version of the library must be +consistent with the full freedom of use specified in this license. + + Most GNU software, including some libraries, is covered by the +ordinary GNU General Public License. This license, the GNU Lesser +General Public License, applies to certain designated libraries, and +is quite different from the ordinary General Public License. We use +this license for certain libraries in order to permit linking those +libraries into non-free programs. + + When a program is linked with a library, whether statically or using +a shared library, the combination of the two is legally speaking a +combined work, a derivative of the original library. The ordinary +General Public License therefore permits such linking only if the +entire combination fits its criteria of freedom. The Lesser General +Public License permits more lax criteria for linking other code with +the library. + + We call this license the "Lesser" General Public License because it +does Less to protect the user's freedom than the ordinary General +Public License. It also provides other free software developers Less +of an advantage over competing non-free programs. These disadvantages +are the reason we use the ordinary General Public License for many +libraries. However, the Lesser license provides advantages in certain +special circumstances. + + For example, on rare occasions, there may be a special need to +encourage the widest possible use of a certain library, so that it becomes +a de-facto standard. To achieve this, non-free programs must be +allowed to use the library. A more frequent case is that a free +library does the same job as widely used non-free libraries. In this +case, there is little to gain by limiting the free library to free +software only, so we use the Lesser General Public License. + + In other cases, permission to use a particular library in non-free +programs enables a greater number of people to use a large body of +free software. For example, permission to use the GNU C Library in +non-free programs enables many more people to use the whole GNU +operating system, as well as its variant, the GNU/Linux operating +system. + + Although the Lesser General Public License is Less protective of the +users' freedom, it does ensure that the user of a program that is +linked with the Library has the freedom and the wherewithal to run +that program using a modified version of the Library. + + The precise terms and conditions for copying, distribution and +modification follow. Pay close attention to the difference between a +"work based on the library" and a "work that uses the library". The +former contains code derived from the library, whereas the latter must +be combined with the library in order to run. + + GNU LESSER GENERAL PUBLIC LICENSE + TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION + + 0. This License Agreement applies to any software library or other +program which contains a notice placed by the copyright holder or +other authorized party saying it may be distributed under the terms of +this Lesser General Public License (also called "this License"). +Each licensee is addressed as "you". + + A "library" means a collection of software functions and/or data +prepared so as to be conveniently linked with application programs +(which use some of those functions and data) to form executables. + + The "Library", below, refers to any such software library or work +which has been distributed under these terms. A "work based on the +Library" means either the Library or any derivative work under +copyright law: that is to say, a work containing the Library or a +portion of it, either verbatim or with modifications and/or translated +straightforwardly into another language. (Hereinafter, translation is +included without limitation in the term "modification".) + + "Source code" for a work means the preferred form of the work for +making modifications to it. For a library, complete source code means +all the source code for all modules it contains, plus any associated +interface definition files, plus the scripts used to control compilation +and installation of the library. + + Activities other than copying, distribution and modification are not +covered by this License; they are outside its scope. The act of +running a program using the Library is not restricted, and output from +such a program is covered only if its contents constitute a work based +on the Library (independent of the use of the Library in a tool for +writing it). Whether that is true depends on what the Library does +and what the program that uses the Library does. + + 1. You may copy and distribute verbatim copies of the Library's +complete source code as you receive it, in any medium, provided that +you conspicuously and appropriately publish on each copy an +appropriate copyright notice and disclaimer of warranty; keep intact +all the notices that refer to this License and to the absence of any +warranty; and distribute a copy of this License along with the +Library. + + You may charge a fee for the physical act of transferring a copy, +and you may at your option offer warranty protection in exchange for a +fee. + + 2. You may modify your copy or copies of the Library or any portion +of it, thus forming a work based on the Library, and copy and +distribute such modifications or work under the terms of Section 1 +above, provided that you also meet all of these conditions: + + a) The modified work must itself be a software library. + + b) You must cause the files modified to carry prominent notices + stating that you changed the files and the date of any change. + + c) You must cause the whole of the work to be licensed at no + charge to all third parties under the terms of this License. + + d) If a facility in the modified Library refers to a function or a + table of data to be supplied by an application program that uses + the facility, other than as an argument passed when the facility + is invoked, then you must make a good faith effort to ensure that, + in the event an application does not supply such function or + table, the facility still operates, and performs whatever part of + its purpose remains meaningful. + + (For example, a function in a library to compute square roots has + a purpose that is entirely well-defined independent of the + application. Therefore, Subsection 2d requires that any + application-supplied function or table used by this function must + be optional: if the application does not supply it, the square + root function must still compute square roots.) + +These requirements apply to the modified work as a whole. If +identifiable sections of that work are not derived from the Library, +and can be reasonably considered independent and separate works in +themselves, then this License, and its terms, do not apply to those +sections when you distribute them as separate works. But when you +distribute the same sections as part of a whole which is a work based +on the Library, the distribution of the whole must be on the terms of +this License, whose permissions for other licensees extend to the +entire whole, and thus to each and every part regardless of who wrote +it. + +Thus, it is not the intent of this section to claim rights or contest +your rights to work written entirely by you; rather, the intent is to +exercise the right to control the distribution of derivative or +collective works based on the Library. + +In addition, mere aggregation of another work not based on the Library +with the Library (or with a work based on the Library) on a volume of +a storage or distribution medium does not bring the other work under +the scope of this License. + + 3. You may opt to apply the terms of the ordinary GNU General Public +License instead of this License to a given copy of the Library. To do +this, you must alter all the notices that refer to this License, so +that they refer to the ordinary GNU General Public License, version 2, +instead of to this License. (If a newer version than version 2 of the +ordinary GNU General Public License has appeared, then you can specify +that version instead if you wish.) Do not make any other change in +these notices. + + Once this change is made in a given copy, it is irreversible for +that copy, so the ordinary GNU General Public License applies to all +subsequent copies and derivative works made from that copy. + + This option is useful when you wish to copy part of the code of +the Library into a program that is not a library. + + 4. You may copy and distribute the Library (or a portion or +derivative of it, under Section 2) in object code or executable form +under the terms of Sections 1 and 2 above provided that you accompany +it with the complete corresponding machine-readable source code, which +must be distributed under the terms of Sections 1 and 2 above on a +medium customarily used for software interchange. + + If distribution of object code is made by offering access to copy +from a designated place, then offering equivalent access to copy the +source code from the same place satisfies the requirement to +distribute the source code, even though third parties are not +compelled to copy the source along with the object code. + + 5. A program that contains no derivative of any portion of the +Library, but is designed to work with the Library by being compiled or +linked with it, is called a "work that uses the Library". Such a +work, in isolation, is not a derivative work of the Library, and +therefore falls outside the scope of this License. + + However, linking a "work that uses the Library" with the Library +creates an executable that is a derivative of the Library (because it +contains portions of the Library), rather than a "work that uses the +library". The executable is therefore covered by this License. +Section 6 states terms for distribution of such executables. + + When a "work that uses the Library" uses material from a header file +that is part of the Library, the object code for the work may be a +derivative work of the Library even though the source code is not. +Whether this is true is especially significant if the work can be +linked without the Library, or if the work is itself a library. The +threshold for this to be true is not precisely defined by law. + + If such an object file uses only numerical parameters, data +structure layouts and accessors, and small macros and small inline +functions (ten lines or less in length), then the use of the object +file is unrestricted, regardless of whether it is legally a derivative +work. (Executables containing this object code plus portions of the +Library will still fall under Section 6.) + + Otherwise, if the work is a derivative of the Library, you may +distribute the object code for the work under the terms of Section 6. +Any executables containing that work also fall under Section 6, +whether or not they are linked directly with the Library itself. + + 6. As an exception to the Sections above, you may also combine or +link a "work that uses the Library" with the Library to produce a +work containing portions of the Library, and distribute that work +under terms of your choice, provided that the terms permit +modification of the work for the customer's own use and reverse +engineering for debugging such modifications. + + You must give prominent notice with each copy of the work that the +Library is used in it and that the Library and its use are covered by +this License. You must supply a copy of this License. If the work +during execution displays copyright notices, you must include the +copyright notice for the Library among them, as well as a reference +directing the user to the copy of this License. Also, you must do one +of these things: + + a) Accompany the work with the complete corresponding + machine-readable source code for the Library including whatever + changes were used in the work (which must be distributed under + Sections 1 and 2 above); and, if the work is an executable linked + with the Library, with the complete machine-readable "work that + uses the Library", as object code and/or source code, so that the + user can modify the Library and then relink to produce a modified + executable containing the modified Library. (It is understood + that the user who changes the contents of definitions files in the + Library will not necessarily be able to recompile the application + to use the modified definitions.) + + b) Use a suitable shared library mechanism for linking with the + Library. A suitable mechanism is one that (1) uses at run time a + copy of the library already present on the user's computer system, + rather than copying library functions into the executable, and (2) + will operate properly with a modified version of the library, if + the user installs one, as long as the modified version is + interface-compatible with the version that the work was made with. + + c) Accompany the work with a written offer, valid for at + least three years, to give the same user the materials + specified in Subsection 6a, above, for a charge no more + than the cost of performing this distribution. + + d) If distribution of the work is made by offering access to copy + from a designated place, offer equivalent access to copy the above + specified materials from the same place. + + e) Verify that the user has already received a copy of these + materials or that you have already sent this user a copy. + + For an executable, the required form of the "work that uses the +Library" must include any data and utility programs needed for +reproducing the executable from it. However, as a special exception, +the materials to be distributed need not include anything that is +normally distributed (in either source or binary form) with the major +components (compiler, kernel, and so on) of the operating system on +which the executable runs, unless that component itself accompanies +the executable. + + It may happen that this requirement contradicts the license +restrictions of other proprietary libraries that do not normally +accompany the operating system. Such a contradiction means you cannot +use both them and the Library together in an executable that you +distribute. + + 7. You may place library facilities that are a work based on the +Library side-by-side in a single library together with other library +facilities not covered by this License, and distribute such a combined +library, provided that the separate distribution of the work based on +the Library and of the other library facilities is otherwise +permitted, and provided that you do these two things: + + a) Accompany the combined library with a copy of the same work + based on the Library, uncombined with any other library + facilities. This must be distributed under the terms of the + Sections above. + + b) Give prominent notice with the combined library of the fact + that part of it is a work based on the Library, and explaining + where to find the accompanying uncombined form of the same work. + + 8. You may not copy, modify, sublicense, link with, or distribute +the Library except as expressly provided under this License. Any +attempt otherwise to copy, modify, sublicense, link with, or +distribute the Library is void, and will automatically terminate your +rights under this License. However, parties who have received copies, +or rights, from you under this License will not have their licenses +terminated so long as such parties remain in full compliance. + + 9. You are not required to accept this License, since you have not +signed it. However, nothing else grants you permission to modify or +distribute the Library or its derivative works. These actions are +prohibited by law if you do not accept this License. Therefore, by +modifying or distributing the Library (or any work based on the +Library), you indicate your acceptance of this License to do so, and +all its terms and conditions for copying, distributing or modifying +the Library or works based on it. + + 10. Each time you redistribute the Library (or any work based on the +Library), the recipient automatically receives a license from the +original licensor to copy, distribute, link with or modify the Library +subject to these terms and conditions. You may not impose any further +restrictions on the recipients' exercise of the rights granted herein. +You are not responsible for enforcing compliance by third parties with +this License. + + 11. If, as a consequence of a court judgment or allegation of patent +infringement or for any other reason (not limited to patent issues), +conditions are imposed on you (whether by court order, agreement or +otherwise) that contradict the conditions of this License, they do not +excuse you from the conditions of this License. If you cannot +distribute so as to satisfy simultaneously your obligations under this +License and any other pertinent obligations, then as a consequence you +may not distribute the Library at all. For example, if a patent +license would not permit royalty-free redistribution of the Library by +all those who receive copies directly or indirectly through you, then +the only way you could satisfy both it and this License would be to +refrain entirely from distribution of the Library. + +If any portion of this section is held invalid or unenforceable under any +particular circumstance, the balance of the section is intended to apply, +and the section as a whole is intended to apply in other circumstances. + +It is not the purpose of this section to induce you to infringe any +patents or other property right claims or to contest validity of any +such claims; this section has the sole purpose of protecting the +integrity of the free software distribution system which is +implemented by public license practices. Many people have made +generous contributions to the wide range of software distributed +through that system in reliance on consistent application of that +system; it is up to the author/donor to decide if he or she is willing +to distribute software through any other system and a licensee cannot +impose that choice. + +This section is intended to make thoroughly clear what is believed to +be a consequence of the rest of this License. + + 12. If the distribution and/or use of the Library is restricted in +certain countries either by patents or by copyrighted interfaces, the +original copyright holder who places the Library under this License may add +an explicit geographical distribution limitation excluding those countries, +so that distribution is permitted only in or among countries not thus +excluded. In such case, this License incorporates the limitation as if +written in the body of this License. + + 13. The Free Software Foundation may publish revised and/or new +versions of the Lesser General Public License from time to time. +Such new versions will be similar in spirit to the present version, +but may differ in detail to address new problems or concerns. + +Each version is given a distinguishing version number. If the Library +specifies a version number of this License which applies to it and +"any later version", you have the option of following the terms and +conditions either of that version or of any later version published by +the Free Software Foundation. If the Library does not specify a +license version number, you may choose any version ever published by +the Free Software Foundation. + + 14. If you wish to incorporate parts of the Library into other free +programs whose distribution conditions are incompatible with these, +write to the author to ask for permission. For software which is +copyrighted by the Free Software Foundation, write to the Free +Software Foundation; we sometimes make exceptions for this. Our +decision will be guided by the two goals of preserving the free status +of all derivatives of our free software and of promoting the sharing +and reuse of software generally. + + NO WARRANTY + + 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO +WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. +EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR +OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY +KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE +IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR +PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE +LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME +THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. + + 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN +WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY +AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU +FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR +CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE +LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING +RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A +FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF +SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH +DAMAGES. + + END OF TERMS AND CONDITIONS + + How to Apply These Terms to Your New Libraries + + If you develop a new library, and you want it to be of the greatest +possible use to the public, we recommend making it free software that +everyone can redistribute and change. You can do so by permitting +redistribution under these terms (or, alternatively, under the terms of the +ordinary General Public License). + + To apply these terms, attach the following notices to the library. It is +safest to attach them to the start of each source file to most effectively +convey the exclusion of warranty; and each file should have at least the +"copyright" line and a pointer to where the full notice is found. + + + Copyright (C) + + This library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version. + + This library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public + License along with this library; if not, write to the Free Software + Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + +Also add information on how to contact you by electronic and paper mail. + +You should also get your employer (if you work as a programmer) or your +school, if any, to sign a "copyright disclaimer" for the library, if +necessary. Here is a sample; alter the names: + + Yoyodyne, Inc., hereby disclaims all copyright interest in the + library `Frob' (a library for tweaking knobs) written by James Random Hacker. + + , 1 April 1990 + Ty Coon, President of Vice + +That's all there is to it! + + } Context: [Frivolous patch to increase my own karma for fixing lambdabot. cgibbard@gmail.com**20080205043406] [Fix link error in runplugs (oeis). cgibbard@gmail.com**20080205032325] [Updates for 6.8.2 cgibbard@gmail.com**20080204222435] [Changed unMtl to be easier to extend and improved its error reporting Twan van Laarhoven **20080202032202] [Added SimpleReflect module for use with @run Twan van Laarhoven **20080131231830] [Make Math.OEIS and Data.Number.* available to RunPlugs Spencer Janssen **20080115231752 NOTE: the 'numbers' and 'oeis' packages are now required (available on hackage) ] [Hide Text.PrettyPrint.HughesPJ.empty Spencer Janssen **20071220233246] [Hide Control.Arrow.pure in @run Spencer Janssen **20071220233026] [Add an alias for @slap, @smack Spencer Janssen **20071213113951] [update hoogl db dons@galois.com**20071206225344] [Lib.Util.timeout: kill threads asynchronously, hopefully this fixes the mysterious hanging bug Spencer Janssen **20071205070311] [Remove silly kind signature Spencer Janssen **20071205065359] [sync logs dons@cse.unsw.edu.au**20071111201729] [Add Math.OEIS to L.hs, and oeis to build-depends. cgibbard@gmail.com**20071111021348] [Added plugin for Math.OEIS. The (slightly modified) library is included itself as well. Twan van Laarhoven **20071105200558] [Offline loop quits when the quit command is used Twan van Laarhoven **20071102163236] [Fixed parentheses handling for @@ parser Twan van Laarhoven **20071102162703] [The ?? and @@ commands are no longer ignored Twan van Laarhoven **20071102162519] [@brain: replies from pinky now separated from the rest Twan van Laarhoven **20071027214524] [Lib.Util.getRandItem: return a valid generator when the list is empty. This Spencer Janssen **20071027093656 is part of an attempt to cover all our bases with the persistent getRandItem bug. ] [Add safeGetStdRandom, hopefully this fixes the "getRandItem" bug. Spencer Janssen **20071027061439] [README should point to the released version of zlib Spencer Janssen **20071001160556] ['??' plugin didn't add a space in front of output Twan van Laarhoven **20071024182421] [Fixed broken Type error handling because of previous patch Twan van Laarhoven **20071024165429] [Type plugin postprocessing simplified; now uses ghci -v0 Twan van Laarhoven **20071024144408] [Fixed gender issues in slap plugin, added some more variation twanvl@gmail.com**20071022222929] [Lib.Parser now understands comments, this is allowed: -- :) twanvl@gmail.com**20071018153703] [Redo understands case expressions as created by undo twanvl@gmail.com**20071016214523] [Nicer error messages for parseExpr, compose plugin and exceptions twanvl@gmail.com**20071016214427] [Fixed pattern match failure in parseExpr twanvl@gmail.com**20071016214302] [Added new rules to Pl to handle things like nested "(f `ap`) . const" constructions. These are produced by for instance "\(x:_:_) -> x" twanvl@gmail.com**20071016173629] [Undo now desugars list comprehensions twanvl@gmail.com**20071016002003] [Moved common expression and declaration parsing to Lib.Parser; improved balanced paren check twanvl@gmail.com**20071015232209] [Split up Pl\Rules into three files to make it a little easier to understand twanvl@gmail.com**20071015214400] [More commenting of Pl twanvl@gmail.com**20071015205616] [Added more advanced way of composing plugins twanvl@gmail.com**20071015004758] [Added comments to Pl code in my attempt to understand it twanvl@gmail.com**20071015004725] [Worked around the lack of readline on windows, added a very simple replacement twanvl@gmail.com**20071015004544] [Some more creativity in insults and confirmation messages twanvl@gmail.com**20071015004425] [sync state dons@cse.unsw.edu.au**20070816045835] [chans dons@cse.unsw.edu.au**20070816045619] [sort some chans dons@cse.unsw.edu.au**20070816045422] [Fixed instance Ord Nick so it'll actually work this time svein.ove@aas.no**20070803224228] [Instance Ord for Nick svein.ove@aas.no**20070803200628 Overriding Eq but not Ord meant that Foo > FOO is true, but so is FOO == FOO. This patch fixes it by overriding Ord to behave the same way. ] [IRC nicknames are case-insensitive svein.ove@aas.no**20070802132816] [Remove the Arbitrary instance for Maybe; it is rarely used, and conflicts with an instance in the 6.6.1 QuickCheck Stefan O'Rear **20070731044211] [finish implementing "forget" Stefan O'Rear **20070731044151] [Use a thin wrapper over haskell-src instead of trying to build on the undocumented internal haskell-src functions. Should increase robustness. Stefan O'Rear **20070731044106] [Add @forget to remove quotes (unpriviledged by analogy with @where+ lambdabot ) Stefan O'Rear **20070628165142] [Fix functions name clash in Lib/Parser.hs Paolo Martini **20070725231055] [update channel list dons@cse.unsw.edu.au**20070725033113] [only have @state disabled dons@cse.unsw.edu.au**20070725033021] [Fixed very small cpphs issue in Lib/Parser.* Christophe Poucet **20070718113647] [Fixed problems with DarcsPatchWatch Christophe Poucet **20070719101737] [Convert vixen's data to new 64-bit Binary format, including code used (in comments) Samuel Bronson **20070628155642] [give a helpful message when user types "make" instead of deleting stuff Samuel Bronson **20070628143453] [fix unary negation in Pl parser cdsmith@twu.net**20070620052142] [and hide Traversable dons@cse.unsw.edu.au**20070619041024] [update the .rc files dons@cse.unsw.edu.au**20070619035426] [some state patches dons@cse.unsw.edu.au**20070304044741] [add online2.rc dons@cse.unsw.edu.au**20070304044712] [update online.rc dons@cse.unsw.edu.au**20070304044636] [Ignore a trailing : in nicknames mail@joachim-breitner.de**20070616181123 A usecase for @tell is: > dons: Something important then noticing that dons is not there, adding a @tell in the beginning > @tell dons: Something important And generally it is nice to be able to write: > @tell someone: something So the attaced patch ignores trailing : for nicknames (which are invalid anyways). ] [Make lambdabot more polite (respond to thanks) mail@joachim-breitner.de**20070616103520] [@type: remove Data.Traversable import, it clashes with Prelude names Spencer Janssen **20070603071205] [Make "active" in @users consider last 30 minutes Jason Creighton **20070519011539] [RunPlugs: fix Control.Monad.Writer import Spencer Janssen **20070510211608] [Fix @redo and infix applications Spencer Janssen **20070507013557] [import Monad.Writer qualified Don Stewart **20070507010118] [Resync djinn from darcs head Don Stewart **20070507010101] [add #ai channel and ignore the ai-depot bot there. Bertram Felgenhauer **20070328181145] [Implement a simple ignore command for lambdabot Bertram Felgenhauer **20070328180812 This patch adds an 'ignore' command similar to the existing 'admin' command. Right now it matches users per string match, not per mask so that it is ineffective against malicious users; it does, however, work for friendly ignores - like other bots. ] [make @wiki translate spaces to underscores Jason Creighton **20070313012928] [account for infix decls in precedence fixing cdsmith@twu.net**20070506202446] [update-prec-unpl-and-undo cdsmith@twu.net**20070506150342] [prec-unpl.patch cdsmith@twu.net**20070506044357 This fixes precedence problems in unpl, by adding a step that transforms the parsed grammar to obey precedence rules. As of right now: 1. Only operators from the Prelude are counted. 2. Precedence is not fixed in let bindings 3. Infix operators in patterns don't work. ] [the first lambdabot plugin I wrote, circa 2004. aFind the temperature in Sydney dons@cse.unsw.edu.au**20070304041525] [obsolete seen state dons@cse.unsw.edu.au**20070304041426] [import Prelude hiding (mapM, sequence, mapM_, sequence_) Don Stewart **20070224012936] [Add @hackage Spencer Janssen **20070222010141] [@src gracefully handles operators with or without parens Spencer Janssen **20070221052035] [the Text.Regex module has changed.. Don Stewart **20070214062236] [merge depends dons@cse.unsw.edu.au**20070214023739] [win32BuildHacks newsham@lava.net**20070207080647] [win32Hacks newsham@lava.net**20070207080524] [-fasm Don Stewart **20070214002425] [add IntMap Don Stewart **20070213232026] [don't need template-haskell package now Don Stewart **20070211235116] [make L.hs visible to @type, really Don Stewart **20070211235050] [use -fextended-default-rules to avoid extra type annotatoins in irc Don Stewart **20070211234346] [make L.hs visible to :t Don Stewart **20070211234334] [h98 be gone! Don Stewart **20070211233012] [ditch TH Don Stewart **20070211233002] [Bring in a bunch of new things Don Stewart **20070211232946] [make ghc 6.6 + runplugs the default build strategy now Don Stewart **20070211223919] [Make ?unmtl support trailing comments Lennart Kolmodin **20070205205945 Before: ?unmtl State Int a -- wazza!?!? err: Unterminated end-of-line comment Now: ?unmtl State Int a Int -> (a, Int) ] [merge dons@cse.unsw.edu.au**20070125234527] [Use hpaste's pretty domain name Spencer Janssen **20070124053632] [Factor string constant into pastebinMsg. Spencer Janssen **20070124053545] [Intercept "lisppaste2: url" and respond with hpaste! Spencer Janssen **20070124052505] [UnMtl should join tuples when possible Lennart Kolmodin **20070124104855] [UnMtl should curry if possible Lennart Kolmodin **20070124104811] [Add UnMtl module Lennart Kolmodin **20070123221755] [shorter Don Stewart **20070123203735] [hpaste Don Stewart **20070123103738] [fix type errors believed to result from binary changes stefanor@cox.net*-20070113064049] [Lie about BotPP's language dependencies, for the sake of shim Stefan O'Rear *-20070121095331] [add dyndns short url for hpaste Stefan O'Rear **20070121210957] [Lie about BotPP's language dependencies, for the sake of shim Stefan O'Rear **20070121095331] [add support for a polynick to have | separated terms Stefan O'Rear **20070122060825] [add NickEq support to Karma Stefan O'Rear **20070122055045] [nick identity, act 1 - the base API Stefan O'Rear **20070122040126] [No response for @seen in channel Spencer Janssen **20070122064822] [Plugin.Karma: minor cosmetic change. Spencer Janssen **20070119164230] [pastebin has moved again Stefan O'Rear **20070120004657] [split optimizer out of Plugin.Pl.Transform Stefan O'Rear **20070116035506] [Make -- comments work in @unpl Spencer Janssen **20070116033328] [make @paste use glguy's amazing Haskell-hosted pastebin Stefan O'Rear **20070118232735] [make last patch compile & work Stefan O'Rear **20070115190136] [make @seen not ping entire channels Stefan O'Rear **20070115185300] [a few small doc updates Stefan O'Rear **20070115185211] [claim more credit Stefan O'Rear **20070115104105] [create a admin-only @activity-full ; obscure usernames in normal @activity Stefan O'Rear **20070115103956] [fix admin list in online.rc Stefan O'Rear **20070115102829] [default to offline mode Stefan O'Rear **20070115101911] [use older System.Time in Activity (I failed a check-compatibility check) Stefan O'Rear **20070115094230] [centralize QSem waiting, fixes serious race condition Stefan O'Rear **20070114220920 This creates a single MVar for IRC flood control, which is filled at a predictable rate by the semaphore code. This allows the semaphores to be used only from the safe fill loops; previously the semaphores were waited on in plugin context, causing deadlocks when waitQSem was interrupted. ] [add a little strictness to fix Activity Stefan O'Rear **20070114052638] [only ask for topic in response to our joining ; should give much better netsplit performance Stefan O'Rear **20070113230626] [use new time library in Activity ; fix interval bug stefanor@cox.net**20070113064132] [fix type errors believed to result from binary changes stefanor@cox.net**20070113064049] [remove State/passwd support (forgotten in previous config-sweep) stefanor@cox.net**20070113010612] [rename OfflineRC.source to rc (fixes embarassing collision) stefanor@cox.net**20070113004912 The current expected method of initalizing lambdabot is: lambdabot -e 'rc online.rc' online.rc contains commands for server connection, joining, admin setup, and sources 'passwd.rc' which is expected to contain a 'msg freenode:nickserv identify foobar' commmand. ] [Lambdabot now depends on 'binary' Don Stewart **20070112125037 Toss out the old newBinary, in favour of 'binary'. darcs get http://darcs.haskell.org/binary Note that you'll have to remove the State/seen file, since it uses a new binary encoding. ] [remove from Config.hs all that is currently subsumed by rc-files stefanor@cox.net**20070112015056] [reverse-sort @activity stefanor@cox.net**20070111050140] [add @listservers, @admin stefanor@cox.net**20070111050106] [sign on synchronously, fixes a race stefanor@cox.net**20070111044427] [I ought to typecheck before sending :( stefanor@cox.net**20070111043845] [add 'source' command, to load a rcfile: lambdabot -e 'source online.rc' stefanor@cox.net**20070111043215] [remove core IRC stefanor@cox.net**20070109053326 This patch removes the core's IRC and readline modules; you are now expected to use the plugin versions instead: lambdabot -e offline # use the readline interface lambdabot -e 'irc-connect freenode chat.freenode.net 6667 lambdabot Lambda_robots:_100%_loyal' ] [add simple activity-monitor plugin stefanor@cox.net**20070111035033] [add the plugin level IRC, @irc-connect to use stefanor@cox.net**20070109040641] [add offline mode to OfflineRC plugin stefanor@cox.net**20070109012406 The new offline mode is activated using the ?offline privileged command, and works mostly like the core offline mode. Currently it is treated as --restricted. ] [add first OfflineRC plugin; -e works now stefanor@cox.net**20070109005834 This creates a new plugin, which executes the actions specified using -e 'foo'. The actions are processed and executed as if entered at an offline prompt. ] [remove the Maybe from lambdabot's readonly state stefanor@cox.net**20070109000344 This appeared as the easiest way to solve the 'No connection' errors encountered with initDoneMVar; it is hoped that this will cause no problems, since the virtual-chat system subsumes what Heffalump called the original purpose of the Maybe. ] [y Don Stewart **20070108100640] [add initDoneMVar, so that plugins that want to run code when LB is fully initialized can forkIO (readMVar ...) stefanor@cox.net**20070108050530] [add command-line parsing for -e 'foo' (execute command on startup) stefanor@cox.net**20070108044501] [more source Don Stewart **20070108035503] [tabs Don Stewart **20070108034833] [add missing logpp.in Don Stewart **20070108033727] [tag messages with lambdabot's nick stefanor@cox.net**20070108024528 To allow different servers to have different names for lambdabot, but not require the LB monad for accessing lambdabot's name, we annotate incoming IRCMessages with a msgLBName field. This seems a little too hackish... ] [more classes Don Stewart **20070108032913] [fix @time Don Stewart **20070108032903] [only catch IO errors in IRC send handler (brown paper bag fix) stefanor@cox.net**20070108022410] [add words Don Stewart **20070108020716] [add some classes Don Stewart **20070108020031] [try to return the time for the person who asked, if no args are supplied Don Stewart **20070108014205] [move testsuite Don Stewart **20070108011401] [create vchat indirection layer stefanor@cox.net**20070107225838 In order to support having several different servers, potentially speaking different protocols, we insert an additional layer of indirection in the path used for sending messages. An `ircServerMap' field in the main state maps the server tags to functions which are able to send messages to the associated servers. The two original servers are modified to be actions which, when run, connect to the servers in a newly-forked thread and register the servers in the vchat's map. When any server fails (IO error), it is removed from the map. The main thread terminates when the number of servers falls to zero. The names invocation in Seen fails due to the "freenode" server not being connected at the time of module initialisation; the effects of this are unknown, however Seen works in autojoined channels. There is no longer any connection-specific data in the read-only state. ] [Test @src Don Stewart **20070107111131] [stuff Don Stewart **20070107101347] [more tests Don Stewart **20070107094716] [more tests Don Stewart **20070107084332] [more test stuff Don Stewart **20070107083114] [remove the Maybe type on message sends (unneccessary now that plugins are invoked synchronously) stefanor@cox.net**20070107081055] [add readme Don Stewart **20070107080217] [Add unit tests `finally` Don Stewart **20070107075248] [update commands Don Stewart **20070107071058] [add printing for moduleInit exceptions (so you don't get silent failure) stefanor@cox.net**20070107030746] [add timeout in offline mode stefanor@cox.net**20070107030721] [rollback Base.hs patch Don Stewart *-20070107030509] [rollback Base.hs patch Don Stewart **20070107030509] [fix separate privmsg/channel handling Don Stewart *-20070106031541] [better catch url lookup failures Don Stewart **20070107030133] [threading rearchitecture, make almost everything synchronous stefanor@cox.net**20070107010531 * The read loop calls LMain.received (via a pointer to avoid recursive module issues): offline does it synchronously, online does it asynchronously. * Also due to recursive module issues, the IRC loops (kept in IRC) were split from the IRC data types (in IRCBase). * LMain.recieved calls the callbacks syncronously. * Side effects: There is no longer a need for the synchronization MVars. Offline mode no longer has a timeout. ] [hide TH Don Stewart **20070106104125] [some more types Don Stewart **20070106075623] [Word2048 dons@cse.unsw.edu.au**20070106075544] [insults Don Stewart **20070106070731] [quotes Don Stewart **20070106065424] [update source Don Stewart **20070106064029] [add LargeWord Don Stewart **20070106061152] [fix separate privmsg/channel handling Don Stewart **20070106031541] [add stref code Don Stewart **20070104083515] [Satisfy my ego Spencer Janssen **20070104073029] [change default tag to "freenode" (was "fn"), as discussed on IRC stefanor@cox.net**20070104053822] [use tag/channel names for logfiles stefanor@cox.net**20070104045851] [refactor, add @spell-all Don Stewart **20070104041905] [Declare my LB-hacker-status stefanor@cox.net**20070104035831] [add Spelling Nazi (@nazi-on, @nazi-off) stefanor@cox.net**20070104035539] [compulsively lowercase nicks in Seen stefanor@cox.net**20070104032120] [more state Don Stewart **20070104013731] [src tweaks Don Stewart **20070103234837] [add some class instances Don Stewart **20070103110126] [state Don Stewart **20070103045915] [tabs Don Stewart **20070103045847] [wibble dons@cse.unsw.edu.au**20070103044300] [update state dons@cse.unsw.edu.au**20070103043616] [Use gzip serialisation on more state types Don Stewart **20070103040516] [Add Gzip compression of the state. Use zcat to read State/quote now. Needs dcoutt's zlib binding, see the README Don Stewart **20070103034629] [resolve conflict stefanor@cox.net**20070103024958] [fix instance Show Nick so that save files from patched LB's can be read by unpatched LB's... just in case. stefanor@cox.net**20070103023410] [try again - get Seen working stefanor@cox.net**20070103014747] [fix all compile errors in Seen stefanor@cox.net**20070103004706] [hopefully fix Seen stefanor@cox.net**20070103003705] [get Seen compiling stefanor@cox.net**20070102023628] [three lambdabotName fixes stefanor@cox.net**20070103002550] [two nick-type fixes stefanor@cox.net**20070103002223] [fix lack of privs at offline console stefanor@cox.net**20070102040833] [force Base to compile stefanor@cox.net**20070102035607] [fix Compose stefanor@cox.net**20070102031951] [fix Karma stefanor@cox.net**20070102031852] [fix Localtime stefanor@cox.net**20070102025619] [fix Log + More stefanor@cox.net**20070102025220] [fix LBState + PL stefanor@cox.net**20070102024112] [fixup Todo to properly keep server data stefanor@cox.net**20070102000901] [refactor Message, add (un)packing stefanor@cox.net**20070102000203] [fix Slap + System stefanor@cox.net**20070101234737] [fix Tell + Todo stefanor@cox.net**20070101233739] [make Topic compile stefanor@cox.net**20070101231716] [fixup ios80 stefanor@cox.net**20070101222701] [fix errors induced in Lambdabot stefanor@cox.net**20070101222531] [fixup IRC for server tags stefanor@cox.net**20070101214510] [fix errors in Message stefanor@cox.net**20070101211206] [add types for attaching server names to messages stefanor@cox.net**20070101210528] [some more @src Don Stewart **20070103024354] [more src Don Stewart **20070103023519] [add bytestring-based fprocess_ module command. takes a msg as a bytestring and returns one. Avoids unnec. unpacks, and will be part of the bytestring-only path in and out of lambdabot Don Stewart **20070103021755] [i wrote another plugin Don Stewart **20070103021747] [needs -cpp for ./ghci script Don Stewart **20070103021736] [Refactor some popen uses Don Stewart **20070103011720] [untab Don Stewart **20070103011614] [remove LShell.hs, too many external deps Don Stewart **20070103011506] [add readOnly serial combinator, refactor Don Stewart **20070103010227] [add some more source Don Stewart **20070103003856] [leading spaces Don Stewart **20070102235425] [some more @whers dons@cse.unsw.edu.au**20070102112240] [tabs Don Stewart **20070102092620] [simplify Don Stewart **20070102091434] [add some extra things to @type Don Stewart **20070102074151] [don't import L qualified Don Stewart **20070102072618] [fmt Don Stewart **20070102072610] [move functions Don Stewart **20070102071710] [fix id Don Stewart **20070102071327] [more src Don Stewart **20070102065247] [add @src plugin Don Stewart **20070102062620] [tweaks for @src Don Stewart **20070102062558] [remove prelude.lam Don Stewart **20070102044117] [remove State/lambda Don Stewart **20070102044008] [sync state dons@cse.unsw.edu.au**20070102020240] [add @flush Don Stewart **20070101090234] [tabs Don Stewart **20070101071417] [move vixen state Don Stewart **20070101060330] [6.4 isms dons@cse.unsw.edu.au**20070101055658] [wibble dons@cse.unsw.edu.au**20070101054010] [Remove @lambda plugin. Unused since the invention of Eval Don Stewart **20070101052359] [no more DrHylo Don Stewart **20070101051858] [warn Don Stewart **20070101051817] [add clean target Don Stewart **20070101051405] [update 6.4 cabal file Don Stewart **20070101051324] [And back port new regex interface to 6.4 Don Stewart **20070101051308] [fix way=ghci Don Stewart **20070101045852] [no more moos Don Stewart **20070101045847] [don't need Lib.Regex as extra anymore Don Stewart **20070101044459] [we need regex-posix now Don Stewart **20070101044446] [port to new regex interface Don Stewart **20070101044439] [Add regex-posix wrapper layer, rather than rolling our own bytestring regex Don Stewart **20070101044400] [Remove regex.hsc Don Stewart **20070101044344] [no more vixenstate file Don Stewart **20070101032731] [serliase vixen state to disk, rather than compiling it in Don Stewart **20070101032701] [record some quotes dons@cse.unsw.edu.au**20061231114853] [switch to a simple MVar track for output from the contextual handler Don Stewart **20061231110733] [print name of author when doing pattern matching Don Stewart **20061231102620] [make ./ghci a bit friendlier Don Stewart **20061231101404] [implement regex matching for quotes Don Stewart **20061231101348] [bytestring interface to regex matching, and fix premature optimisation bug Don Stewart **20061231101322] [make the ghc 6.6 cabal file the default Don Stewart **20061231063912] [Improve nick++ handling. Spencer Janssen **20061226204954 Messages may now have several occurrences of nick++ and nick--. The current code should ignore most Haskell or Perl code that happens to have ++ or -- in it. ] [Add #if'd aliases to Lib/Parser.ly for functions in haskell-src that were renamed post-6.6 stefanor@cox.net**20061220071934] [Special case lowercase c++, so that lazy irc-ers don't inadvertantly praise c stefanor@cox.net**20061220211927] [fix expected location of BotPP stefanor@cox.net**20061223002750] [op sjanssen, int-e and sorear Don Stewart **20061220071649] [add some more monads Don Stewart **20061218105226] [record patch for Syzygy- Don Stewart **20061215141211] [quotes dons@cse.unsw.edu.au**20061212055301] [log-log commiter graph script Don Stewart **20061209040542] [bug fix Don Stewart **20061209010234] [add @bug Don Stewart **20061209005730] [stunnel instructions in README Daniel Nilsson **20061207104152] [gschuett Don Stewart **20061208001843] [more state dons@cse.unsw.edu.au**20061205000454] [update state dons@cse.unsw.edu.au**20061204235759] [Pointful: removing broken 'fix' definition Kevin Reid **20061204222252] [Pointful: recognize ($) Kevin Reid **20061204222122] [increase N bytes limit for grabbing titles dons@cse.unsw.edu.au**20061204002654] [increase tinyurl threshold Don Stewart **20061204002111] [merge dons@cse.unsw.edu.au**20061203055223] [Fix static build Samuel Bronson **20061103024316] [Get dynamic loading working again, yay! Samuel Bronson **20061102235724] [fmt dons@cse.unsw.edu.au**20061203054541] [Added GNU Talk Filters ekmett@gmail.com**20061129011340 Adds Plugin.Filter filter provides: austro b1ff brooklyn chef cockney drawl dubya fudd funetak jethro jive kraut pansy pirate postmodern redneck valspeak warez To use, install: http://www.hyperrealm.com/talkfilters/talkfilters.html If you install them in a non-standard location you may need to change the directory named in Plugins/Filter.hs ] [add hac07 site dons@cse.unsw.edu.au**20061203031508] [add :t / :k syntax Don Stewart **20061203030756] [Pointful: pretty print in single line mode Spencer Janssen **20061202021803] [Remove stray comma. Spencer Janssen **20061130192653] [more gschuett notes Don Stewart **20061127233704] [Seen.hs: lowercase all channel names before using them. Bertram Felgenhauer **20061127060006] [Seen.hs whitespace cleanup Bertram Felgenhauer **20061127052917] [wibbles dons@cse.unsw.edu.au**20061127031021] [more quotes dons@cse.unsw.edu.au**20061127024617] [add #jtiger Don Stewart **20061126093956] [this week's quotes dons@cse.unsw.edu.au**20061122121031] [Two new vim scripts smith@bcs.org**20061119194516] [merge in small check changes Don Stewart **20061119031821] [Import SmallCheck 0.2 Spencer Janssen **20061118053101] [redo: fix m >>= f Spencer Janssen **20061119015905] [Add a show instance for IO Don Stewart **20061117034858] [Add Pointful dons@cse.unsw.edu.au**20061115235116] [Add Pointful plugin. Kevin Reid **20061107180224] [Fix @source so that it outputs a / between the base URL and the package Spencer Janssen **20061115155022] [Another unsafePerformIO bites the dust Spencer Janssen **20061102022827] [Thanks to the unsafePerformIO Police, another crime against referential transparency has been solved. Spencer Janssen **20061102021955] [new quotes dons@cse.unsw.edu.au**20061114015950] [update free theorem Don Stewart **20061110042311] [update dons@cse.unsw.edu.au**20061107001120] [#haskell.no Don Stewart **20061106235535] [add more chans Don Stewart **20061105105033] [Make fptools and docs strip beginning and trailing whitespace Spencer Janssen **20061102015409] [Factor out the common parts of fptools, source and docs Spencer Janssen **20061102015118] [don't stay in ##logic. leave that to mbot Don Stewart **20061104020349] [stay in ##logic Don Stewart **20061104012236] [more quotes dons@cse.unsw.edu.au**20061031015333] [sync dons@cse.unsw.edu.au**20061031014924] [more details on protontorpedo Don Stewart **20061030090219] [add #gentoo-uy Don Stewart **20061030011702] [disable giant log file for now Don Stewart **20061026224718] [add a new keal Don Stewart **20061026030944] [add #haskell.jp Don Stewart **20061025062815] [sync dons@cse.unsw.edu.au**20061020034917] [Trailing whitespace in Modules.hs is no longer fatal. smith@bcs.org**20061010130913] [strictify randomly Don Stewart **20061018235857] [import Generics qualified Don Stewart **20061014160221] [sync dons@cse.unsw.edu.au**20061010022824] [sync dons@cse.unsw.edu.au**20061003120631] [Figlet plugin mux@FreeBSD.org**20060916162721] [more generics Don Stewart **20061004005900] [Add Data.Generics Don Stewart **20061004005054] [tune Karma's xxx++ regexp to allow nicks with + and - (but not at end) Bertram Felgenhauer **20060927052647] [Enable comments in @undo code Spencer Janssen **20061003014622] [Make @redo handle non-lambda expressions on the RHS of (>>=) sjanssen@cse.unl.edu**20060912005550] [Clean up patterns. Spencer Janssen **20061001224333] [handle out of memory errors more gracefully Don Stewart **20060928093031] [quotes dons@cse.unsw.edu.au**20060927061446] [less Monad.ST Don Stewart **20060926070913] [don't use Monad.ST, spotted by sjanssen Don Stewart **20060926070744] [revert to "No IO allowed", suggest by int-e Don Stewart **20060925021956] [sync state dons@cse.unsw.edu.au**20060924041327] [wibbles Don Stewart **20060924035028] [fix Don Stewart **20060922084717] [more strictness Don Stewart **20060921235443] [strictify Don Stewart **20060921023551] [enable -O Don Stewart **20060921021042] [Add Monad.Error Don Stewart **20060920042403] [all the web TODOs have been fixed Jason Dagit **20060919063052] [Add Serial instance for Ordering in SmallCheck Samuel Bronson **20060919025313] [Oops, left this out of previous patch... Samuel Bronson **20060919025033] [Move Show instance for (->) out of ShowQ for SmallCheck Samuel Bronson **20060919023113] [stop filtering spaces in BF Jason Dagit **20060919050510] [fixed major bug in BF interpretation Jason Dagit **20060919050233 The bf interpreter was not handling nested loops correctly. ] [Make @type and @kind work for me Samuel Bronson **20060917224306] [wibbe Don Stewart **20060917050057] [move source -> Dummy.source Don Stewart **20060917050029] [fix some todos Don Stewart **20060917045003] [disable slap, echo, listchans by defualt Don Stewart **20060917044901] [added web todo to TODO Jason Dagit **20060916185358] [fix help for dicts Don Stewart **20060917044506] [update dons@cse.unsw.edu.au**20060916145634] [tweak build isntrs Don Stewart **20060916074645] [auto-reconfigure Don Stewart **20060916074636] [always print a \n. fixes goa Don Stewart **20060916074615] [fix version string on non-linux Don Stewart **20060916074605] [disable state plugin dons@cse.unsw.edu.au**20060916065111] [wibble dons@cse.unsw.edu.au**20060916065054] [sync Don Stewart **20060916063055] [Fix logging. Goes into State/log now (a full transcript) Don Stewart **20060916062802] [wibbles Don Stewart **20060916055408] [nice the build Don Stewart **20060916054619] [revert contextual super-handling. broke > Don Stewart **20060916054603] [add logging in offline mode. Logs go into State/Logs/*/offline/ Don Stewart **20060916035901] [just double check handling of [[]] empty output in Base.hs Don Stewart **20060916032624] [--restricted, disables priv commands in command line mode Don Stewart **20060916032338] [wibbles Don Stewart **20060916032059] [wibbles in @localtime patch Don Stewart **20060916032040] [add --web, which is like command line mode, but disables the priv commands Don Stewart **20060916032012] [lambdabot's own response to @time mail@joachim-breitner.de**20060915112642 (Note that I could not test the code, sorry) ] [fix Don Stewart **20060916020254] [pervert Don Stewart **20060914100853] [hide bounds for ghc 6.4.2 Don Stewart **20060914023257] [wibbles Don Stewart **20060914023241] [Add scheck command Don Stewart **20060913175013] [And build smallcheck Don Stewart **20060913165744] [Add SmallCheck support Don Stewart **20060913165626] [typo Don Stewart **20060913165550] [fixify Don Stewart **20060913161128] [Add instance for Ratio Don Stewart **20060913160428] [hopefully catch and handle better some state change serialisation issues Don Stewart **20060913111018] [quotes, and log everything Don Stewart **20060913102257] [move hoogle state into State/ Don Stewart **20060913051522] [disable input in bf Don Stewart **20060912004649] [don't warn so much Don Stewart **20060911084203] [add @let and @undefine to command list Don Stewart **20060911072133] [Make @let use Language.Haskell rather than a regex sjanssen@cse.unl.edu**20060911065925] [wibble Don Stewart **20060911061403] [add Test.QuickCheck Don Stewart **20060911060428] [generalise binding regex Don Stewart **20060911055345] [add local decl support to quickCheck Don Stewart **20060911051829] [500 tests seems reasonable dons@cse.unsw.edu.au**20060911050048] [increase check limit dons@cse.unsw.edu.au**20060911050035] [Add persistent declarations to Eval plugin Don Stewart **20060911045634] [wibbles Don Stewart **20060910090853] [add check Don Stewart **20060910072443] [add I = Int Don Stewart **20060910065959] [add a synonym for [Int] Don Stewart **20060910062312] [add an instance Arbitrary Ordering dons@cse.unsw.edu.au**20060910060621] [improvements Don Stewart **20060910052949] [add cabal rule for building quickCheck Don Stewart **20060910051056] [working @check Don Stewart **20060910050925] [Add @check, test an instance of Testable with quickCheck Don Stewart **20060910035257] [no haskell98 Don Stewart **20060909095347] [add a cabal script for ghc 6.6 Don Stewart **20060909090823] [error Don Stewart **20060909071924] [resync Don Stewart **20060909033933] [don't use -threaded twice Don Stewart **20060909032534] [wibble Don Stewart **20060909032419] [wibble Don Stewart **20060909032141] [add chmod Don Stewart **20060909031352] [Don't commit to 6.6 modules just yet Don Stewart **20060909031144] [add FT Don Stewart **20060909031028] [add FT.hs Don Stewart **20060909030928] [Import Janis Voigtlaender and Sascha Bohme's FT tool for free theorems Don Stewart **20060909025221] [added more html entities to ./Lib/Url.hs Jason Dagit **20060909002407] [limit getHtmlPage to follow 5 redirects max Jason Dagit **20060908222107 This fixes a possible DoS where a website does an infinite sequence of redirects. ] [turn off logging Don Stewart **20060908125145] [in BF.hs isAscii wasn't stringent enough so replaced with custom 'printable' Jason Dagit **20060908064735] [fix a bug with composing tiny-url and url-title Jason Dagit **20060908060358] [fix a potential bug with returning multiple titles/urls Jason Dagit **20060908060325] [fixed bug in tiny-url and url-title where the url was not found sometimes Jason Dagit **20060908051744] [fixify Don Stewart **20060908011858] [more quotes Don Stewart **20060908010540] [silent, simple Don Stewart **20060907080256] [the impredicative stuff only work in 6.6 dons@cse.unsw.edu.au**20060907074809] [no more long @list Don Stewart **20060907074402] [fix nick++ regex Don Stewart **20060907074341] [add offline contextual support. Introduce contextual data with !foo Don Stewart **20060907074316] [bf wibbles Don Stewart **20060907031434] [Match karma like dons asked Samuel Bronson **20060906113031] [sync Don Stewart **20060906053410] [point to commands Don Stewart **20060906033908] [add commands file Don Stewart **20060906033640] [disable listall except as a priv command Don Stewart **20060906030856] [make the bot quieter Don Stewart **20060906030527] [resync freetheorems Don Stewart **20060906025620] [Plea for help Samuel Bronson **20060904150906] [Add #perl6 style karma Samuel Bronson **20060904145059] [wibble dons@cse.unsw.edu.au**20060904061037] [sync Don Stewart **20060904060617] [Add instructions for updating Cabal to README (thanks lispy!) Samuel Bronson **20060904012059] [Fix up whitespace in logo Samuel Bronson **20060904005257] [nicer Don Stewart **20060903033717] [wibble Don Stewart **20060903032828] [more concise time diffs Don Stewart **20060903005916] [bf is now an optimizing interpreter Jason Dagit **20060901230358 phase1 -> remove instruction which will be ignored anyway phase2 -> runs of inc/dec instructions are now grouped and turned into a single inc/dec. For example, ++++++ would become IncByteBy 6 phase3 -> Jumps are transformed to abosulte changes in the instruction pointer ] [optimized bf Jason Dagit **20060901085059] [removed unneeded filtering Jason Dagit **20060901084914] [Add #ghc dons@cse.unsw.edu.au**20060901083314] [added optimizations to building bf Jason Dagit **20060901063526] [scrub "Machine Halted." from bf output Jason Dagit **20060901063443] [added bf to main cabal file Jason Dagit **20060901060340] [added bf to lambdabot.cabal.plugins Jason Dagit **20060901055833] [added brainf*ck interpreter Jason Dagit **20060901054551] [add some more stuff to version control dons@cse.unsw.edu.au**20060901051608] [sync dons@cse.unsw.edu.au**20060901051550] [fixed a short url bug and renamed isTiny -> findTiny Jason Dagit **20060901042750 Accidentally applied the minimum length of a url to fetching the title, this patch fixes that bug. ] [sync state dons@cse.unsw.edu.au**20060901042754] [added tiny-url to Url plugin Jason Dagit **20060901041714] [Track maximum uptime sjanssen@cse.unl.edu**20060901034159] [Plugin.Djinn: move from Haskell '98 style modules to hierarchical sjanssen@cse.unl.edu**20060829145103] [Undo: handle pattern match failures sjanssen@cse.unl.edu**20060829145432] [add note to README describing how to get 'run' working Jason Dagit **20060830065619] [improve docs. Stop Korollary whinging Don Stewart **20060830033405] [Refactor undo, add redo sjanssen@cse.unl.edu**20060829025607] [Make @free use @type if no signature is supplied. Kevin Reid **20060828064238] [Quarter-baked @djinn-names command. Kevin Reid **20060704045204] [proxy = Nothing, to keep SamB happy Don Stewart **20060828042327] [fix buglet Don Stewart **20060828020710] [track active users Don Stewart **20060828015033] [quieter Don Stewart **20060827045106] [Doless -> Undo dons@cse.unsw.edu.au**20060825035909] [typo dons@cse.unsw.edu.au**20060825035434] [Implement doless -- a plugin to translate do notation to Monad operations sjanssen@cse.unl.edu**20060825034232] [merge Don Stewart **20060824140105] [wibbles Don Stewart **20060824135636] [Changes to the Seen module. Lemmih **20060824133838 * Proper help message for @users. * Made @users take an optional channel argument. * (Added myself to the admin list) ] [fix unlamda hack Don Stewart **20060824062012] [remove \n from read Don Stewart **20060824024108] [add control.monad.writer Don Stewart **20060824011955] [less lines in output Don Stewart **20060823061648] [wibble Don Stewart **20060823061351] [Add rename pass Don Stewart **20060823060207] [support latest fps Don Stewart **20060823040634] [Add free theorems plugin Don Stewart **20060823040623] [search google.com Don Stewart **20060822152436] [update dons@cse.unsw.edu.au**20060822051149] [sync state dons@cse.unsw.edu.au**20060822051136] [update @quotes dons@cse.unsw.edu.au**20060816032324] [100 * Don Stewart **20060819085608] [less verbose Don Stewart **20060819025054] [idea from syntaxfree Don Stewart **20060817042017] [fix karma- java Don Stewart **20060815054445] [-fasm and haskell98 dep is not needed (thanks ndm) Don Stewart **20060814041348] [wibbles Don Stewart **20060814041338] [fix type error for ghc 6.4 Bertram Felgenhauer **20060813174010] [get rid of implicit arguments Bertram Felgenhauer **20060813155635 - ModuleT is an actual transformer now, a newtyped ReaderT. - ?ref and ?name are replaced by getRef and getName actions. - there are explicit binding options for converting module specific actions to LB actions, namely bindModule1 :: (a -> ModuleT s LB b) -> ModuleT s LB (a -> LB b) and similarily bindModule0 and bindModule2. - a lot of small changes to plugins were necessary because the types weren't quite correct but that was hidden by the fact that ModuleT was merely a type alias. ] [more quotes Don Stewart **20060814020148] [sort quotes dons@cse.unsw.edu.au**20060813051858] [Add @protontorpedo dons@cse.unsw.edu.au**20060813045211] [haskell 98 in case dons@cse.unsw.edu.au**20060813045145] [Fix up @yarr quotes and command. Duncan Coutts **20060812164657] [Make @arr and @yarr! do what I think they should do. Duncan Coutts **20060812163700 Oh, and add more pirate quotes. ] [rsync hoogle Don Stewart **20060812100018] [remember how to script the state Don Stewart **20060811101139] [simplify Don Stewart **20060811100304] [fix snoc/cons and add nil Don Stewart **20060811094528] [add state cons/snoc Don Stewart **20060811093312] [add read/show (for unquote/quote games) Don Stewart **20060811091137] [no self-raising of karma Don Stewart **20060810080938] [-w in log Don Stewart **20060810080312] [java karma fun Don Stewart **20060810080303] [disable @last and friends for now. too evil Don Stewart **20060810072830] [hid @seen by accident Don Stewart **20060806095954] [missing binary instance Don Stewart **20060806074408] [handle max users for multiple channels Don Stewart **20060806074250] [Track maximum, and current users Don Stewart **20060806071857] [@users, count the number of current users Don Stewart **20060806064852] [Dice: more concise error messages, minor formula improvement for many dice. Bertram Felgenhauer **20060806050254] [dice plugin enhancements Bertram Felgenhauer **20060802153425 - use normally distributed random numbers to approximate many dice - use Integer instead of Int (prevents overflows) - limit output to 79 characters - add eof to parser ] [fix paths in backup cabal file Don Stewart **20060730053556] [Remove haskell98 dep :) Don Stewart **20060730051649] [Remove haskell98 deps in hoogle and djiinn Don Stewart **20060730051538] [more quotes Don Stewart **20060730045107] [Remove hs-plugins dependency by default. Don Stewart **20060730045043] [ignore dot-ghci files in instances Don Stewart **20060729132153] [leading space to unquote, to prevent abuse dons@cse.unsw.edu.au**20060728041916] [Added unquote command to Dummy plugin. Kevin Reid **20060727172405] [MORE AI! Paolo Martini **20060718141019] [fix two compiler warnings Bertram Felgenhauer **20060718000347] [(runplugs) fix > error (repeat 'a') :: Int Bertram Felgenhauer **20060717235330] [somewhat revert Don Stewart **20060714061028] [more human prompt for @url-title Don Stewart **20060714060423] [Add a string replace function and use it to implement unhtml Vesa Kaihlavirta **20060714050344] [State -> ST Don Stewart **20060714032219] [Make the Url plugin's title fetching mode persistent. Kevin Reid **20060707164802] [Move command prefixes into Config.hs. Kevin Reid **20060704033226] [note that the ghci way depends on a successful cabal build to get the preprocessor Don Stewart **20060704031514] [Fix HTTP/1.1 headers to avoid persistent connections and associated timeouts davidf@rd.bbc.co.uk**20060703115945 HTTP/1.1 by default maintains persistent connections. Url plugin now sends correct headers to close the connection and stop timeouts with some servers. ] [Fix @instances for Arrow and Monad and other classes where (->), or indeed any operator involving the character '-', was an instance. david **20060701182819] [Every project needs a cheesy ASCII-art logo! TODO: make it better. I'm not too david **20060612175106 gifted in the creative sectors :) ] [Fix url handling to be HTTP/1.1 for requests not sent through a proxy davidf@rd.bbc.co.uk**20060630110228 Webservers are often required to be HTTP/1.1 compliant, which requires an extra host: header to be sent to identify virtual hosts. Proxies handle this automatically and can continue to use HTTP/1.0 requests from us. ] [some palomers dons@cse.unsw.edu.au**20060629031654] [url decode the titles, no more &s; dons@cse.unsw.edu.au**20060627091824] [readNBytes, to avoid possible bandwidth games in @url dons@cse.unsw.edu.au**20060627090842] [Change @paste url. Suggested by vincenz dons@cse.unsw.edu.au**20060625023325] [ignore ??... @@... dons@cse.unsw.edu.au**20060619033926] [Add a workaround for violators of the HTTP RFC 2619 wrt Location headers. pete-lambdabot@kazmier.com**20060618180207] [Enhanced Search plugin with url page title fetching. pete-lambdabot@kazmier.com**20060618044512 In addition, I removed the buggy extractLoc function, which failed to remove the trailing CR. Instead, it now uses the new Url library's getHeader function instead. ] [Refactored the URL page and title fetching to a URL library. pete-lambdabot@kazmier.com**20060618032331 The intent of this is to allow other plugins to leverage the fetching of pages (and following of redirects) as well as the fetching of page titles for text/html content. It was suggested by dmhouse that I modify the Search plugin to print not only the URL of the result, but also the title of it. ] [reenable @remember dons@cse.unsw.edu.au**20060618051552] [Reduce chance of mishaps with the ignored list pete-lambdabot@kazmier.com**20060616113441] [Need to update the ignored list when the output is changed in Url plugin pete-lambdabot@kazmier.com**20060616112053] [brevity is the art of .. something or other dons@cse.unsw.edu.au**20060616100942] [Get rid of error messages from Url.hs pete-lambdabot@kazmier.com**20060616092733 And ignore c++ paste bin posts. ] [import unsafeUseAsCString from Data.ByteString.Base (follows recent change in FPS) dons@cse.unsw.edu.au**20060616051012] [use ios80 in Eval plugin Bertram Felgenhauer **20060616045555] [use ios80 in Unlambda plugin Bertram Felgenhauer **20060616045519] [add ios80 function for limiting output to channels Bertram Felgenhauer **20060616045036] [limit output of Unlambda plugin to 2048 characters Bertram Felgenhauer **20060616025039 this avoids crazy output like ' [5537 @more lines]' ] [add dmhouse to copyright on Log.hs dons@cse.unsw.edu.au**20060615083907] [bump Versoin.hs number dons@cse.unsw.edu.au**20060615042526] [TAG lambdabot-4.0 dons@cse.unsw.edu.au**20060615041235] Patch bundle hash: 9f5d19d5dedacd00b255dc6119f68cb50c29aa3c From dons at galois.com Tue Feb 5 12:18:55 2008 From: dons at galois.com (Don Stewart) Date: Tue Feb 5 12:18:03 2008 Subject: lambdabot setup In-Reply-To: References: Message-ID: <20080205171855.GA4050@scytale.galois.com> valery.vv: > Dear, lazy programmers, > > Please let me know the proper place to report lambdabot bugs, > and feel free to ignore the rest of message. > > Are you still reading? In this case you may want to know that > *** I've successfully installed lambdabot with GHC 6.9! :) *** > Kudos to Cale & the IRC crowd for making my day > [http://tunes.org/~nef/logs/haskell/08.02.04]. > > Boring part: > > $ darcs get http://code.haskell.org/lambdabot > $ cd lambdabot > $ runhaskell Setup configure --prefix=$HOME --user > $ runhaskell Setup build > $ touch LICENSE # see the patch attached > $ runhaskell Setup install You need to use the ./build script which builds all the programs, not just the cabal ones, and generates the extra files. -- Don From Christian.Maeder at dfki.de Tue Feb 5 12:39:34 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Feb 5 12:39:20 2008 Subject: fgl-bug Message-ID: <47A89F56.5040903@dfki.de> Hallo Martin, I was going to use xdfWith from Data.Graph.Inductive.Query.DFS with Data.Graph.Inductive.Graph.out' as second argument, but 1. xdfWith is not exported 2. out' seems to be wrong (by looking at the source code) -- | All outward-directed 'LEdge's in a 'Context'. out' :: Context a b -> [LEdge b] out' c@(_,v,_,_) = map (\(l,w)->(w,v,l)) (context4l' c) ^^^ I think, the outgoing edge must be made as "(v,w,l)"! inn' looks correct: -- | All inward-directed 'LEdge's in a 'Context'. inn' :: Context a b -> [LEdge b] inn' c@(_,v,_,_) = map (\(l,w)->(w,v,l)) (context1l' c) Can 1. and 2. be fixed? I need the general xdfWith because I want to filter out some successors (or maybe I can filter to whole graph first). Cheers Christian From bulat.ziganshin at gmail.com Tue Feb 5 16:00:12 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Feb 5 16:03:45 2008 Subject: freezing the base In-Reply-To: <47A1ADEE.80407@gmail.com> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> <20080129175243.GA18863@scytale.galois.com> <479F6CBD.3090009@imn.htwk-leipzig.de> <259254796.20080129225150@gmail.com> <47A1ADEE.80407@gmail.com> Message-ID: <162985135.20080206000012@gmail.com> Hello Simon, Thursday, January 31, 2008, 2:15:58 PM, you wrote: > Freezing base is a bad idea. > - we'd end up with silly packages called things like 'listexts' with > Data.List.Exts. > - we have no way of evolving the design of the libraries, no way to > make improvements. We're stuck with a design which is widely > acknowledged to be lacking in various serious ways (e.g. no Unicode > in the IO library). "Freezing base is a bad idea" only in the situation when we fear to duplicate any code. but really this leads to situation when the same code needs to be duplicated in every serious program, starting from GHC itself! why i have Utils module with dozens of list funcs? why you duplicated in GHC bag, bitset, encoding support, finite maps and lots of other standard code? i propose to freeze base in its current state and duplicate everything we want to evolve to separate libs. want to evolve i/o libs? no problem - just copy system.io to new.system.io and add anything you want. this new implementation will be outside of base so everyone will be able to use just the version he need at last end, "old good things" in base will remain only for backward compatibility with "old good books" like haskell98 package now used and as a base for other libraries, like GHC.* modules now used we shouldn't take new code into the base library because this only makes problem harder. are you not consider as a problem that it's impossible to develop code which will work with different ghc versions? in particular, i think we *have* library which supports unicode. it's not mature enough but it's better to evolve this lib or write another one which will be independent of base instead of making any changes to existing 2kloc Handle implementation > What we propose to do instead is to provide better support for backwards > compatibility. I'm honestly not sure whether this will lead to more > problems, or whether it will just work nicely, but it's pretty clear we > have to try. > Before responding, take a good read through > http://hackage.haskell.org/trac/ghc/wiki/PackageCompatibility first, now it is clear how to handle situation in 6.8 - with 4.2 we will have no more problems than with previous ghc upgrades >"Each time we split base we have to invent a new name for it, and we >accumulate a new compatibility wrapper for the old one." not true. for previous base versions, we never declared that it obeys HLP (haskell libraries policy), so users was absolutely right using general "base" dependency. for newbase library we will need to declare this and require that user specify "newbase 1.*" dependency, so newbase 2.0+ can make any API changes my proposal of freezing the base is exactly what i propose to do in order to finally solve "base problem". the proposed solution seems unusual for the first look but it really works and really solves the problem for 100%. actually, it's much better than duplicating code in every application program. the main disadvantage of duplicated code - maintenance costs - will be probably zero in this case because existing code in base rarely need to be fixed > For this we need support in Cabal and/or Hackage. By the time we release > GHC 6.10, we want most packages in Hackage using accurate dependencies, so > that the majority will continue to work with GHC 6.10. a few days ago i've released first version of my GUI program. it had support for 69 localizations. how it was done? i just wrote script which translated language files of another program with close functionality :) we have only two ways to make all hackage libs compatible with 6.10 - either make *ghc* compatible with existing libs or *convert* these libs to the new format. but forcing authors to upgrade their libs is a bad idea. now i have feeling that goals of ghc/cabal/hackage developers isn't to provide eternal compatibility but to research various ways of providing such compatibility and write interesting papers about user reaction to all their experiments. sorry, but it is what i see > Something else we have to think about is upgrades. We're now commonly > seeing multiple versions of packages installed, leading to problems when > resolving dependencies ends up with two different versions of a given > package, and type errors ensue. It's probably time to start a new wiki > page for thinking about solutions to this. sure. one idea we can import from my proposal is to recommend users to write their code against some "gem" of libraries - HSL-2008, HSL-2009... -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From johan.tibell at gmail.com Wed Feb 6 04:07:47 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed Feb 6 04:06:49 2008 Subject: freezing the base In-Reply-To: <162985135.20080206000012@gmail.com> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> <20080129175243.GA18863@scytale.galois.com> <479F6CBD.3090009@imn.htwk-leipzig.de> <259254796.20080129225150@gmail.com> <47A1ADEE.80407@gmail.com> <162985135.20080206000012@gmail.com> Message-ID: <90889fe70802060107h96760f1k59bc8e7f8d399089@mail.gmail.com> On Feb 5, 2008 10:00 PM, Bulat Ziganshin wrote: > i propose to freeze base in its current state and duplicate everything we > want to evolve to separate libs. want to evolve i/o libs? no problem - > just copy system.io to new.system.io and add anything you want. this > new implementation will be outside of base so everyone will be able to > use just the version he need Please do not use the package or library name for versioning or we'll end up with New.New.New.System.IO or Newer.Than.The.Third.Old.System.IO.That.Johan.Wrote ;). There will always be a new versions. Use the package's version number for versioning. -- Johan From vandijk.roel at gmail.com Wed Feb 6 05:38:53 2008 From: vandijk.roel at gmail.com (vandijk.roel@gmail.com) Date: Wed Feb 6 05:37:55 2008 Subject: darcs patch: Small documentation fix Message-ID: <47a98e3f.2533440a.3040.fffff192@mx.google.com> Wed Feb 6 01:58:29 CET 2008 Roel van Dijk * Small documentation fix -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 376 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/libraries/attachments/20080206/537617c8/attachment.bin From valery.vv at gmail.com Wed Feb 6 11:04:41 2008 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Wed Feb 6 11:03:40 2008 Subject: lambdabot setup In-Reply-To: <20080205171855.GA4050@scytale.galois.com> References: <20080205171855.GA4050@scytale.galois.com> Message-ID: On 2/5/08, Don Stewart wrote: > You need to use the ./build script which builds all the programs, not > just the cabal ones, and generates the extra files. Thanks. -- vvv From valery.vv at gmail.com Wed Feb 6 11:43:41 2008 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Wed Feb 6 11:42:39 2008 Subject: lambdabot setup In-Reply-To: References: Message-ID: On 2/5/08, Valery V. Vorotyntsev wrote: > $ lambdabot -e 'hoogle map' > Initialising plugins ...........Plugin.Djinn: couldn't find djinn binary > ...........................sending message to bogus server: > IrcMessage {msgServer = "freenode", msgLBName = "urk!", > msgPrefix = "", msgCommand = "NAMES", msgParams = [""]} > .................. done. > A Hoogle error occured. > Exception: all servers detached > exception: > State/seen: openBinaryFile: does not exist (No such file or directory) Sorry, Don, I still prefer cabal installation procedure to the ./build[1] script. Cabal way is cleaner and "sh ./build" didn't help with the error mentioned above. 1. http://code.haskell.org/lambdabot/build "lambdabot -e 'hoogle map'" works fine if there is `State' directory in $PWD. Workaround is to copy `State' to ~/bin/ and to define a function in .bashrc: lambdabot () { cd ~/bin ./lambdabot "$@" } Shouldn't lambdabot chdir(2) before accessing files from State/ directory? Thank you. -- vvv From ross at soi.city.ac.uk Wed Feb 6 13:48:54 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Feb 6 13:48:38 2008 Subject: [Haskell-cafe] Minor issue with mapAccumR In-Reply-To: <89ca3d1f0802042103m3e72f6f7y3ad5f5552093ef5e@mail.gmail.com> References: <89ca3d1f0802042103m3e72f6f7y3ad5f5552093ef5e@mail.gmail.com> Message-ID: <20080206184854.GA13277@soi.city.ac.uk> On Tue, Feb 05, 2008 at 12:03:38AM -0500, Cale Gibbard wrote: > Are many people using mapAccumR? How much would it hurt to change it? It's specified in the Haskell 98 Report, so changing it is a big deal. Personally, I think the types should have been mapAccumL :: (s -> a -> (b,s)) -> s -> [a] -> ([b],s) mapAccumR :: (a -> s -> (s,b)) -> [a] -> s -> (s,[b]) to show which direction the state flows. I can't resist observing that these functions generalize to Traversable, so they can be used for numbering elements, zipping with a Stream, etc: -- left-to-right state transformer newtype StateL s a = StateL { runStateL :: s -> (s, a) } instance Functor (StateL s) where fmap f (StateL k) = StateL ((id *** f) . k) instance Applicative (StateL s) where pure x = StateL (\ s -> (s, x)) StateL kf <*> StateL kv = StateL $ \ s -> let (s', f) = kf s (s'', v) = kv s' in (s'', f v) mapAccumL :: Traversable t => (a -> b -> (a, c)) -> a -> t b -> (a, t c) mapAccumL f s t = runStateL (traverse (StateL . flip f) t) s -- right-to-left state transformer newtype StateR s a = StateR { runStateR :: s -> (s, a) } instance Functor (StateR s) where fmap f (StateR k) = StateR ((id *** f) . k) instance Applicative (StateR s) where pure x = StateR (\ s -> (s, x)) StateR kf <*> StateR kv = StateR $ \ s -> let (s', v) = kv s (s'', f) = kf s' in (s'', f v) mapAccumR :: Traversable t => (a -> b -> (a, c)) -> a -> t b -> (a, t c) mapAccumR f s t = runStateR (traverse (StateR . flip f) t) s From gale at sefer.org Wed Feb 6 16:09:04 2008 From: gale at sefer.org (Yitzchak Gale) Date: Wed Feb 6 16:08:01 2008 Subject: Readline read_history and write_history addition In-Reply-To: <6d74b0d20802041349v1597c25cq4fdd55f4c9a9b904@mail.gmail.com> References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> <20080123125724.GA2912@matrix.chaos.earth.li> <2608b8a80801230519v72388283xf35f1de120571ca2@mail.gmail.com> <57526e770802021035u170e47cey77edea12eaa5c340@mail.gmail.com> <2608b8a80802021130i2b4486c3m74bc6ef7fdd2c425@mail.gmail.com> <6d74b0d20802021203x7ae35e0fjaee1a1c961731856@mail.gmail.com> <2608b8a80802021314k7bcbc643n22d4ee53e6506d73@mail.gmail.com> <47A6FCBE.4090101@gmail.com> <2608b8a80802040606mdb73f20n6090d1b437d5202@mail.gmail.com> <6d74b0d20802041349v1597c25cq4fdd55f4c9a9b904@mail.gmail.com> Message-ID: <2608b8a80802061309h4c85c9dai4add6870d779496c@mail.gmail.com> Judah Jacobson wrote: > - readFile... writeFile... > I think of readHistory and writeHistory as analogues to the above > functions. I don't think so. I don't really care about the file itself - that just happens to be the way readline implements its persistence. Non-existence of the file is the normal way that readline represents the fact that there isn't any history yet. The semantics of the API call are: load history, if any exists yet, and report the result. Nothing exceptional about that. > All that being said, this is a relatively minor issue Agreed. All the more so with the MonadIO problem now factored out. Regards, Yitz From cgibbard at gmail.com Wed Feb 6 19:33:46 2008 From: cgibbard at gmail.com (Cale Gibbard) Date: Wed Feb 6 19:32:43 2008 Subject: [Haskell-cafe] Minor issue with mapAccumR In-Reply-To: <20080206184854.GA13277@soi.city.ac.uk> References: <89ca3d1f0802042103m3e72f6f7y3ad5f5552093ef5e@mail.gmail.com> <20080206184854.GA13277@soi.city.ac.uk> Message-ID: <89ca3d1f0802061633r7214bfc2h5658c84ef429fa7a@mail.gmail.com> On 06/02/2008, Ross Paterson wrote: > On Tue, Feb 05, 2008 at 12:03:38AM -0500, Cale Gibbard wrote: > > Are many people using mapAccumR? How much would it hurt to change it? > > It's specified in the Haskell 98 Report, so changing it is a big deal. > Personally, I think the types should have been > > mapAccumL :: (s -> a -> (b,s)) -> s -> [a] -> ([b],s) > mapAccumR :: (a -> s -> (s,b)) -> [a] -> s -> (s,[b]) > > to show which direction the state flows. > However, it's perhaps worth considering as well that ((,) s) is a Functor instance, something which the MTL ignores in its types, using less-convenient (a,s) pairs in Writer and State. - Cale From Christian.Maeder at dfki.de Thu Feb 7 05:05:09 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Feb 7 05:04:07 2008 Subject: ANNOUNCE: multiset 0.1 In-Reply-To: <47AA6251.3020805@gmail.com> References: <47AA6251.3020805@gmail.com> Message-ID: <47AAD7D5.2080207@dfki.de> > Hackage: > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/multiset-0.1 > Haddock: http://twan.home.fmf.nl/multiset/doc/ > Darcs: http://twan.home.fmf.nl/repos/multiset/ Seeing all these nice little packages (i.e. also bimap), is there a cute way to get a binary distribution - similar to the current extra libs - with many packages already included, so that installation can be accomplished in one go (maybe for the next ghc release)? Cheers Christian From twanvl at gmail.com Thu Feb 7 12:20:12 2008 From: twanvl at gmail.com (Twan van Laarhoven) Date: Thu Feb 7 12:19:13 2008 Subject: ANNOUNCE: multiset 0.1 In-Reply-To: <200802071107.40781.g9ks157k@acme.softbase.org> References: <47AA6251.3020805@gmail.com> <200802071107.40781.g9ks157k@acme.softbase.org> Message-ID: <47AB3DCC.8030308@gmail.com> (moving discussion to the libraries list) Wolfgang Jeltsch wrote: > this is interesting. A few days ago I discovered that I needed such a library > and decided to implement it myself. However, I had not started yet when I > received your e-mail. > > A bit of criticism concerning the name: According to the English Wikipedia, > multiset is a single word. So the identifiers should be Multiset and > IntMultiset instead of MultiSet and IntMultiSet. After looking around a bit, it seems 'multiset' is consistently spelled as a single word. Personally I think "MultiSet" looks better, but if more people agree with you I will change the name in the next version. > However, I think it would > be even better to just use Bag and IntBag as identifiers. Those are shorter > and maybe easier to remember. After all, the term bag is fairly standard. There are two several for choosing "multiset" over "bag": - The name "multiset" covers the functionality much better. If I didn't know the name of the data structure, only that it is like a set containing multiple copies of elements, I would find it if it was called multiset, not if it was called bag. - The name Bag is also used for other data structures. For instance GHC uses 'bag' for an ordered data structure with fast concatenation. - Other libraries like the C++ STL also use the name multiset. > I think that actually your multiset/bag implementation should be a part of the > containers package. So why not ask the maintainers of the containers package > for permission to add your implementation and change the identifiers to Bag > and IntBag during this process? This would be great. I initially wrote these modules as part of the containers package. Unfortunatly the libraries process is awefully slow. And if you think about it, there isn't a big advantage to having multiset in the containers package. I decided to get the code out there quickly, so it can be used right now. Perhaps the library could/should be merged into the containers package somewhere in the future. Twan From Christian.Maeder at dfki.de Thu Feb 7 13:05:40 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Feb 7 13:04:36 2008 Subject: ANNOUNCE: multiset 0.1 In-Reply-To: <47AA6251.3020805@gmail.com> References: <47AA6251.3020805@gmail.com> Message-ID: <47AB4874.70405@dfki.de> Twan van Laarhoven wrote: > Hackage: > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/multiset-0.1 > Haddock: http://twan.home.fmf.nl/multiset/doc/ > Darcs: http://twan.home.fmf.nl/repos/multiset/ There used to be Daan's DData http://research.microsoft.com/users/daan/ddata.html How does your implementation relate to his (MultiSet and IntBag)? (partial reuse or duplication, differences) Cheers Christian From twanvl at gmail.com Thu Feb 7 13:39:31 2008 From: twanvl at gmail.com (Twan van Laarhoven) Date: Thu Feb 7 14:42:09 2008 Subject: ANNOUNCE: multiset 0.1 In-Reply-To: <47AB4874.70405@dfki.de> References: <47AA6251.3020805@gmail.com> <47AB4874.70405@dfki.de> Message-ID: <47AB5063.2010309@gmail.com> Christian Maeder wrote: > > There used to be Daan's DData > http://research.microsoft.com/users/daan/ddata.html > > How does your implementation relate to his (MultiSet and IntBag)? > (partial reuse or duplication, differences) I got many ideas of the interface from there. The implementation is really just a very thin wrapper around Data.(Int)Map. To implement the modules I copied Data.Set, and rewrote each function and adjusted the documentation here and there (changing set to multiset, etc.). The implementation is mostly straight forward. A random example: findMin = fst . Map.findMin . unMS The difference with Daan's MultiSet is that mine is more 'modern', it has the same interface of Data.Set. This means some minor differences (e.g. 'singleton' instead of 'single') and some additional functions such as maxView. DData's multiset also lacks Ord, Data and Typeable instances. Twan From dons at galois.com Thu Feb 7 13:46:48 2008 From: dons at galois.com (Don Stewart) Date: Thu Feb 7 14:56:04 2008 Subject: Proposal: Add Text.Read.maybeRead :: Read a => String -> Maybe a Message-ID: <20080207184648.GA19014@scytale.galois.com> This function is typically defined once per project. So its about time this safe variant of 'read' made it into the base. maybeRead :: Read a => String -> Maybe a maybeRead s = case reads s of [(x, "")] -> Just x _ -> Nothing Consideration period: 1 week. Patch to Text.Read attached. -------------- next part -------------- New patches: [Add maybeRead: a 'read' parser that fails in Maybe Don Stewart **20080207184215] { hunk ./Text/Read.hs 72 +-- | The 'maybeRead' function reads input from a string. +-- Parse failures are encapsulated in a 'Maybe' type, unlike +-- the standard 'read' function, which fails with an exception. +-- +-- > > maybeRead "42" +-- > Just 42 +-- +-- > > maybeRead "A2" +-- > Nothing +-- +-- > > maybeRead "0xA2" +-- > Just 162 +-- +maybeRead :: Read a => String -> Maybe a +maybeRead s = case reads s of + [(x, "")] -> Just x + _ -> Nothing + } Context: [FIX dynamic001 dynamic002: isTupleTyCon had rotted Simon Marlow **20080205103904 In the patch "Tuple tycons have parens around their names", the names of the tuple tycons were changed to include parens, but isTupleTyCon was not updated to match, which made tuple types show as "(,) a b" rather than "(a,b)" ] [deforestation rules for enumFromThenTo; based on a patch from Robin Houston Ian Lynagh **20080203152755] [Whitespace only Don Stewart **20080207183954] [FIX #1936: hGetBufNonBlocking was blocking on stdin/stdout/stderr Simon Marlow **20080124092203] [The default uncaught exception handler was adding an extra \n Simon Marlow **20080124091216] [add comment about lack of _chsize_s() Simon Marlow **20080123131248] [Windows: large file support for hFileSize and hSeek (#1771) Simon Marlow **20080123102904 ] [Export topHandler, topHandlerFastExit from GHC.TopHandler Ian Lynagh **20080120182429 We now use one of these in ghc when running with ghc -e ] [haddock attributes for haddock-2.0 Ross Paterson **20080120022308] [Data.List.sort: force elements from start to end. Bertram Felgenhauer **20071121101458 this prevents a stack overflow on sort (take 10^6 [1..]) ] [Fix comment on GHC.Ptr.minusPtr simonpj@microsoft.com**20080109114736] [Remove redundant imports of GHC.Err simonpj@microsoft.com**20080104091314 GHC.Base SOURCE-imports GHC.Err, and re-exports 'error'. So other modules need only import GHC.Base. This doesn't change the fact that these other modules are all compiled before GHC.Err, so they are all part of the module loop that starts with GHC.Base and finishes with GHC.Err. But it does reduce the occurrence of those SOURCE imports. ] [Generalise type of forever :: (Monad m) => m a -> m b Don Stewart **20080129191940] [Tuple tycons have parens around their names simonpj@microsoft**20071220171812 The name of the pair TyCon, in the Typeable instance, should be "(,)" not ",". Don't merge to 6.8; it's a minor API change. ] [Add groupWith, sortWith, the, to support generalised list comprehensions simonpj@microsoft.com**20071220111929 This the base-library patch to support the main compiler patch Implement generalised list comprehensions It just adds three functions to GHC.Exts. ] [Add GHC.Prim to exposedModules in the Haddock 0.x hook David Waern *-20071209173931 Please merge to the stable branch ] [Add GHC.Prim to exposedModules in the Haddock 0.x hook David Waern **20071209173931 Please merge to the stable branch ] [Simplify the GHC.Prim hack in base.cabal/Setup.hs Ian Lynagh **20071202215758] [Implement 'openTempFile' for nhc98. Malcolm.Wallace@cs.york.ac.uk**20071207133335] [docs: describe the changes to forkIO, and document forkOnIO Simon Marlow **20071205091423] [doc only: use realToFrac instead of fromRational.toRational Simon Marlow **20071205091334] [Add singletonP to GHC.PArr Roman Leshchinskiy **20071205220859] [FIX #1621: bug in Windows code for getCPUTime Simon Marlow **20071205120118 We were reading the components of FILETIME as CLong, when they should be unsigned. Word32 seems to be the correct type here. ] [protect console handler against concurrent access (#1922) Simon Marlow **20071204153940] [protect against concurrent access to the signal handlers (#1922) Simon Marlow **20071204110817] [restore fdToHandle' to avoid breaking clients (#1109) Simon Marlow **20071130135122 ] [note about how to convert CTime (aka EpochTime) to UTCTime Simon Marlow **20071130101648] [Fix some URLs Ian Lynagh **20071126214213] [Fix some links in haddock docs Ian Lynagh **20071126184428] [Don't try to make haddock links to the mtl package as we don't depend on it Ian Lynagh **20071126170631] [Escape some special characters in haddock docs Ian Lynagh **20071126163443] [FIX BUILD: maybeUpdateFile: ignore failures when removing the target Simon Marlow **20071123092219] [FIX #1753 Simon Marlow **20071122094207 hClose should close the Handle and unlock the file even if calling close() fails for some reason. ] [remove lockFile.h from install-includes Simon Marlow **20071121102248] [oops, we forgot to export traceShow Simon Marlow **20071121094300] [Fix compilation with GHC 6.2.x Simon Marlow **20071121084341] [Move file locking into the RTS, fixing #629, #1109 Simon Marlow **20071120121053 File locking (of the Haskell 98 variety) was previously done using a static table with linear search, which had two problems: the array had a fixed size and was sometimes too small (#1109), and performance of lockFile/unlockFile was suboptimal due to the linear search. Also the algorithm failed to count readers as required by Haskell 98 (#629). Now it's done using a hash table (provided by the RTS). Furthermore I avoided the extra fstat() for every open file by passing the dev_t and ino_t into lockFile. This and the improvements to the locking algorithm result in a healthy 20% or so performance increase for opening/closing files (see openFile008 test). ] [Only overwrite GHC/Prim.hs and GHC/Primopwrappers.hs if they change Simon Marlow **20071120102042 This avoids make doing unnecessary work after 'setup makefile'. ] [fix comment Simon Marlow **20071116091227] [Fix ` characters in elem's haddock docs Ian Lynagh **20071110173052] [Filter out GHC.Prim also for the Haddock step David Waern **20071109000806 Please merge to the GHC 6.8.2 branch ] [Add module of special magic GHC desugaring helper functions Simon Marlow **20071102160054 Currently containing only one such helper: (>>>) for arrow desugaring ] [add Control.Category to the nhc98 build Malcolm.Wallace@cs.york.ac.uk**20071030120459] [fix nhc98 build: need a qualified Prelude import Malcolm.Wallace@cs.york.ac.uk**20071030120410] [Fix performance regression: re-instate -funbox-strict-fields Simon Marlow **20071029150730 Yikes! While investigating the increase in code size with GHC 6.8 relative to 6.6, I noticed that in the transition to Cabal for the libraries we lost -funbox-strict-fields, which is more or less depended on by the IO library for performance. I'm astonished that we didn't notice this earlier! To reduce the chances of this happening again, I put -funbox-strict-fields in the OPTIONS_GHC pragma of the modules that need it. {-# UNPACK #-} pragmas would be better, though. ] [FIX BUILD: Haddock 1.x fails to parse (Prelude..) Simon Marlow **20071029131921] [new Control.Category, ghc ticket #1773 Ashley Yakeley **20071029022526] [new Control.Compositor module Ashley Yakeley **20071013074851 The Compositor class is a superclass of Arrow. ] [Fix doc building with Haddock 0.9 Simon Marlow **20071024090947 I was using a recent build here, which is more tolerant. ] [FIX #1258: document that openTempFile is secure(ish) Simon Marlow **20071023130928 Also change the mode from 0666 to 0600, which seems like a more sensible value and matches what C's mkstemp() does. ] [Clean up .cabal file a bit Duncan Coutts **20071022132708 specify build-type and cabal-version >= 1.2 put extra-tmp-files in the right place use os(windows) rather than os(mingw32) ] [FIX #1652: openTempFile should accept an empty string for the directory Simon Marlow **20071018122345] [clean up duplicate code Simon Marlow **20071017141311] [expose the value of +RTS -N as GHC.Conc.numCapabilities (see #1733) Simon Marlow **20071009132042] [base in 6.8 and head branch should be version 3.0 Don Stewart **20071007150408] [typo Simon Marlow **20070917130703] [put extra-tmp-files field in the right place Simon Marlow **20070914140812] [Add more entries to boring file Ian Lynagh **20070913210500] [Add a boring file Ian Lynagh **20070913204641] [TAG 2007-09-13 Ian Lynagh **20070913215720] [FIX #1689 (openTempFile returns wrong filename) Tim Chevalier **20070913052025] [TAG ghc-6.8 branched 2007-09-03 Ian Lynagh **20070903155541] [Remove some incorrect rules; fixes #1658: CSE [of Doubles] changes semantics Ian Lynagh **20070904134140] [make hWaitForInput/hReady not fail with "invalid argument" on Windows Simon Marlow **20070830131115 See #1198. This doesn't fully fix it, because hReady still always returns False on file handles. I'm not really sure how to fix that. ] [Fix haddock docs in Hashtable Ian Lynagh **20070830154131] [Fix building HashTable: Use ord rather than fromEnum Ian Lynagh **20070830150214] [Better hash functions for Data.HashTable, from Jan-Willem Maessen Ian Lynagh **20070830142844] [Remove redundant include/Makefile Ian Lynagh **20070828205659] [Make arrays safer (e.g. trac #1046) Ian Lynagh **20070810163405] [delete configure droppings in setup clean Simon Marlow **20070824104100] [FIX #1282: 64-bit unchecked shifts are not exported from base Simon Marlow **20070823135033 I've exported these functions from GHC.Exts. They are still implemented using the FFI underneath, though. To avoid conditional exports, on a 64-bit build: uncheckedShiftL64# = uncheckShiftL# (etc.) which has a different type than the 32-bit version of uncheckedShiftL64#, but at least GHC.Exts exports the same names. ] [Fix hashInt Ian Lynagh **20070821140706 As pointed out in http://www.haskell.org/pipermail/glasgow-haskell-bugs/2007-August/009545.html the old behaviour was Prelude Data.HashTable> map hashInt [0..10] [0,-1,-1,-2,-2,-2,-3,-3,-4,-4,-4] Fixed according to the "Fibonacci Hashing" algorithm described in http://www.brpreiss.com/books/opus4/html/page213.html http://www.brpreiss.com/books/opus4/html/page214.html ] [test impl(ghc) instead of IsGHC Ross Paterson **20070819233500] [fpstring.h has moved to bytestring Ross Paterson **20070819233815] [remove now-unused SIG constants Ross Paterson **20070819233745] [include Win32 extra-libraries for non-GHC's too Ross Paterson **20070819233611] [Don't import Distribution.Setup in Setup.hs as we no longer need it Ian Lynagh **20070816151643] [Correct the swapMVar haddock doc Ian Lynagh **20070814145028] [install Typeable.h for use by other packages Malcolm.Wallace@cs.york.ac.uk**20070813112855] [Don't try to build modules no longer living in base. Malcolm.Wallace@cs.york.ac.uk**20070813112803] [Move Data.{Foldable,Traversable} back to base Ian Lynagh **20070812165654 The Array instances are now in Data.Array. ] [Remove bits left over from the old build system Ian Lynagh **20070811135019] [Move the datamap001 (our only test) to the containers package Ian Lynagh **20070803180932] [Data.Array* and Data.PackedString have now moved to their own packages Ian Lynagh **20070801235542] [Remove a number of modules now in a "containers" package Ian Lynagh **20070801223858] [Remove System.Posix.Signals (moving to unix) Ian Lynagh **20070729215213] [bytestring is now in its own package Ian Lynagh **20070729132215] [Export throwErrnoPath* functions Ian Lynagh **20070722002923] [Add simple haddock docs for throwErrnoPath* functions Ian Lynagh **20070722002817] [Move throwErrnoPath* functions from unix:System.Posix.Error Ian Lynagh **20070722002746] [Clarify the swapMVar haddock doc Ian Lynagh **20070807185557] [fix Haddock markup Simon Marlow **20070802081717] [Temporarily fix breakage for nhc98. Malcolm.Wallace@cs.york.ac.uk**20070801163750 A recent patch to System.IO introduced a cyclic dependency on Foreign.C.Error, and also inadvertently dragged along System.Posix.Internals which has non-H'98 layout, causing many build problems. The solution for now is to #ifndef __NHC__ all of the recent the openTempFile additions, and mark them non-portable once again. (I also took the opportunity to note a number of other non-portable functions in their Haddock comments.) ] [Generalise the type of synthesize, as suggested by Trac #1571 simonpj@microsoft**20070801125208 I have not looked at the details, but the type checker is happy with the more general type, and more general types are usually a Good Thing. ] [Fix fdToHandle on Windows Ian Lynagh **20070730133139 The old setmode code was throwing an exception, and I'm not sure it is meant to do what we need anyway. For now we assume that all FDs are both readable and writable. ] [Correct Windows OS name in cabal configuration Ian Lynagh **20070729161739] [Use cabal configurations rather than Setup hacks Ian Lynagh **20070729132157] [Handle buffers should be allocated with newPinnedByteArray# always Simon Marlow **20070725095550 Not just on Windows. This change is required because we now use safe foreign calls for I/O on blocking file descriptors with the threaded RTS. Exposed by concio001.thr on MacOS X: MacOS apparently uses smaller buffers by default, so they weren't being allocated as large objects. ] [fix Hugs implementation of openTempFile Ross Paterson **20070724114003] [Hugs only: avoid dependency cycle Ross Paterson **20070724113852] [open(Binary)TempFile is now portable Ian Lynagh **20070722152752] [Tweak temporary file filename chooser Ian Lynagh **20070722105445] [Move open(Binary)TempFile to System.IO Ian Lynagh **20070722010205] [Rename openFd to fdToHandle' Ian Lynagh **20070721235538 The name collision with System.Posix.IO.openFd made my brain hurt. ] [Add a test for Data.Map, for a bug on the libraries@ list Ian Lynagh **20070721002119] [fix Data.Map.updateAt Bertram Felgenhauer **20070718150340 See http://haskell.org/pipermail/libraries/2007-July/007785.html for a piece of code triggering the bug. updateAt threw away parts of the tree making up the map. ] [in hClose, free the handle buffer by replacing it with an empty one Simon Marlow **20070719161419 This helps reduce the memory requirements for a closed but unfinalised Handle. ] [Implement GHC.Environment.getFullArgs Ian Lynagh **20070717141918 This returns all the arguments, including those normally eaten by the RTS (+RTS ... -RTS). This is mainly for ghc-inplace, where we need to pass /all/ the arguments on to the real ghc. e.g. ioref001(ghci) was failing because the +RTS -K32m -RTS wasn't getting passed on. ] [Define stripPrefix; fixes trac #1464 Ian Lynagh **20070714235204] [no need to hide Maybe Malcolm.Wallace@cs.york.ac.uk**20070710154058] [Add a more efficient Data.List.foldl' for GHC (from GHC's utils/Util.lhs) Ian Lynagh **20070706205526] [Remove include-dirs ../../includes and ../../rts Ian Lynagh **20070705205356 We get these by virtue of depending on the rts package. ] [FIX #1131 (newArray_ allocates an array full of garbage) Simon Marlow **20070704102020 Now newArray_ returns a deterministic result in the ST monad, and behaves as before in other contexts. The current newArray_ is renamed to unsafeNewArray_; the MArray class therefore has one more method than before. ] [change nhc98 option from -prelude to --prelude Malcolm.Wallace@cs.york.ac.uk**20070702150355] [Word is a type synonym in nhc98 - so class instance not permitted. Malcolm.Wallace@cs.york.ac.uk**20070629122035] [fix bug in writes to blocking FDs in the non-threaded RTS Simon Marlow **20070628134320] [Modernize printf. lennart.augustsson@credit-suisse.com**20070628083852 Add instances for Int8, Int16, Int32, Int64, Word, Word8, Word16, Word32, and Word64. Handle + flag. Handle X, E, and G formatting characters. Rewrite internals to make it simpler. ] [Speed up number printing and remove the need for Array by using the standard 'intToDigit' routine John Meacham **20070608182353] [Use "-- //" (2 spaces) rather than "-- //" (1) to avoid tripping haddock up Ian Lynagh **20070627010930 Are we nearly there yet? ] [Use a combination of Haskell/C comments to ensure robustness. Malcolm.Wallace@cs.york.ac.uk**20070626095222 e.g. -- // ensures that _no_ preprocessor will try to tokenise the rest of the line. ] [Change C-style comments to Haskell-style. Malcolm.Wallace@cs.york.ac.uk**20070625094515 These two headers are only ever used for pre-processing Haskell code, and are never seen by any C tools except cpp. Using the Haskell comment convention means that cpphs no longer needs to be given the --strip option to remove C comments from open code. This is a Good Thing, because all of /* */ and // are valid Haskell operator names, and there is no compelling reason to forbid using them in files which also happen to have C-preprocessor directives. ] [makefileHook needs to generate PrimopWrappers.hs too Simon Marlow **20070622073424] [Hugs now gets MonadFix(mfix) from its prelude Ross Paterson **20070620000343] [Typo (consUtils.hs -> consUtils.h) Ian Lynagh **20070619124140] [install dependent include files and Typeable.h Bertram Felgenhauer **20070613041734] [update prototype following inputReady->fdReady change Simon Marlow **20070614095309] [FIX hGetBuf001: cut-and-pasto in readRawBufferNoBlock Simon Marlow **20070614094222] [fix description of CWStringLen Ross Paterson **20070605223345] [Remove unsafeCoerce-importing kludgery in favor of Unsafe.Coerce Isaac Dupree **20070601203625] [--configure-option and --ghc-option are now provided by Cabal Ross Paterson **20070604115233] [Data.PackedString: Data.Generics is GHC-only Ross Paterson **20070529232427] [Add Data instance for PackedString; patch from greenrd in trac #1263 Ian Lynagh **20070529205420] [Control.Concurrent documentation fix shae@ScannedInAvian.com**20070524163325] [add nhc98-options: field to .cabal file Malcolm.Wallace@cs.york.ac.uk**20070528122626] [add a dummy implementation of System.Timeout.timeout for nhc98 Malcolm.Wallace@cs.york.ac.uk**20070528110309] [Add System.Timeout to base.cabal Ian Lynagh **20070527123314 Filtered out for non-GHC by Setup.hs. ] [add module Data.Fixed to nhc98 build Malcolm.Wallace@cs.york.ac.uk**20070525141021] [DIRS now lives in package Makefile, not script/pkgdirlist Malcolm.Wallace@cs.york.ac.uk**20070525111749] [delete unused constants Ross Paterson **20070525001741] [remove System.Cmd and System.Time too Malcolm.Wallace@cs.york.ac.uk**20070524163200] [remove locale as well Malcolm.Wallace@cs.york.ac.uk**20070524161943] [nhc98 version of instance Show (a->b) copied from Prelude Malcolm.Wallace@cs.york.ac.uk**20070524160615] [remove directory, pretty, and random bits from base for nhc98 Malcolm.Wallace@cs.york.ac.uk**20070524160608] [Remove Makefile and package.conf.in (used in the old build system) Ian Lynagh **20070524142545] [Split off process package Ian Lynagh **20070523210523] [Fix comment: maperrno is in Win32Utils.c, not runProcess.c Ian Lynagh **20070523181331] [System.Locale is now split out Ian Lynagh **20070519132638] [Split off directory, random and old-time packages Ian Lynagh **20070519120642] [Remove Control.Parallel*, now in package parallel Ian Lynagh **20070518165431] [Remove the pretty-printing modules (now in package pretty( Ian Lynagh **20070518162521] [add install-includes: field Simon Marlow **20070517094948] [correct the documentation for newForeignPtr Simon Marlow **20070516082019] [When doing safe writes, handle EAGAIN rather than raising an exception Simon Marlow **20070515114615 It might be that stdin was set to O_NONBLOCK by someone else, and we should handle this case. (this happens with GHCi, I'm not quite sure why) ] [Use FilePath to make paths when building GHC/Prim.hs and GHC/PrimopWrappers.hs Ian Lynagh **20070514110409] [Build GHC/Prim.hs and GHC/PrimopWrappers.hs from Cabal Ian Lynagh **20070509142655] [fix imports for non-GHC Ross Paterson **20070513001138] [Give an example of how intersection takes elements from the first set Ian Lynagh **20070512160253] [further clarify the docs for 'evaluate' Malcolm.Wallace@cs.york.ac.uk**20070508101124] [improve documentation for evaluate Simon Marlow **20070508081712] [FIX: #724 (tee complains if used in a process started by ghc) Simon Marlow **20070507123537 Now, we only set O_NONBLOCK on file descriptors that we create ourselves. File descriptors that we inherit (stdin, stdout, stderr) are kept in blocking mode. The way we deal with this differs between the threaded and non-threaded runtimes: - with -threaded, we just make a safe foreign call to read(), which may block, but this is ok. - without -threaded, we test the descriptor with select() before attempting any I/O. This isn't completely safe - someone else might read the data between the select() and the read() - but it's a reasonable compromise and doesn't seem to measurably affect performance. ] [the "unknown" types are no longer required Simon Marlow **20070426135931] [Make Control.Exception buildable by nhc98. Malcolm.Wallace@cs.york.ac.uk**20070504105548 The nhc98 does not have true exceptions, but these additions should be enough infrastructure to pretend that it does. Only IO exceptions will actually work. ] [Trim imports, remove a cycle simonpj@microsoft**20070503123010 A first attempt at removing gratuitous cycles in the base package. I've removed the useless module GHC.Dynamic, which gets rid of a cycle; and trimmed off various unnecesary imports. This also fixes the IsString import problem. ] [Be less quiet about building the base package simonpj@microsoft**20070503093707] [Remove Splittable class (a vestige of linear implicit parameters) simonpj@microsoft**20070221104329] [Add IsString to exports of GHC.Exts simonpj@microsoft**20070221104249] [tweak documentation as per suggestion from Marc Weber on libraries@haskell.org Simon Marlow **20070426075921] [Add extra libraries when compiling with GHC on Windows Ian Lynagh **20070424213127] [Follow Cabal changes in Setup.hs Ian Lynagh **20070418114345] [inclusion of libc.h is conditional on __APPLE__ Malcolm.Wallace@cs.york.ac.uk**20070417085556] [MERGE: fix ugly uses of memcpy foreign import inside ST Simon Marlow **20070416101530 fixes cg026 ] [Fix configure with no --with-cc Ian Lynagh **20070415165143] [MacOS 10.3 needs #include as well Malcolm.Wallace@cs.york.ac.uk**20070414155507] [For nhc98 only, use hsc2hs to determine System.Posix.Types. Malcolm.Wallace@cs.york.ac.uk**20070413155831 Avoids the existing autoconf stuff, by introducing an auxiliary module called NHC.PosixTypes that uses hsc2hs, which is then simply re-exported from System.Posix.Types. ] [we need a makefileHook too Simon Marlow **20070413151307] [Remove unnecesary SOURCE import of GHC.Err in GHC.Pack Ian Lynagh **20070412235908] [add System.Posix.Types to default nhc98 build Malcolm.Wallace@cs.york.ac.uk**20070412195026] [mark System.IO.openTempFile as non-portable in haddocks Malcolm.Wallace@cs.york.ac.uk**20070412135359] [Don't turn on -Werror in Data.Fixed Ian Lynagh **20070411155721 This may be responsible for the x86_64/Linux nightly build failing. ] [Fix -Wall warnings Ian Lynagh **20070411004929] [Add missing case in removePrefix Ian Lynagh **20070411002537] [Allow additional options to pass on to ./configure to be given Ian Lynagh **20070406151856] [Hugs only: fix location of unsafeCoerce Ross Paterson **20070406113731] [fix isPortableBuild test Ross Paterson **20070406111304] [Unsafe.Coerce doesn't need Prelude Ian Lynagh **20070405175930] [make Setup and base.cabal suitable for building the libraries with GHC Ian Lynagh **20070308163824] [HsByteArray doesn't exist Ian Lynagh **20070404163051] [Don't use Fd/FD in foreign decls Ian Lynagh **20070404155822 Using CInt makes it much easier to verify that it is right, and we won't get caught out by possible newtype switches between CInt/Int. ] [HsByteArray doesn't exist Ian Lynagh **20070404155732] [Fix braino Ian Lynagh **20070404144508] [Fix incorrect changes to C types in a foreign import for nhc98. Malcolm.Wallace@cs.york.ac.uk**20070404120954 If we use type CTime, it needs to be imported. Also, CTime is not an instance of Integral, so use some other mechanism to convert it. ] [Fix C/Haskell type mismatches Ian Lynagh **20070403194943] [add new module Unsafe.Coerce to build system Malcolm.Wallace@cs.york.ac.uk**20070403131333] [Fix type mismatches between foreign imports and HsBase.h Ian Lynagh **20070403001611 Merge to stable, checking for interface changes. ] [put 'unsafeCoerce' in a standard location Malcolm.Wallace@cs.york.ac.uk**20061113114103] [fix for nhc98 build Malcolm.Wallace@cs.york.ac.uk**20070402141712] [Function crossMapP for fixing desugaring of comprehensions Manuel M T Chakravarty **20070402082906 Merge into 6.6 branch. ] [Add min/max handling operations for IntSet/IntMap jeanphilippe.bernardy@gmail.com**20070315072352] [Monoid instance for Maybe and two wrappers: First and Last. trac proposal #1189 Jeffrey Yasskin **20070309062550] [Fix the type of wgencat Ian Lynagh **20070329164223] [fix strictness of foldr/build rule for take, see #1219 Simon Marlow **20070327103941] [remove Makefile.inc (only affects nhc98) Malcolm.Wallace@cs.york.ac.uk**20070320120057] [copyBytes copies bytes, not elements; fixes trac #1203 Ian Lynagh **20070312113555] [Add ioeGetLocation, ioeSetLocation to System/IO/Error.hs; trac #1191 Ian Lynagh **20070304130315] [fix race condition in prodServiceThread Simon Marlow **20070307134330 See #1187 ] [Prevent duplication of unsafePerformIO on a multiprocessor Simon Marlow **20070306145424 Fixes #986. The idea is to add a new operation noDuplicate :: IO () it is guaranteed that if two threads have executed noDuplicate, then they are not duplicating any computation. We now provide two new unsafe operations: unsafeDupablePerformIO :: IO a -> a unsafeDupableInterleaveIO :: IO a -> IO a which are equivalent to the old unsafePerformIO and unsafeInterleaveIO respectively. The new versions of these functions are defined as: unsafePerformIO m = unsafeDupablePerformIO (noDuplicate >> m) unsafeInterleaveIO m = unsafeDupableInterleaveIO (noDuplicate >> m) ] [expand docs for forkOS Simon Marlow **20070305160921] [document timeout limitations Peter Simons **20070228223540] [So many people were involved in the writing of this module that Peter Simons **20070228223415 it feels unfair to single anyone out as the lone copyright holder. ] [This patch adds a timeout function to the base libraries. Trac #980 is Peter Simons **20070126222615 concerned with this issue. The design guideline for this implementation is that 'timeout N E' should behave exactly the same as E as long as E doesn't time out. In our implementation, this means that E has the same myThreadId it would have without the timeout wrapper. Any exception E might throw cancels the timeout and propagates further up. It also possible for E to receive exceptions thrown to it by another thread. ] [PArr: fixed permutations Manuel M T Chakravarty **20070305055807] [Add Data.String, containing IsString(fromString); trac proposal #1126 Ian Lynagh **20070130134841 This is used by the overloaded strings extension (-foverloaded-strings in GHC). ] [GHC.PArr: add bounds checking Manuel M T Chakravarty **20070302053224] [Bump nhc98 stack size for System/Time.hsc sven.panne@aedion.de**20070301153009] [FDs are CInts now, fixing non-GHC builds sven.panne@aedion.de**20070225105620] [Fixed PArr.dropP Manuel M T Chakravarty **20070222032405 - Thanks to Audrey Tang for the bug report ] [Keep the same FD in both halves of a duplex handle when dup'ing Ian Lynagh **20070220141039 Otherwise we only close one of the FDs when closing the handle. Fixes trac #1149. ] [Remove more redundant FD conversions Ian Lynagh **20070220092520] [Fix FD changes on Windows Ian Lynagh **20070220091516] [Consistently use CInt rather than Int for FDs Ian Lynagh **20070219233854] [Fix the types of minView/maxView (ticket #1134) jeanphilippe.bernardy@gmail.com**20070210065115] [fix for hashString, from Jan-Willem Maessen (see #1137) Simon Marlow **20070215094304 ] [fix to getUSecOfDay(): arithmetic was overflowing Simon Marlow **20070214161719] [The Windows counterpart to 'wrapround of thread delays' Ian Lynagh **20070209173510] [wrapround of thread delays Neil Davies **20070129160519 * made the wrapround of the underlying O/S occur before the wrapround of the delayed threads by making threads delay in microseconds since O/S epoch (1970 - Unix, 1601 - Windows) stored in Word64. * removed redundant calls reading O/S realtime clock * removed rounding to 1/50th of sec for timers * Only for Unix version of scheduler. ] [Whitespace changes only Ian Lynagh **20070206232722] [Add some type sigs Ian Lynagh **20070206232439] [Use static inline rather than extern inline/inline Ian Lynagh **20070205203628 I understand this is more portable, and it also fixes warnings when C things we are wrapping are themselves static inlines (which FD_ISSET is on ppc OS X). ] [add derived instances for Dual monoid Ross Paterson **20070202190847] [add doc pointers to Foldable Ross Paterson **20070202110931 Could be applied to STABLE. ] [Eliminate some warnings Ian Lynagh **20060729220854 Eliminate warnings in the libraries caused by mixing pattern matching with numeric literal matching. ] [Remove IsString(fromString) from the Prelude Ian Lynagh **20070130124136] [Add Kleisli composition Don Stewart **20061113015442] [IsString is GHC-only (so why is it in the Prelude?) Ross Paterson **20070123183007] [Applicative and Monad instances for Tree Ross Paterson **20070115174510] [Add IsString class for overloaded string literals. lennart@augustsson.net**20061221210532] [Added examples, more detailed documentation to Data.List Extracting sublists functions Andriy Palamarchuk **20061204164710] [fix threadDelay Simon Marlow **20070117091702 In "Add support for the IO manager thread" I accidentally spammed part of "Make sure the threaded threadDelay sleeps at least as long as it is asked", which is why the ThreadDelay001 test has been failing. ] [update section on "blocking" Simon Marlow **20070116124328] [Fix crash with (minBound :: Int*) `div (-1) as result is maxBound + 1. Ian Lynagh **20070115142005] [version of example using Tomasz Zielonka's technique Ross Paterson **20070105175907] [Added Unknowns for higher kinds Pepe Iborra **20061108155938] [Improved the Show instance for Unknown Pepe Iborra **20060813111816] [Show instance for GHC.Base.Unknown mnislaih@gmail.com**20060801233530] [Introduce Unknowns for the closure viewer. Add breakpointCond which was missing mnislaih@gmail.com**20060725174537] [Fix missing comma in Fractional documentation Alec Berryman **20061201173237] [Mention that throwTo does not guarantee promptness of delivery simonpj@microsoft**20061211123215] [Add note about synhronous delivery of throwTo simonpj@microsoft**20061211122257] [documentation for installHandler Simon Marlow **20061205154927 merge to 6.6 ] [dos2unix Simon Marlow **20061204095439] [don't try to compile this on Unix Simon Marlow **20061204095427] [TAG 6.6 release Ian Lynagh **20061011124740] [TAG Version 2.1 Ian Lynagh **20061009114014] [Bump version number Ian Lynagh **20061009114009] [Add support for the IO manager thread on Windows Simon Marlow **20061201152042 Fixes #637. The test program in that report now works for me with -threaded, but it doesn't work without -threaded (I don't know if that's new behaviour or not, though). ] [deriving (Eq, Ord, Enum, Show, Read, Typeab) for ConsoleEvent Simon Marlow **20061201144032] [Make sure the threaded threadDelay sleeps at least as long as it is asked to Ian Lynagh **20061128204807] [Add comments about argument order to the definitions of gmapQ and constrFields simonpj@microsoft**20061124164505] [Hugs: add Control.Parallel.Strategies Ross Paterson **20061124161039] [Move instance of Show Ptr to Ptr.hs (fewer orphans) simonpj@microsoft.com**20061124100639] [Add type signatures simonpj@microsoft.com**20061124100621] [Add an example of the use of unfoldr, following doc feedback from dozer Don Stewart **20061124011249] [trim imports Ross Paterson **20061123190352] [Data.Graph is now portable (enable for nhc98) Malcolm.Wallace@cs.york.ac.uk**20061123174913] [remove Data.FunctorM and Data.Queue Ross Paterson **20061112001046 These were deprecated in 6.6, and can thus be removed in 6.8. ] [make Data.Graph portable (no change to the interface) Ross Paterson **20061122010040 The algorithm now uses STArrays on GHC and IntSets elsewhere. (Hugs has STArrays, but avoiding them saves a -98, and boxed arrays aren't fast under Hugs anyway.) ] [One less unsafeCoerce# in the tree Don Stewart **20061120120242] [typo in comment Ross Paterson **20061120115106] [fix shift docs to match ffi spec Ross Paterson **20061117003144] [(nhc98) use new primitive implementations of h{Put,Get}Buf. Malcolm.Wallace@cs.york.ac.uk**20061116173104] [The wrong 'cycle' was exported from Data.ByteString.Lazy.Char8, spotted by sjanssen Don Stewart **20061110021311] [LPS chunk sizes should be 16 bytes, not 17. Don Stewart **20061110021254] [Update comments on Prelude organisation in GHC/Base.lhs Ian Lynagh **20061115001926] [Control.Parallel.Strategies clean-up: Added export list to avoid exporting seq, fixed import list strangeness that haddock choked on, and moved the deprecated functions to a separate section. bringert@cs.chalmers.se**20061113224202] [Control.Parallel.Strategies: added NFData instances for Data.Int.*, Data.Word.*, Maybe, Either, Map, Set, Tree, IntMap, IntSet. bringert@cs.chalmers.se**20061113221843] [Control.Parallel.Strategies: deprecate sPar, sSeq, Assoc, fstPairFstList, force and sforce. bringert@cs.chalmers.se**20061113215219 Code comments indicated that sPar and sSeq have been superceded by sparking and demanding, and that Assoc, fstPairFstList, force and sforce are examples and hacks needed by the Lolita system. ] [add Control.Monad.Instances to nhc98 build Malcolm.Wallace@cs.york.ac.uk**20061113113221] [Control.Parallel.Strategies: clarified documentation of parListChunk. bringert@cs.chalmers.se**20061112232904] [Added and cleaned up Haddock comments in Control.Parallel.Strategies. bringert@cs.chalmers.se**20061112220445 Many of the definitions in Control.Parallel.Strategies had missing or unclear Haddock comments. I converted most of the existing plain code comments to haddock comments, added some missing documentation and cleaned up the existing Haddock mark-up. ] [Fix broken pragmas; spotted by Bulat Ziganshin Ian Lynagh **20061111205916] [add doc link to bound threads section Ross Paterson **20060929103252] [hide Data.Array.IO.Internals Ross Paterson **20061111113248 It's hidden from haddock, and everything it exports is re-exported by Data.Array.IO. ] [add Data.Function Malcolm.Wallace@cs.york.ac.uk**20061110142710] [add Data.Function Ross Paterson **20061110141354] [whitespace only Ross Paterson **20061110141326] [move fix to Data.Function Ross Paterson **20061110141120] [import Prelude Ross Paterson **20061110140445] [Added Data.Function (Trac ticket #979). Nils Anders Danielsson **20061110122503 + A module with simple combinators working solely on and with functions. + The only new function is "on". + Some functions from the Prelude are re-exported. ] [__hscore_long_path_size is not portable beyond GHC Malcolm.Wallace@cs.york.ac.uk**20061110113222] [redefine writeFile and appendFile using withFile Ross Paterson **20061107140359] [add withFile and withBinaryFile (#966) Ross Paterson **20061107134510] [remove conflicting import for nhc98 Malcolm.Wallace@cs.york.ac.uk**20061108111215] [Add intercalate to Data.List (ticket #971) Josef Svenningsson **20061102122052] [non-GHC: fix canonicalizeFilePath Ross Paterson **20061107133902 I've also removed the #ifdef __GLASGOW_HASKELL__ from the proper Windows versions of a few functions. These will need testing with Hugs on Windows. ] [enable canonicalizePath for non-GHC platforms Simon Marlow **20061107121141] [Update documentation for hWaitForInput Simon Marlow **20061107111430 See #972 Merge to 6.6 branch. ] [Use unchecked shifts to implement Data.Bits.rotate Samuel Bronson **20061012125553 This should get rid of those cases, maybe lower the size enough that the inliner will like it? ] [fix Haddock module headers Ross Paterson **20061106124140] [fix example in docs Ross Paterson **20061106115628] [Add intercalate and split to Data.List Josef Svenningsson *-20061024172357] [Data.Generics.Basics is GHC-only Ross Paterson **20061102111736] [#ifdef around non-portable Data.Generics.Basics Malcolm.Wallace@cs.york.ac.uk**20061102103445] [Add deriving Data to Complex simonpj@microsoft**20061101102059] [minor clarification of RandomGen doc Ross Paterson **20061030230842] [rearrange docs a bit Ross Paterson **20061030161223] [Add intercalate and split to Data.List Josef Svenningsson **20061024172357] [Export pseq from Control.Parallel, and use it in Control.Parallel.Strategies Simon Marlow **20061027150141] [`par` should be infixr 0 Simon Marlow **20061027130800 Alas, I didn't spot this due to lack of testing, and the symptom is that an expression like x `par` y `seq z will have exactly the wrong parallelism properties. The workaround is to add parantheses. I think we could push this to the 6.6 branch. ] [fix example in comment Ross Paterson **20061023163925] [Use the new Any type for dynamics (GHC only) simonpj@microsoft**20061019160408] [add Data.Sequence to nhc98 build Malcolm.Wallace@cs.york.ac.uk**20061012135200] [Remove Data.FiniteMap, add Control.Applicative, Data.Traversable, and Malcolm.Wallace@cs.york.ac.uk**20061012095605 Data.Foldable to the nhc98 build. ] [STM invariants tharris@microsoft.com**20061007123253] [Inline shift in GHC's Bits instances for {Int,Word}{,8,16,32,64} Samuel Bronson **20061009020906] [Don't create GHC.Prim when bootstrapping; we can't, and we don't need it Ian Lynagh **20061004165355] [Data.ByteString: fix lazyness of take, drop & splitAt Don Stewart **20061005011703 ByteString.Lazy's take, drop and splitAt were too strict when demanding a byte string. Spotted by Einar Karttunen. Thanks to him and to Bertram Felgenhauer for explaining the problem and the fix. ] [Fix syntax error that prevents building Haddock documentation on Windows brianlsmith@gmail.com**20060917013530] [Hugs only: unbreak typeRepKey Ross Paterson **20060929102743] [make hGetBufNonBlocking do something on Windows w/ -threaded Simon Marlow **20060927145811 hGetBufNonBlocking will behave the same as hGetBuf on Windows now, which is better than just crashing (which it did previously). ] [add typeRepKey :: TypeRep -> IO Int Simon Marlow **20060927100342 See feature request #880 ] [fix header comment Ross Paterson **20060926135843] [Add strict versions of insertWith and insertWithKey (Data.Map) jeanphilippe.bernardy@gmail.com**20060910162443] [doc tweaks, including more precise equations for evaluate Ross Paterson **20060910115259] [Sync Data.ByteString with stable branch Don Stewart **20060909050111 This patch: * hides the LPS constructor (its in .Base if you need it) * adds functions to convert between strict and lazy bytestrings * and adds readInteger ] [Typeable1 instances for STM and TVar Ross Paterson **20060904231425] [remove obsolete Hugs stuff Ross Paterson **20060904223944] [Cleaner isInfixOf suggestion from Ross Paterson John Goerzen **20060901143654] [New function isInfixOf that searches a list for a given sublist John Goerzen **20060831151556 Example: isInfixOf "Haskell" "I really like Haskell." -> True isInfixOf "Ial" "I really like Haskell." -> False This function was first implemented in MissingH as MissingH.List.contains ] [Better doc on Data.Map.lookup: explain what the monad is for jeanphilippe.bernardy@gmail.com**20060903133440] [fix hDuplicateTo on Windows Simon Marlow **20060901150016 deja vu - I'm sure I remember fixing this before... ] [Improve documentation of atomically simonpj@microsoft**20060714120207] [Add missing method genRange for StdGen (fixes #794) simonpj@microsoft**20060707151901 MERGE TO STABLE Trac #794 reports (correctly) that the implementation of StdGen only returns numbers in the range (0..something) rather than (minBound, maxBound), which is what StdGen's genRange claims. This commit fixes the problem, by implementing genRange for StdGen (previously it just used the default method). ] [mark nhc98 import hack Ross Paterson **20060831125219] [remove some outdated comments Simon Marlow **20060831104200] [import Control.Arrow.ArrowZero to help nhc98's type checker Malcolm.Wallace@cs.york.ac.uk**20060831101105] [remove Text.Regex(.Posix) from nhc98 build Malcolm.Wallace@cs.york.ac.uk**20060831101016] [add Data.Foldable.{msum,asum}, plus tweaks to comments Ross Paterson **20060830163521] [fix doc typo Ross Paterson **20060830134123] [add Data.Foldable.{for_,forM_} and Data.Traversable.{for,forM} Ross Paterson **20060830133805 generalizing Control.Monad.{forM_,forM} ] [Make length a good consumer simonpj@microsoft*-20060508142726 Make length into a good consumer. Fixes Trac bug #707. (Before length simply didn't use foldr.) ] [Add Control.Monad.forM and forM_ Don Stewart **20060824081118 flip mapM_ is more and more common, I find. Several suggestions have been made to add this, as foreach or something similar. This patch does just that: forM :: (Monad m) => [a] -> (a -> m b) -> m [b] forM_ :: (Monad m) => [a] -> (a -> m b) -> m () So we can write: Prelude Control.Monad> forM_ [1..4] $ \x -> print x 1 2 3 4 ] [Hide internal module from haddock in Data.ByteString Don Stewart **20060828011515] [add advice on avoiding import ambiguities Ross Paterson **20060827170407] [expand advice on importing these modules Ross Paterson **20060827164044] [add Haddock marker Ross Paterson **20060827115140] [Clarify how one hides Prelude.catch Don Stewart **20060826124346 User feedback indicated that an example was required, of how to hide Prelude.catch, so add such an example to the docs ] [Workaround for OSes that don't have intmax_t and uintmax_t Ian Lynagh **20060825134936 OpenBSD (and possibly others) do not have intmax_t and uintmax_t types: http://www.mail-archive.com/haskell-prime@haskell.org/msg01548.html so substitute (unsigned) long long if we have them, otherwise (unsigned) long. ] [add docs for par Simon Marlow **20060825110610] [document minimal complete definition for Bits Ross Paterson **20060824140504] [C regex library bits have moved to the regex-posix package Simon Marlow **20060824132311] [Add shared Typeable support (ghc only) Esa Ilari Vuokko **20060823003126] [this should have been removed with the previous patch Simon Marlow **20060824121223] [remove Text.Regx & Text.Regex.Posix Simon Marlow **20060824094615 These are subsumed by the new regex-base, regex-posix and regex-compat packages. ] [explicitly tag Data.ByteString rules with the FPS prefix. Don Stewart **20060824041326] [Add spec rules for sections in Data.ByteString Don Stewart **20060824012611] [Sync Data.ByteString with current stable branch, 0.7 Don Stewart **20060823143338] [add notes about why copyFile doesn't remove the target Simon Marlow **20060823095059] [copyFile: try removing the target file before opening it for writing Simon Marlow *-20060822121909] [copyFile: try removing the target file before opening it for writing Simon Marlow **20060822121909] [add alternative functors and extra instances Ross Paterson **20060821152151 * Alternative class, for functors with a monoid * instances for Const * instances for arrows ] [generate Haddock docs on all platforms Simon Marlow **20060821131612] [remove extra comma from import Ross Paterson **20060819173954] [fix docs for withC(A)StringLen Ross Paterson **20060818170328] [use Haskell'98 compliant indentation in do blocks Malcolm.Wallace@cs.york.ac.uk**20060818130810] [use correct names of IOArray operations for nhc98 Malcolm.Wallace@cs.york.ac.uk**20060818130714] [add mapMaybe and mapEither, plus WithKey variants Ross Paterson **20060817235041] [remove Text.Html from nhc98 build Malcolm.Wallace@cs.york.ac.uk**20060817135502] [eliminate more HOST_OS tests Ross Paterson **20060815190609] [Hugs only: disable unused process primitives Ross Paterson **20060813184435 These were the cause of Hugs bug #30, I think, and weren't used by Hugs anyway. ] [markup fix to Data.HashTable Ross Paterson **20060812103835] [revert removal of ghcconfig.h from package.conf.in Ross Paterson **20060812082702 as it's preprocessed with -undef (pointed out by Esa Ilari Vuokko) ] [fix Data.HashTable for non-GHC Ross Paterson **20060811231521] [remove deprecated 'withObject' Simon Marlow **20060811152350] [Jan-Willem Maessen's improved implementation of Data.HashTable Simon Marlow **20060811151024 Rather than incrementally enlarging the hash table, this version just does it in one go when the table gets too full. ] [Warning police: Make some prototypes from the RTS known sven.panne@aedion.de**20060811144629] [Warning police: Removed useless catch-all clause sven.panne@aedion.de**20060811142208] [reduce dependency on ghcconfig.h Ross Paterson **20060811124030 The only remaining use is in cbits/dirUtils.h, which tests solaris2_HOST_OS (Also System.Info uses ghcplatform.h and several modules import MachDeps.h to get SIZEOF_* and ALIGNMENT_* from ghcautoconf.h) ] [(non-GHC only) track MArray interface change Ross Paterson **20060810182902] [move Text.Html to a separate package Simon Marlow **20060810113017] [bump version to 2.0 Simon Marlow **20060810112833] [Remove deprecated Data.FiniteMap and Data.Set interfaces Simon Marlow **20060809153810] [move altzone test from ghc to base package Ross Paterson **20060809124259] [remove unnecessary #include "ghcconfig.h" Ross Paterson **20060809123812] [Change the API of MArray to allow resizable arrays Simon Marlow **20060809100548 See #704 The MArray class doesn't currently allow a mutable array to change its size, because of the pure function bounds :: (HasBounds a, Ix i) => a i e -> (i,i) This patch removes the HasBounds class, and adds getBounds :: (MArray a e m, Ix i) => a i e -> m (i,i) to the MArray class, and bounds :: (IArray a e, Ix i) => a i e -> (i,i) to the IArray class. The reason that bounds had to be incorporated into the IArray class is because I couldn't make DiffArray work without doing this. DiffArray acts as a layer converting an MArray into an IArray, and there was no way (that I could find) to define an instance of HasBounds for DiffArray. ] [deprecate this module. Simon Marlow **20060808100708] [add traceShow (see #474) Simon Marlow **20060807155545] [remove spurious 'extern "C" {' Simon Marlow **20060724160258] [Fix unsafeIndex for large ranges Simon Marlow **20060721100225] [disambiguate uses of foldr for nhc98 to compile without errors Malcolm.Wallace@cs.york.ac.uk**20060711161614] [make Control.Monad.Instances compilable by nhc98 Malcolm.Wallace@cs.york.ac.uk**20060711160941] [breakpointCond Lemmih **20060708055528] [UNDO: Merge "unrecognized long opt" fix from 6.4.2 Simon Marlow **20060705142537 This patch undid the previous patch, "RequireOrder: do not collect unrecognised options after a non-opt". I asked Sven to revert it, but didn't get an answer. See bug #473. ] [Avoid strictness in accumulator for unpackFoldr Don Stewart **20060703091806 The seq on the accumulator for unpackFoldr will break in the presence of head/build rewrite rules. The empty list case will be forced, producing an exception. This is a known issue with seq and rewrite rules that we just stumbled on to. ] [Disable unpack/build fusion Don Stewart **20060702083913 unpack/build on bytestrings seems to trigger a bug when interacting with head/build fusion in GHC.List. The bytestring001 testcase catches it. I'll investigate further, but best to disable this for now (its not often used anyway). Note that with -frules-off or ghc 6.4.2 things are fine. It seems to have emerged with the recent rules changes. ] [Import Data.ByteString.Lazy, improve ByteString Fusion, and resync with FPS head Don Stewart **20060701084345 This patch imports the Data.ByteString.Lazy module, and its helpers, providing a ByteString implemented as a lazy list of strict cache-sized chunks. This type allows the usual lazy operations to be written on bytestrings, including lazy IO, with much improved space and time over the [Char] equivalents. ] [Wibble in docs for new ForeignPtr functionsn Don Stewart **20060609075924] [comments for Applicative and Traversable Ross Paterson **20060622170436] [default to NoBuffering on Windows for a read/write text file Simon Marlow **20060622144446 Fixes (works around) #679 ] [remove dead code Simon Marlow **20060622144433] [clarify and expand docs Simon Marlow **20060622112911] [Add minView and maxView to Map and Set jeanphilippe.bernardy@gmail.com**20060616180121] [add signature for registerDelay Ross Paterson **20060614114456] [a few doc comments Ross Paterson **20060613142704] [Optimised foreign pointer representation, for heap-allocated objects Don Stewart **20060608015011] [Add the inline function, and many comments simonpj@microsoft.com**20060605115814 This commit adds the 'inline' function described in the related patch in the compiler. I've also added comments about the 'lazy' function. ] [small intro to exceptions Ross Paterson **20060525111604] [export breakpoint Simon Marlow **20060525090456] [Merge in changes from fps head. Highlights: Don Stewart **20060525065012 Wed May 24 15:49:38 EST 2006 sjanssen@cse.unl.edu * instance Monoid ByteString Wed May 24 15:04:04 EST 2006 Duncan Coutts * Rearange export lists for the .Char8 modules Wed May 24 14:59:56 EST 2006 Duncan Coutts * Implement mapAccumL and reimplement mapIndexed using loopU Wed May 24 14:47:32 EST 2006 Duncan Coutts * Change the implementation of the unfoldr(N) functions. Use a more compact implementation for unfoldrN and change it's behaviour to only return Just in the case that it actually 'overflowed' the N, so the boundary case of unfolding exactly N gives Nothing. Implement unfoldr and Lazy.unfoldr in terms of unfoldrN. Use fibonacci growth for the chunk size in unfoldr Wed May 24 08:32:29 EST 2006 sjanssen@cse.unl.edu * Add unfoldr to ByteString and .Char8 A preliminary implementation of unfoldr. Wed May 24 01:39:41 EST 2006 Duncan Coutts * Reorder the export lists to better match the Data.List api Tue May 23 14:04:32 EST 2006 Don Stewart * pack{Byte,Char} -> singleton. As per fptools convention Tue May 23 14:00:51 EST 2006 Don Stewart * elemIndexLast -> elemIndexEnd Tue May 23 13:57:34 EST 2006 Don Stewart * In the search for a more orthogonal api, we kill breakFirst/breakLast, which were of dubious value Tue May 23 12:24:09 EST 2006 Don Stewart * Abolish elems. It's name implied it was unpack, but its type didn't. it made no sense Tue May 23 10:42:09 EST 2006 Duncan Coutts * Minor doc tidyup. Use haddock markup better. Tue May 23 11:00:31 EST 2006 Don Stewart * Simplify the join() implementation. Spotted by Duncan. ] [add a way to ask the IO manager thread to exit Simon Marlow **20060524121823] [Sync with FPS head, including the following patches: Don Stewart **20060520030436 Thu May 18 15:45:46 EST 2006 sjanssen@cse.unl.edu * Export unsafeTake and unsafeDrop Fri May 19 11:53:08 EST 2006 Don Stewart * Add foldl1' Fri May 19 13:41:24 EST 2006 Don Stewart * Add fuseable scanl, scanl1 + properties Fri May 19 18:20:40 EST 2006 Don Stewart * Spotted another chance to use unsafeTake,Drop (in groupBy) Thu May 18 09:24:25 EST 2006 Duncan Coutts * More effecient findIndexOrEnd based on the impl of findIndex Thu May 18 09:22:49 EST 2006 Duncan Coutts * Eliminate special case in findIndex since it's handled anyway. Thu May 18 09:19:08 EST 2006 Duncan Coutts * Add unsafeTake and unsafeDrop These versions assume the n is in the bounds of the bytestring, saving two comparison tests. Then use them in varous places where we think this holds. These cases need double checking (and there are a few remaining internal uses of take / drop that might be possible to convert). Not exported for the moment. Tue May 16 23:15:11 EST 2006 Don Stewart * Handle n < 0 in drop and splitAt. Spotted by QC. Tue May 16 22:46:22 EST 2006 Don Stewart * Handle n <= 0 cases for unfoldr and replicate. Spotted by QC Tue May 16 21:34:11 EST 2006 Don Stewart * mapF -> map', filterF -> filter' ] [haddock fix Ross Paterson **20060518154723] [simplify indexing in Data.Sequence Ross Paterson **20060518154316] [Move Eq, Ord, Show instances for ThreadId to GHC.Conc Simon Marlow **20060518113339 Eliminates orphans. ] [Better error handling in the IO manager thread Simon Marlow **20060518113303 In particular, handle EBADF just like rts/posix/Select.c, by waking up all the waiting threads. Other errors are thrown, instead of just being ignored. ] [#define _REENTRANT 1 (needed to get the right errno on some OSs) Simon Marlow **20060518104151 Part 2 of the fix for threaded RTS problems on Solaris and possibly *BSD (Part 1 was the same change in ghc/includes/Rts.h). ] [copyCString* should be in IO. Spotted by Tomasz Zielonka Don Stewart **20060518012154] [add import Prelude to get dependencies right for Data/Fixed.hs Duncan Coutts **20060517222044 Hopefully this fixes parallel builds. ] [Fix negative index handling in splitAt, replicate and unfoldrN. Move mapF, filterF -> map', filter' while we're here Don Stewart **20060517020150] [Use our own realloc. Thus reduction functions (like filter) allocate on the Haskell heap. Makes around 10% difference. Don Stewart **20060513051736] [Last two CInt fixes for 64 bit, and bracket writeFile while we're here Don Stewart **20060512050750] [Some small optimisations, generalise the type of unfold Don Stewart **20060510043309 Tue May 9 22:36:29 EST 2006 Duncan Coutts * Surely the error function should not be inlined. Tue May 9 22:35:53 EST 2006 Duncan Coutts * Reorder memory writes for better cache locality. Tue May 9 23:28:09 EST 2006 Duncan Coutts * Generalise the type of unfoldrN The type of unfoldrN was overly constrained: unfoldrN :: Int -> (Word8 -> Maybe (Word8, Word8)) -> Word8 -> ByteString if we compare that to unfoldr: unfoldr :: (b -> Maybe (a, b)) -> b -> [a] So we can generalise unfoldrN to this type: unfoldrN :: Int -> (a -> Maybe (Word8, a)) -> a -> ByteString and something similar for the .Char8 version. If people really do want to use it a lot with Word8/Char then perhaps we should add a specialise pragma. Wed May 10 13:26:40 EST 2006 Don Stewart * Add foldl', and thus a fusion rule for length . {map,filter,fold}, that avoids creating an array at all if the end of the pipeline is a 'length' reduction **END OF DESCRIPTION*** Place the long patch description above the ***END OF DESCRIPTION*** marker. The first line of this file will be the patch name. This patch contains the following changes: M ./Data/ByteString.hs -8 +38 M ./Data/ByteString/Char8.hs -6 +12 ] [portable implementation of WordPtr/IntPtr for non-GHC Ross Paterson **20060510001826 plus much tweaking of imports to avoid cycles ] [add WordPtr and IntPtr types to Foreign.Ptr, with associated conversions Simon Marlow **20060509092606 As suggested by John Meacham. I had to move the Show instance for Ptr into GHC.ForeignPtr to avoid recursive dependencies. ] [add CIntPtr, CUIntPtr, CIntMax, CUIntMax types Simon Marlow **20060509092427] [add GHC.Dynamic Simon Marlow **20060509082739] [Two things. #if defined(__GLASGOW_HASKELL__) on INLINE [n] pragmas (for jhc). And careful use of INLINE on words/unwords halves runtime for those functions Don Stewart **20060509023425] [Make length a good consumer simonpj@microsoft**20060508142726 Make length into a good consumer. Fixes Trac bug #707. (Before length simply didn't use foldr.) ] [Trim imports simonpj@microsoft**20060508142557] [Make unsafePerformIO lazy simonpj@microsoft**20060508142507 The stricteness analyser used to have a HACK which ensured that NOINLNE things were not strictness-analysed. The reason was unsafePerformIO. Left to itself, the strictness analyser would discover this strictness for unsafePerformIO: unsafePerformIO: C(U(AV)) But then consider this sub-expression unsafePerformIO (\s -> let r = f x in case writeIORef v r s of (# s1, _ #) -> (# s1, r #) The strictness analyser will now find that r is sure to be eval'd, and may then hoist it out. This makes tests/lib/should_run/memo002 deadlock. Solving this by making all NOINLINE things have no strictness info is overkill. In particular, it's overkill for runST, which is perfectly respectable. Consider f x = runST (return x) This should be strict in x. So the new plan is to define unsafePerformIO using the 'lazy' combinator: unsafePerformIO (IO m) = lazy (case m realWorld# of (# _, r #) -> r) Remember, 'lazy' is a wired-in identity-function Id, of type a->a, which is magically NON-STRICT, and is inlined after strictness analysis. So unsafePerformIO will look non-strict, and that's what we want. ] [Sync with FPS head. Don Stewart **20060508122322 Mon May 8 10:40:14 EST 2006 Don Stewart * Fix all uses for Int that should be CInt or CSize in ffi imports. Spotted by Igloo, dcoutts Mon May 8 16:09:41 EST 2006 Don Stewart * Import nicer loop/loop fusion rule from ghc-ndp Mon May 8 17:36:07 EST 2006 Don Stewart * Fix stack leak in split on > 60M strings Mon May 8 17:50:13 EST 2006 Don Stewart * Try same fix for stack overflow in elemIndices ] [Fix all uses for Int that should be CInt or CSize in ffi imports. Spotted by Duncan and Ian Don Stewart **20060508010311] [Fixed import list syntax Sven Panne **20060507155008] [Faster filterF, filterNotByte dons@cse.unsw.edu.au**20060507042301] [Much faster find, findIndex. Hint from sjanssen dons@cse.unsw.edu.au**20060507033048] [Merge "unrecognized long opt" fix from 6.4.2 Sven Panne **20060506110519] [ dons@cse.unsw.edu.au**20060506061029 Sat May 6 13:01:34 EST 2006 Don Stewart * Do loopU realloc on the Haskell heap. And add a really tough stress test Sat May 6 12:28:58 EST 2006 Don Stewart * Use simple, 3x faster concat. Plus QC properties. Suggested by sjanssen and dcoutts Sat May 6 15:59:31 EST 2006 Don Stewart * dcoutt's packByte bug squashed With inlinePerformIO, ghc head was compiling: packByte 255 `compare` packByte 127 into roughly case mallocByteString 2 of ForeignPtr f internals -> case writeWord8OffAddr# f 0 255 of _ -> case writeWord8OffAddr# f 0 127 of _ -> case eqAddr# f f of False -> case compare (GHC.Prim.plusAddr# f 0) (GHC.Prim.plusAddr# f 0) which is rather stunning. unsafePerformIO seems to prevent whatever magic inlining was leading to this. Only affected the head. ] [Add array fusion versions of map, filter and foldl dons@cse.unsw.edu.au**20060505060858 This patch adds fusable map, filter and foldl, using the array fusion code for unlifted, flat arrays, from the Data Parallel Haskell branch, after kind help from Roman Leshchinskiy, Pipelines of maps, filters and folds should now need to walk the bytestring once only, and intermediate bytestrings won't be constructed. ] [fix for non-GHC Ross Paterson **20060504093044] [use bracket in appendFile (like writeFile) Ross Paterson **20060504091528] [writeFile: close the file on error Simon Marlow **20060504084505 Suggested by Ross Paterson, via Neil Mitchell ] [Sync with FPS head dons@cse.unsw.edu.au**20060503105259 This patch brings Data.ByteString into sync with the FPS head. The most significant of which is the new Haskell counting sort. Changes: Sun Apr 30 18:16:29 EST 2006 sjanssen@cse.unl.edu * Fix foldr1 in Data.ByteString and Data.ByteString.Char8 Mon May 1 11:51:16 EST 2006 Don Stewart * Add group and groupBy. Suggested by conversation between sjanssen and petekaz on #haskell Mon May 1 16:42:04 EST 2006 sjanssen@cse.unl.edu * Fix groupBy to match Data.List.groupBy. Wed May 3 15:01:07 EST 2006 sjanssen@cse.unl.edu * Migrate to counting sort. Data.ByteString.sort used C's qsort(), which is O(n log n). The new algorithm is O(n), and is faster for strings larger than approximately thirty bytes. We also reduce our dependency on cbits! ] [improve performance of Integer->String conversion Simon Marlow **20060503113306 See http://www.haskell.org//pipermail/libraries/2006-April/005227.html Submitted by: bertram.felgenhauer@googlemail.com ] [inline withMVar, modifyMVar, modifyMVar_ Simon Marlow **20060503111152] [Fix string truncating in hGetLine -- it was a pasto from Simon's code Simon Marlow **20060503103504 (from Don Stewart) ] [Merge in Data.ByteString head. Fixes ByteString+cbits in hugs Don Stewart **20060429040733] [Import Data.ByteString from fps 0.5. Don Stewart **20060428130718 Fast, packed byte vectors, providing a better PackedString. ] [fix previous patch Ross Paterson **20060501154847] [fixes for non-GHC Ross Paterson **20060501144322] [fix imports for mingw32 && !GHC Ross Paterson **20060427163248] [RequireOrder: do not collect unrecognised options after a non-opt Simon Marlow **20060426121110 The documentation for RequireOrder says "no option processing after first non-option", so it doesn't seem right that we should process the rest of the arguments to collect the unrecognised ones. Presumably the client wants to know about the unrecognised options up to the first non-option, and will be using a different option parser for the rest of the command line. eg. before: Prelude System.Console.GetOpt> getOpt' RequireOrder [] ["bar","--foo"] ([],["bar","--foo"],["--foo"],[]) after: Prelude System.Console.GetOpt> getOpt' RequireOrder [] ["bar","--foo"] ([],["bar","--foo"],[],[]) ] [fix for Haddock 0.7 Ashley Yakeley **20060426072521] [add Data.Fixed module Ashley Yakeley **20060425071853] [add instances Ross Paterson **20060424102146] [add superclasses to Applicative and Traversable Ross Paterson **20060411144734 Functor is now a superclass of Applicative, and Functor and Foldable are now superclasses of Traversable. The new hierarchy makes clear the inclusions between the classes, but means more work in defining instances. Default definitions are provided to help. ] [add Functor and Monad instances for Prelude types Ross Paterson **20060410111443] [GHC.Base.breakpoint Lemmih **20060407125827] [Track the GHC source tree reorganisation Simon Marlow **20060407041631] [in the show instance for Exception, print the type of dynamic exceptions Simon Marlow **20060406112444 Unfortunately this requires some recursve module hackery to get at the show instance for Typeable. ] [implement ForeignEnvPtr, newForeignPtrEnv, addForeignPtrEnv for GHC Simon Marlow **20060405155448] [add forkOnIO :: Int -> IO () -> IO ThreadId Simon Marlow **20060327135018] [Rework previous: not a gcc bug after all Simon Marlow **20060323161229 It turns out that we were relying on behaviour that is undefined in C, and undefined behaviour in C means "the compiler can do whatever the hell it likes with your entire program". So avoid that. ] [work around a gcc 4.1.0 codegen bug in -O2 by forcing -O1 for GHC.Show Simon Marlow **20060323134514 See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26824 ] [commit mysteriously missing parts of "runIOFastExit" patch Simon Marlow **20060321101535] [add runIOFastExit :: IO a -> IO a Simon Marlow **20060320124333 Similar to runIO, but calls stg_exit() directly to exit, rather than shutdownHaskellAndExit(). Needed for running GHCi in the test suite. ] [Fix a broken invariant Simon Marlow **20060316134151 Patch from #694, for the problem "empty is an identity for <> and $$" is currently broken by eg. isEmpty (empty<>empty)" ] [Add unsafeSTToIO :: ST s a -> IO a Simon Marlow **20060315160232 Implementation for Hugs is missing, but should be easy. We need this for the forthcoming nested data parallelism implementation. ] [Added 'alter' jeanphilippe.bernardy@gmail.com**20060315143539 Added 'alter :: (Maybe a -> Maybe a) -> k -> Map k a -> Map k a' to IntMap and Map This addresses ticket #665 ] [deprecate FunctorM in favour of Foldable and Traversable Ross Paterson **20060315092942 as discussed on the libraries list. ] [Simplify Eq, Ord, and Show instances for UArray Simon Marlow **20060313142701 The Eq, Ord, and Show instances of UArray were written out longhand with one instance per element type. It is possible to condense these into a single instance for each class, at the expense of using more extensions (non-std context on instance declaration). Suggestion by: Frederik Eaton ] [Oops typo in intSet notMember jeanphilippe.bernardy@gmail.com**20060311224713] [IntMap lookup now returns monad instead of Maybe. jeanphilippe.bernardy@gmail.com**20060311224502] [Added notMember to Data.IntSet and Data.IntMap jeanphilippe.bernardy@gmail.com**20060311085221] [add Data.Set.notMember and Data.Map.notMember John Meacham **20060309191806] [addToClockTime: handle picoseconds properly Simon Marlow **20060310114532 fixes #588 ] [make head/build rule apply to all types, not just Bool. John Meacham **20060303045753] [Avoid overflow when normalising clock times Ian Lynagh **20060210144638] [Years have 365 days, not 30*365 Ian Lynagh **20060210142853] [declare blkcmp() static Simon Marlow **20060223134317] [typo in comment in Foldable class Ross Paterson **20060209004901] [simplify fmap Ross Paterson **20060206095048] [update ref in comment Ross Paterson **20060206095139] [Give -foverlapping-instances to Data.Typeable simonpj@microsoft**20060206133439 For some time, GHC has made -fallow-overlapping-instances "sticky": any instance in a module compiled with -fallow-overlapping-instances can overlap when imported, regardless of whether the importing module allows overlap. (If there is an overlap, both instances must come from modules thus compiled.) Instances in Data.Typeable might well want to be overlapped, so this commit adds the flag to Data.Typeable (with an explanatory comment) ] [Add -fno-bang-patterns to modules using both bang and glasgow-exts simonpj@microsoft.com**20060203175759] [When splitting a bucket, keep the contents in the same order Simon Marlow **20060201130427 To retain the property that multiple inserts shadow each other (see ticket #661, test hash001) ] [add foldr/build optimisation for take and replicate Simon Marlow **20060126164603 This allows take to be deforested, and improves performance of replicate and replicateM/replicateM_. We have a separate problem that means expressions involving [n..m] aren't being completely optimised because eftIntFB isn't being inlined but otherwise the results look good. Sadly this has invalidated a number of the nofib benchmarks which were erroneously using take to duplicate work in a misguided attempt to lengthen their runtimes (ToDo). ] [Generate PrimopWrappers.hs with Haddock docs Simon Marlow **20060124131121 Patch originally from Dinko Tenev , modified to add log message by me. ] [[project @ 2006-01-19 14:47:15 by ross] ross**20060119144715 backport warning avoidance from Haddock ] [[project @ 2006-01-18 11:45:47 by malcolm] malcolm**20060118114547 Fix import of Ix for nhc98. ] [[project @ 2006-01-17 09:38:38 by ross] ross**20060117093838 add Ix instance for GeneralCategory. ] [TAG Initial conversion from CVS complete John Goerzen **20060112154126] Patch bundle hash: dd94d37ff64288aaac10861c71a8ca67d59be72b From lemming at henning-thielemann.de Thu Feb 7 15:18:25 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Feb 7 15:17:19 2008 Subject: Proposal: Add Text.Read.maybeRead :: Read a => String -> Maybe a In-Reply-To: <20080207184648.GA19014@scytale.galois.com> References: <20080207184648.GA19014@scytale.galois.com> Message-ID: On Thu, 7 Feb 2008, Don Stewart wrote: > This function is typically defined once per project. So its > about time this safe variant of 'read' made it into the base. > > maybeRead :: Read a => String -> Maybe a > maybeRead s = case reads s of > [(x, "")] -> Just x > _ -> Nothing > > Consideration period: 1 week. > > Patch to Text.Read attached. Seems to be useful. May prevent people from using just 'read' while hoping that parsing will always succeed. From jeff.polakow at db.com Thu Feb 7 15:20:31 2008 From: jeff.polakow at db.com (Jeff Polakow) Date: Thu Feb 7 15:19:53 2008 Subject: Proposal: Add Text.Read.maybeRead :: Read a => String -> Maybe a In-Reply-To: <20080207184648.GA19014@scytale.galois.com> Message-ID: Hello, Why not allow an arbitrary monad? readM :: (Monad m, Read a) => String -> String -> m a readM errMsg s = case reads s of [(x, "")] -> return x _ -> fail errMsg -Jeff libraries-bounces@haskell.org wrote on 02/07/2008 01:46:48 PM: > This function is typically defined once per project. So its > about time this safe variant of 'read' made it into the base. > > maybeRead :: Read a => String -> Maybe a > maybeRead s = case reads s of > [(x, "")] -> Just x > _ -> Nothing > > Consideration period: 1 week. > > Patch to Text.Read attached. > > [attachment "maybeRead.patch" deleted by Jeff Polakow/db/dbcom] > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20080207/e3f76a5a/attachment.htm From iavor.diatchki at gmail.com Thu Feb 7 16:58:57 2008 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Thu Feb 7 16:57:52 2008 Subject: Proposal: Add Text.Read.maybeRead :: Read a => String -> Maybe a In-Reply-To: References: <20080207184648.GA19014@scytale.galois.com> Message-ID: <5ab17e790802071358p709b9116x307ef8611cefc892@mail.gmail.com> Hello, I don't think that the function should be in an arbitrary monad because not all monads support failure, and the purpose of using this function is to take an action when a parse error occurs (if parse errors were not an issue, then we could just use 'read' instead). If we really wanted to generalize the function, then we should use the 'MonadPlus' (or 'Alternative') classes to restrict the result to types that have meaningful "default" values. Having said this, I have used this function on many occasions, and the Maybe type has always been sufficient, so my preference would be to keep the original type that was proposed by Don. -Iavor 2008/2/7 Jeff Polakow : > > Hello, > > Why not allow an arbitrary monad? > > readM :: (Monad m, Read a) => String -> String -> m a > readM errMsg s = case reads s of > [(x, "")] -> return x > _ -> fail errMsg > > -Jeff > > > libraries-bounces@haskell.org wrote on 02/07/2008 01:46:48 PM: > > > > > This function is typically defined once per project. So its > > about time this safe variant of 'read' made it into the base. > > > > maybeRead :: Read a => String -> Maybe a > > maybeRead s = case reads s of > > [(x, "")] -> Just x > > _ -> Nothing > > > > Consideration period: 1 week. > > > > Patch to Text.Read attached. > > > > [attachment "maybeRead.patch" deleted by Jeff Polakow/db/dbcom] > > > _______________________________________________ > > Libraries mailing list > > Libraries@haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > > --- > > This e-mail may contain confidential and/or privileged information. If you > are not the intended recipient (or have received this e-mail in error) > please notify the sender immediately and destroy this e-mail. Any > unauthorized copying, disclosure or distribution of the material in this > e-mail is strictly forbidden. > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > From ndmitchell at gmail.com Thu Feb 7 17:42:34 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Feb 7 17:41:30 2008 Subject: Proposal: Add Text.Read.maybeRead :: Read a => String -> Maybe a In-Reply-To: <20080207184648.GA19014@scytale.galois.com> References: <20080207184648.GA19014@scytale.galois.com> Message-ID: <404396ef0802071442r3febd0c2g5e58e28bbf151fc9@mail.gmail.com> Hi > This function is typically defined once per project. So its > about time this safe variant of 'read' made it into the base. It's also in the Safe library as readMay: http://www-users.cs.york.ac.uk/~ndm/safe/ and has been useful. Not 100% certain that maybe read is the right name as opposed to readMaybe - given read/reads both have a read prefix. (+0.7) agreement. Thanks Neil From ross at soi.city.ac.uk Thu Feb 7 18:12:43 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Feb 7 18:11:37 2008 Subject: Proposal: Add Text.Read.maybeRead :: Read a => String -> Maybe a In-Reply-To: <20080207184648.GA19014@scytale.galois.com> References: <20080207184648.GA19014@scytale.galois.com> Message-ID: <20080207231243.GA3429@soi.city.ac.uk> On Thu, Feb 07, 2008 at 10:46:48AM -0800, Don Stewart wrote: > This function is typically defined once per project. So its > about time this safe variant of 'read' made it into the base. > > maybeRead :: Read a => String -> Maybe a > maybeRead s = case reads s of > [(x, "")] -> Just x > _ -> Nothing I think this is a good idea, though I normally write the equivalent of maybeRead :: Read a => String -> Maybe a maybeRead s = case reads s of [(x, rest)] | all isSpace rest -> Just x _ -> Nothing and would prefer not to generalize it to any monad. fail is a wart, not a design pattern. > Consideration period: 1 week. I think that's too short, and the recent fashion of 2 weeks is too short, even for an uncontroversial change. Some people aren't here continuously, but I'd still like to get their input. From ross at soi.city.ac.uk Thu Feb 7 18:50:15 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Feb 7 18:49:09 2008 Subject: ANNOUNCE: multiset 0.1 In-Reply-To: <47AB3DCC.8030308@gmail.com> References: <47AA6251.3020805@gmail.com> <200802071107.40781.g9ks157k@acme.softbase.org> <47AB3DCC.8030308@gmail.com> Message-ID: <20080207235015.GB3429@soi.city.ac.uk> On Thu, Feb 07, 2008 at 06:20:12PM +0100, Twan van Laarhoven wrote: > Wolfgang Jeltsch wrote: >> I think that actually your multiset/bag implementation should be a part >> of the containers package. So why not ask the maintainers of the >> containers package for permission to add your implementation and change >> the identifiers to Bag and IntBag during this process? This would be >> great. > > I initially wrote these modules as part of the containers package. > Unfortunatly the libraries process is awefully slow. And if you think > about it, there isn't a big advantage to having multiset in the > containers package. I decided to get the code out there quickly, so it > can be used right now. > > Perhaps the library could/should be merged into the containers package > somewhere in the future. These modules would fit quite nicely into the containers package (small "s" in Multiset, please). One can upgrade the containers package without waiting for the next GHC release, but containers is one of the packages most likely to cause problems if multiple versions are installed. ("Couldn't match expected type `containers-0.1.0.0::Data.Set.Set a' against inferred type `containers-0.1.1.0::Data.Set.Set a'") From john at repetae.net Thu Feb 7 22:48:35 2008 From: john at repetae.net (John Meacham) Date: Thu Feb 7 22:47:28 2008 Subject: Proposal: Add Text.Read.maybeRead :: Read a => String -> Maybe a In-Reply-To: <20080207184648.GA19014@scytale.galois.com> References: <20080207184648.GA19014@scytale.galois.com> Message-ID: <20080208034835.GB18950@sliver.repetae.net> On Thu, Feb 07, 2008 at 10:46:48AM -0800, Don Stewart wrote: > This function is typically defined once per project. So its > about time this safe variant of 'read' made it into the base. > > maybeRead :: Read a => String -> Maybe a > maybeRead s = case reads s of > [(x, "")] -> Just x > _ -> Nothing > > Consideration period: 1 week. May I suggest 'readM'? It is just the obvious generalization of the 'readIO' that is in the Prelude, that it isn't generalized is a bug in the prelude IMHO. (and it is signifigantly more useful) > readM :: (Monad m,Read a) => String -> m a > readM s = case reads s of > [(x, "")] -> return x > _ -> fail "readM: no parse" John -- John Meacham - ?repetae.net?john? From john at repetae.net Thu Feb 7 22:52:30 2008 From: john at repetae.net (John Meacham) Date: Thu Feb 7 22:51:21 2008 Subject: Proposal: Add Text.Read.maybeRead :: Read a => String -> Maybe a In-Reply-To: References: <20080207184648.GA19014@scytale.galois.com> Message-ID: <20080208035230.GC18950@sliver.repetae.net> On Thu, Feb 07, 2008 at 03:20:31PM -0500, Jeff Polakow wrote: > Why not allow an arbitrary monad? > > readM :: (Monad m, Read a) => String -> String -> m a > readM errMsg s = case reads s of > [(x, "")] -> return x > _ -> fail errMsg Yes. I strongly support this, this routine has been in my GenUtil for a long time as is hella useful. Though, I wouldn't give it an error message argument and just let it have something descriptive like "readM: no parse" as in my other reply. John -- John Meacham - ?repetae.net?john? From dave at zednenem.com Fri Feb 8 00:17:31 2008 From: dave at zednenem.com (David Menendez) Date: Fri Feb 8 00:16:23 2008 Subject: Proposal: Add Text.Read.maybeRead :: Read a => String -> Maybe a In-Reply-To: <20080207231243.GA3429@soi.city.ac.uk> References: <20080207184648.GA19014@scytale.galois.com> <20080207231243.GA3429@soi.city.ac.uk> Message-ID: <49a77b7a0802072117o335623i93dabb6035222855@mail.gmail.com> On Feb 7, 2008 6:12 PM, Ross Paterson wrote: > I think this is a good idea, though I normally write the equivalent of > > maybeRead :: Read a => String -> Maybe a > maybeRead s = case reads s of > [(x, rest)] | all isSpace rest -> Just x > _ -> Nothing > > and would prefer not to generalize it to any monad. fail is a wart, > not a design pattern. I also prefer Maybe to fail. Error strings are only useful if you're ignoring them or passing them to the user without interpretation. -- Dave Menendez From s.clover at gmail.com Fri Feb 8 00:56:11 2008 From: s.clover at gmail.com (Sterling Clover) Date: Fri Feb 8 00:55:07 2008 Subject: Proposal: Add Text.Read.maybeRead :: Read a => String -> Maybe a In-Reply-To: <20080208035230.GC18950@sliver.repetae.net> References: <20080207184648.GA19014@scytale.galois.com> <20080208035230.GC18950@sliver.repetae.net> Message-ID: readM for an arbitrary monad with a standard error message++. not necessarily because I believe this is the right or even the one true way to do this per se., but rather because this is how Data.Map etc. handle failure on lookups, etc. Given that read apparently trims trailing whitespace, I also approve of adding that to this function. My argument here is that uniform and expected behavior should be a stronger goal of libraries than the ugly rails notion of "configuration by convention." As such, generalizing to an arbitrary monad is more uniform and common than simply using a Maybe instance (and provides a strict superset of functionality to boot). Furthermore, I agree with the dislike of fail, and agree that it should be moved to MonadFail or MonadZero or such. However, I also think that even if this were to happen in a major revamp (Haskell' or whatever) that it would be more appropriate to have a generalized readM than not. in fact, as a whole, there's really no reason the libraries should err on the size of giving less generality rather than more. --Sterl. p.s. Actually, the fact that read doesn't act like readM by default strikes me as a bug, but not one that can reasonably be resolved with the libraries as they stand. As the general sentiment seems to go, total base libraries ftw. The more direct the path for haskell newcomers to come over the benefits of strong type-safety in all instances, the better. On Feb 7, 2008, at 10:52 PM, John Meacham wrote: > On Thu, Feb 07, 2008 at 03:20:31PM -0500, Jeff Polakow wrote: >> Why not allow an arbitrary monad? >> >> readM :: (Monad m, Read a) => String -> String -> m a >> readM errMsg s = case reads s of >> [(x, "")] -> return x >> _ -> fail errMsg > > Yes. I strongly support this, this routine has been in my GenUtil > for a > long time as is hella useful. Though, I wouldn't give it an error > message argument and just let it have something descriptive like > "readM: > no parse" as in my other reply. > > John > > > -- > John Meacham - ?repetae.net?john? > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries From dan.doel at gmail.com Fri Feb 8 01:48:50 2008 From: dan.doel at gmail.com (Dan Doel) Date: Fri Feb 8 01:46:57 2008 Subject: Proposal: Add Text.Read.maybeRead :: Read a => String -> Maybe a In-Reply-To: <20080207184648.GA19014@scytale.galois.com> References: <20080207184648.GA19014@scytale.galois.com> Message-ID: <200802080148.51207.dan.doel@gmail.com> On Thursday 07 February 2008, Don Stewart wrote: > This function is typically defined once per project. So its > about time this safe variant of 'read' made it into the base. > > maybeRead :: Read a => String -> Maybe a > maybeRead s = case reads s of > [(x, "")] -> Just x > _ -> Nothing > > Consideration period: 1 week. > > Patch to Text.Read attached. I was poking around the GHC sources, and it seems like you'd be closer to 'read' if you went with: maybeRead s = case reads s of [(x, s')] | all isSpace s' -> Just x _ -> Nothing I'd also, personally, vote in favor of readM. fail is a wart, but that's a problem with the Monad class, not with the idea of failing in an arbitrary, appropriate monad. In fact, if you use fail, you can also make a distinction between "no parse" and "ambiguous parse", as read does. In fact, GHC has an internal 'readEither' it uses to define 'read': readEither s = case [ x | (x,"") <- readPrec_to_S read' minPrec s ] of [x] -> Right x [] -> Left "Prelude.read: no parse" _ -> Left "Prelude.read: ambiguous parse" where read' = do x <- readPrec lift P.skipSpaces return x Using this auxiliary function, you have: read s = either error id (readEither s) maybeRead s = either (const Nothing) Just (readEither s) readIO s = either fail return (readEither s) -- [1] readM s = either fail return (readEither s) readM is the generalization of readIO, maybeRead, and even readEither, so one could simply define it instead of readEither, read in terms of readM, and export both (although I don't know how that'd gel with non-GHC compilers; the importing/exporting in base is somewhat convoluted :)). -- Dan 1: readIO apparently uses 'lex' instead of 'skipSpaces', which is the same if there are actually just spaces left, but does extra work if not. From lemming at henning-thielemann.de Fri Feb 8 02:59:55 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Feb 8 02:58:48 2008 Subject: Proposal: Add Text.Read.maybeRead :: Read a => String -> Maybe a In-Reply-To: <5ab17e790802071358p709b9116x307ef8611cefc892@mail.gmail.com> References: <20080207184648.GA19014@scytale.galois.com> <5ab17e790802071358p709b9116x307ef8611cefc892@mail.gmail.com> Message-ID: On Thu, 7 Feb 2008, Iavor Diatchki wrote: > Hello, > I don't think that the function should be in an arbitrary monad > because not all monads support failure, and the purpose of using this > function is to take an action when a parse error occurs I'm for the fixed Maybe type. I also think that 'maybeRead' is better than 'readMaybe' since the latter one suggests that it is about reading a value of type 'Maybe'. (Though you can also argue the opposite way.) From waldmann at imn.htwk-leipzig.de Fri Feb 8 03:05:44 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Fri Feb 8 03:04:37 2008 Subject: Proposal: Add Text.Read.maybeRead :: Read a => String -> Maybe a In-Reply-To: References: <20080207184648.GA19014@scytale.galois.com> <5ab17e790802071358p709b9116x307ef8611cefc892@mail.gmail.com> Message-ID: <47AC0D58.7020702@imn.htwk-leipzig.de> Hello. I like the functionality, but I generally don't like type information in a name. Isn't there a way to express this with the module system or the type system. Best regards, Johannes. From johan.tibell at gmail.com Fri Feb 8 04:15:07 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri Feb 8 04:14:00 2008 Subject: Proposal: Add Text.Read.maybeRead :: Read a => String -> Maybe a In-Reply-To: <47AC0D58.7020702@imn.htwk-leipzig.de> References: <20080207184648.GA19014@scytale.galois.com> <5ab17e790802071358p709b9116x307ef8611cefc892@mail.gmail.com> <47AC0D58.7020702@imn.htwk-leipzig.de> Message-ID: <90889fe70802080115g454a661bn31a049d0a383780a@mail.gmail.com> On Feb 8, 2008 9:05 AM, Johannes Waldmann wrote: > Hello. I like the functionality, > but I generally don't like type information in a name. > Isn't there a way to express this with the > module system or the type system. > Best regards, Johannes. I have to agree here. We should try to make more use of the module system and qualified imports. All this type information in function names is distracting. And no fail please. -- Johan From jules at jellybean.co.uk Fri Feb 8 04:51:34 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Fri Feb 8 04:50:26 2008 Subject: Proposal: Add Text.Read.maybeRead :: Read a => String -> Maybe a In-Reply-To: <200802080148.51207.dan.doel@gmail.com> References: <20080207184648.GA19014@scytale.galois.com> <200802080148.51207.dan.doel@gmail.com> Message-ID: <47AC2626.9050102@jellybean.co.uk> Dan Doel wrote: > readEither s = > case [ x | (x,"") <- readPrec_to_S read' minPrec s ] of > [x] -> Right x > [] -> Left "Prelude.read: no parse" > _ -> Left "Prelude.read: ambiguous parse" Because there are multiple error cases, I support the Monad version. I agree with everyone who has said that fail is a wart, but since we don't have a haskell98 'MonadStringError', and 'MonadError' requires fundeps and MPTCs, I think fail is the best we have at the moment. If we were prepared to endorse fundeps and MPTCs then I might support a (Error e, MonadError e m,Read a) => String -> m a type. If there was only one error case, then Maybe would contain enough information, and I would support the simpler version. As there are three (no parse, ambiguous parse, and incomplete parse), it is losing information just to product Nothing. +1 for Text.Read.readM from me. Dan points out in conversation that a MonadPlus constraint might be considered a 'valid hint' that fail is a sensible operation. Without wishing to derail the conversation, common combinators to promote and demote error types might be good thigns to document and possibly even include in the standard lib. One example which springs to mind is maybe (fail "it went wrong") return which the combinator to "promote" from unlabelled errors (Maybe) to labelled errors (presumably in an error monad). Or with a custom error type, something like maybe (throwError ThereWasAProblem) return which could be set up as an infix like this: possiblyFailingOperation `withError` ThereWasAProblem There are a whole bunch of tricks like this for embedding one error strategy inside another which are 'obvious' and even 'folklore' but not written down. Jules From john at repetae.net Fri Feb 8 04:56:27 2008 From: john at repetae.net (John Meacham) Date: Fri Feb 8 04:55:19 2008 Subject: Proposal: Add Text.Read.maybeRead :: Read a => String -> Maybe a In-Reply-To: <49a77b7a0802072117o335623i93dabb6035222855@mail.gmail.com> References: <20080207184648.GA19014@scytale.galois.com> <20080207231243.GA3429@soi.city.ac.uk> <49a77b7a0802072117o335623i93dabb6035222855@mail.gmail.com> Message-ID: <20080208095627.GD18950@sliver.repetae.net> On Fri, Feb 08, 2008 at 12:17:31AM -0500, David Menendez wrote: > On Feb 7, 2008 6:12 PM, Ross Paterson wrote: > > I think this is a good idea, though I normally write the equivalent of > > > > maybeRead :: Read a => String -> Maybe a > > maybeRead s = case reads s of > > [(x, rest)] | all isSpace rest -> Just x > > _ -> Nothing > > > > and would prefer not to generalize it to any monad. fail is a wart, > > not a design pattern. > > I also prefer Maybe to fail. Error strings are only useful if you're > ignoring them or passing them to the user without interpretation. say that next time you get a mysterious "fromJust: Nothing" error with no context, error messages in haskell are quite an issue as is, _any_ useful information is good, passing them on to the user without interpretation is loads better than not having any clue what went wrong. It is what you want to do because the fact that it was a 'readM' that failed is extremely useful for figuring out what went wrong. It is a straightforward generalization that is very useful pragmatically. John -- John Meacham - ?repetae.net?john? From gale at sefer.org Fri Feb 8 05:50:56 2008 From: gale at sefer.org (Yitzchak Gale) Date: Fri Feb 8 05:49:47 2008 Subject: Proposal: Add Text.Read.maybeRead :: Read a => String -> Maybe a In-Reply-To: <20080207231243.GA3429@soi.city.ac.uk> References: <20080207184648.GA19014@scytale.galois.com> <20080207231243.GA3429@soi.city.ac.uk> Message-ID: <2608b8a80802080250o293f701fxa5d86279e80a8071@mail.gmail.com> I vote mildly in favor of maybeRead, strongly against readM. "fail" refers only to failure of pattern matching. The wart is that its name should have been more specific, like "patternFail". Using "fail" for a non-pattern-matching error is a bug, not just a wart, in my opinion. My preferences for the type of this function, from best to worst, would be: 1. (Error e, MonadError e m, Read a) => String -> m a 2. (MonadZero m, Read a) => String -> m a 3. (MonanPlus m, Read a) => String -> m a 4. Read a => String -> Maybe a But (1) depends on mtl, and MonadZero is not even part of the libraries, so (2) is also out. That leaves (3) and (4) as the only possibilities. They're still useful sometimes. Thanks, Yitz From lemming at henning-thielemann.de Fri Feb 8 05:39:18 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Feb 8 06:52:19 2008 Subject: Proposal: Add Text.Read.maybeRead :: Read a => String -> Maybe a In-Reply-To: <20080208095627.GD18950@sliver.repetae.net> References: <20080207184648.GA19014@scytale.galois.com> <20080207231243.GA3429@soi.city.ac.uk> <49a77b7a0802072117o335623i93dabb6035222855@mail.gmail.com> <20080208095627.GD18950@sliver.repetae.net> Message-ID: On Fri, 8 Feb 2008, John Meacham wrote: > On Fri, Feb 08, 2008 at 12:17:31AM -0500, David Menendez wrote: > > > I also prefer Maybe to fail. Error strings are only useful if you're > > ignoring them or passing them to the user without interpretation. > > say that next time you get a mysterious "fromJust: Nothing" error with > no context, error messages in haskell are quite an issue as is, _any_ > useful information is good, passing them on to the user without > interpretation is loads better than not having any clue what went wrong. Since 'error' denotes a programming error, not an exception, there is no need that the user understands the error message. It is entirely the task of the programmer to understand the message or its absence and it would be completely ok if the program aborts with "the programmer made a mistake, please complain to him". http://www.haskell.org/haskellwiki/Error http://www.haskell.org/haskellwiki/Exception From wnoise at ofb.net Fri Feb 8 07:08:57 2008 From: wnoise at ofb.net (Aaron Denney) Date: Fri Feb 8 07:07:57 2008 Subject: Proposal: Add Text.Read.maybeRead :: Read a => String -> Maybe a References: <20080207184648.GA19014@scytale.galois.com> <20080207231243.GA3429@soi.city.ac.uk> <2608b8a80802080250o293f701fxa5d86279e80a8071@mail.gmail.com> Message-ID: On 2008-02-08, Yitzchak Gale wrote: > I vote mildly in favor of maybeRead, > strongly against readM. > > "fail" refers only to failure of pattern matching. > The wart is that its name should have been > more specific, like "patternFail". Using > "fail" for a non-pattern-matching error is a > bug, not just a wart, in my opinion. Even if you do consider it a bug, it's an extremely useful bug. I don't see the point in deprecating it until a truly usable alternative is actually in the standard. -- Aaron Denney -><- From john at repetae.net Fri Feb 8 07:12:43 2008 From: john at repetae.net (John Meacham) Date: Fri Feb 8 07:11:35 2008 Subject: Proposal: Add Text.Read.maybeRead :: Read a => String -> Maybe a In-Reply-To: References: <20080207184648.GA19014@scytale.galois.com> <20080207231243.GA3429@soi.city.ac.uk> <49a77b7a0802072117o335623i93dabb6035222855@mail.gmail.com> <20080208095627.GD18950@sliver.repetae.net> Message-ID: <20080208121242.GA26836@sliver.repetae.net> On Fri, Feb 08, 2008 at 11:39:18AM +0100, Henning Thielemann wrote: > > say that next time you get a mysterious "fromJust: Nothing" error with > > no context, error messages in haskell are quite an issue as is, _any_ > > useful information is good, passing them on to the user without > > interpretation is loads better than not having any clue what went wrong. > > Since 'error' denotes a programming error, not an exception, there is no > need that the user understands the error message. It is entirely the task > of the programmer to understand the message or its absence and it would > be completely ok if the program aborts with "the programmer made a > mistake, please complain to him". > http://www.haskell.org/haskellwiki/Error > http://www.haskell.org/haskellwiki/Exception I am not sure what distinction you are making between the user and the developer. I don't believe errors should be catchable at all and find the ability to catch 'error' rather unaethetic. But I do believe they should be absolutely as informative as possible in order to track down bugs and the string argument is invaluable for that. I am not saying that "users" will be happier seeing "readM: no parse" than "fromJust: Nothing" as they both indicate bugs in your code, but getting a bug report with the first is much more useful and more precise. Haskell is hard enough to debug as is, we should take help wherever we can get it. John -- John Meacham - ?repetae.net?john? From ross at soi.city.ac.uk Fri Feb 8 11:35:12 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Fri Feb 8 11:34:18 2008 Subject: Proposal: Add Text.Read.maybeRead :: Read a => String -> Maybe a In-Reply-To: <20080208095627.GD18950@sliver.repetae.net> References: <20080207184648.GA19014@scytale.galois.com> <20080207231243.GA3429@soi.city.ac.uk> <49a77b7a0802072117o335623i93dabb6035222855@mail.gmail.com> <20080208095627.GD18950@sliver.repetae.net> Message-ID: <20080208163512.GA11927@soi.city.ac.uk> On Fri, Feb 08, 2008 at 01:56:27AM -0800, John Meacham wrote: > On Fri, Feb 08, 2008 at 12:17:31AM -0500, David Menendez wrote: > > I also prefer Maybe to fail. Error strings are only useful if you're > > ignoring them or passing them to the user without interpretation. > > say that next time you get a mysterious "fromJust: Nothing" error with > no context, And that is why people recommend against using functions that throw errors, like fromJust. But in some monads (and which monad is involved isn't immediately obvious), readM would be another such function (as is read, of course). In contrast, the proposed maybeRead wraps up a solution to a common problem in a safe way, and requires the caller (who has more information about the context) to handle failed parses. From conor at strictlypositive.org Fri Feb 8 12:03:38 2008 From: conor at strictlypositive.org (Conor McBride) Date: Fri Feb 8 12:02:08 2008 Subject: Proposal: Add Text.Read.maybeRead :: Read a => String -> Maybe a In-Reply-To: References: Message-ID: <2F08B61C-2E15-4D95-921F-DCBC20A46E8F@strictlypositive.org> Hi Don: > > > This function is typically defined once per project. So its > > about time this safe variant of 'read' made it into the base. > > > > maybeRead :: Read a => String -> Maybe a > > maybeRead s = case reads s of > > [(x, "")] -> Just x > > _ -> Nothing > > Jeff: > Why not allow an arbitrary monad? > > readM :: (Monad m, Read a) => String -> String -> m a > readM errMsg s = case reads s of > [(x, "")] -> return x > _ -> fail errMsg My instinct here is to follow James McKinna's observation (which give rise to views in Epigram): you don't need to produce elements of an *arbitrary* whatever-it-is when you can produce elements of the *initial* whatever-it-is. It makes the construction a bit easier to implement, because you're working at a concrete type, but no harder to use. I'd suggest going with the Maybe version, but then add the relevant initiality principles for Maybe (if they're not already there). This thing mayA :: Alternative a => Maybe x -> a x mayA (Just x) = pure x mayA Nothing = empty is a useful little piece of glue, and it has a few friends which might also help, including, for the moment, mayM :: Monadplus m => Maybe x -> m x mayM (Just x) = return x mayM Nothing = mzero and (oh all right then) mayhem :: Monad m => Maybe x -> m x mayhem (Just x) = return x mayhem Nothing = fail "I told you so!" These things are common factors in quite a lot of unnecessarily abstract operations. I suggest factoring out the final appeals to initiality, keeping the actual machinery simple and specific. All the best Conor From dons at galois.com Fri Feb 8 12:11:20 2008 From: dons at galois.com (Don Stewart) Date: Fri Feb 8 12:10:19 2008 Subject: Proposal: Add Text.Read.maybeRead :: Read a => String -> Maybe a In-Reply-To: <20080208163512.GA11927@soi.city.ac.uk> References: <20080207184648.GA19014@scytale.galois.com> <20080207231243.GA3429@soi.city.ac.uk> <49a77b7a0802072117o335623i93dabb6035222855@mail.gmail.com> <20080208095627.GD18950@sliver.repetae.net> <20080208163512.GA11927@soi.city.ac.uk> Message-ID: <20080208171120.GA27582@scytale.galois.com> ross: > On Fri, Feb 08, 2008 at 01:56:27AM -0800, John Meacham wrote: > > On Fri, Feb 08, 2008 at 12:17:31AM -0500, David Menendez wrote: > > > I also prefer Maybe to fail. Error strings are only useful if you're > > > ignoring them or passing them to the user without interpretation. > > > > say that next time you get a mysterious "fromJust: Nothing" error with > > no context, > > And that is why people recommend against using functions that throw > errors, like fromJust. But in some monads (and which monad is involved > isn't immediately obvious), readM would be another such function (as is > read, of course). > > In contrast, the proposed maybeRead wraps up a solution to a common > problem in a safe way, and requires the caller (who has more information > about the context) to handle failed parses. Quite so. The whole point of this exercise was to get a version of read that was safe, and where an unintential <- or other slip up wouldn't bring down the system. readM with fail defaults to ioError for almost all Monads, and so admits many dangerous programs, which is against the intent of the proposal in the first place. It seems with Conor's suggestion of a maybeReturn :: MonadPlus m => Maybe a -> m a maybeReturn = maybe mzero return we can still have the by-default-safe maybeRead, that doesn't admit exception throwing opportunities. -- Don From jeff.polakow at db.com Fri Feb 8 13:24:30 2008 From: jeff.polakow at db.com (Jeff Polakow) Date: Fri Feb 8 13:23:42 2008 Subject: Proposal: Add Text.Read.maybeRead :: Read a => String -> Maybe a In-Reply-To: <20080208171120.GA27582@scytale.galois.com> Message-ID: Hello, > readM with fail defaults to ioError for almost all Monads, and so admits > many dangerous programs, which is against the intent of the proposal > in the first place. > ioError is only in the IO monad and is catchable. I think the problem is when fail defaults to error which can be anywhere and is not catchable. > It seems with Conor's suggestion of a > > maybeReturn :: MonadPlus m => Maybe a -> m a > maybeReturn = maybe mzero return > > we can still have the by-default-safe maybeRead, that doesn't admit > exception throwing opportunities. > Isn't the MonadPlus approach also by-default-safe? -Jeff --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20080208/47cc6c59/attachment.htm From dave at zednenem.com Fri Feb 8 15:14:04 2008 From: dave at zednenem.com (David Menendez) Date: Fri Feb 8 15:12:55 2008 Subject: Proposal: Add Text.Read.maybeRead :: Read a => String -> Maybe a In-Reply-To: <20080208095627.GD18950@sliver.repetae.net> References: <20080207184648.GA19014@scytale.galois.com> <20080207231243.GA3429@soi.city.ac.uk> <49a77b7a0802072117o335623i93dabb6035222855@mail.gmail.com> <20080208095627.GD18950@sliver.repetae.net> Message-ID: <49a77b7a0802081214g6d4b0edwb2d5c195f709b0d2@mail.gmail.com> On Feb 8, 2008 4:56 AM, John Meacham wrote: > On Fri, Feb 08, 2008 at 12:17:31AM -0500, David Menendez wrote: > > On Feb 7, 2008 6:12 PM, Ross Paterson wrote: > > > I think this is a good idea, though I normally write the equivalent of > > > > > > maybeRead :: Read a => String -> Maybe a > > > maybeRead s = case reads s of > > > [(x, rest)] | all isSpace rest -> Just x > > > _ -> Nothing > > > > > > and would prefer not to generalize it to any monad. fail is a wart, > > > not a design pattern. > > > > I also prefer Maybe to fail. Error strings are only useful if you're > > ignoring them or passing them to the user without interpretation. > > say that next time you get a mysterious "fromJust: Nothing" error with > no context, error messages in haskell are quite an issue as is, _any_ > useful information is good, passing them on to the user without > interpretation is loads better than not having any clue what went wrong. That's why I use "fromMaybe" (or "maybe"). Why narrow it down to a call to some function when you can narrow it down to a specific call to a function? It's a pity there isn't something like __LINE__ in Haskell itself. > It is what you want to do because the fact that it was a 'readM' that > failed is extremely useful for figuring out what went wrong. It is a > straightforward generalization that is very useful pragmatically. We already have a function that produces an opaque error string to pass to the user: read. -- Dave Menendez From dave at zednenem.com Fri Feb 8 15:26:05 2008 From: dave at zednenem.com (David Menendez) Date: Fri Feb 8 15:24:56 2008 Subject: Proposal: Add Text.Read.maybeRead :: Read a => String -> Maybe a In-Reply-To: References: <20080208171120.GA27582@scytale.galois.com> Message-ID: <49a77b7a0802081226vdec9db5jc21ef24fff7a5804@mail.gmail.com> 2008/2/8 Jeff Polakow : Don Stewart: > > readM with fail defaults to ioError for almost all Monads, and so admits > > many dangerous programs, which is against the intent of the proposal > > in the first place. > > > ioError is only in the IO monad and is catchable. I think the problem is > when fail defaults to error which can be anywhere and is not catchable. I think Don meant "error". The default definition of fail in the Monad class is "error". > > It seems with Conor's suggestion of a > > > > maybeReturn :: MonadPlus m => Maybe a -> m a > > maybeReturn = maybe mzero return > > > > we can still have the by-default-safe maybeRead, that doesn't admit > > exception throwing opportunities. > > > Isn't the MonadPlus approach also by-default-safe? Safe, yes, but is it more useful? (I'm tempted to argue that the way MTL conflates mzero/mplus with throwError/catchError is unfortunate, but that's another discussion.) -- Dave Menendez From twanvl at gmail.com Fri Feb 8 15:35:34 2008 From: twanvl at gmail.com (Twan van Laarhoven) Date: Fri Feb 8 15:34:27 2008 Subject: Proposal: Add Text.Read.maybeRead :: Read a => String -> Maybe a In-Reply-To: <49a77b7a0802081226vdec9db5jc21ef24fff7a5804@mail.gmail.com> References: <20080208171120.GA27582@scytale.galois.com> <49a77b7a0802081226vdec9db5jc21ef24fff7a5804@mail.gmail.com> Message-ID: <47ACBD16.9010408@gmail.com> David Menendez wrote: >>Isn't the MonadPlus approach also by-default-safe? > > Safe, yes, but is it more useful? Yes. In this case, take a parsing monad for example. You could write: parseInt :: CharParser () Int parseInt = do ds <- many digit readM ds And it would work automatically. A reading error would be propagated to the parser monad, and it would backtrack/report the error/whatever. Twan From lemming at henning-thielemann.de Fri Feb 8 08:20:22 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat Feb 9 19:05:06 2008 Subject: Proposal: Add Text.Read.maybeRead :: Read a => String -> Maybe a In-Reply-To: References: <20080207184648.GA19014@scytale.galois.com> <20080207231243.GA3429@soi.city.ac.uk> <2608b8a80802080250o293f701fxa5d86279e80a8071@mail.gmail.com> Message-ID: On Fri, 8 Feb 2008, Aaron Denney wrote: > On 2008-02-08, Yitzchak Gale wrote: > > I vote mildly in favor of maybeRead, > > strongly against readM. > > > > "fail" refers only to failure of pattern matching. > > The wart is that its name should have been > > more specific, like "patternFail". Using > > "fail" for a non-pattern-matching error is a > > bug, not just a wart, in my opinion. > > Even if you do consider it a bug, it's an extremely useful bug. > I don't see the point in deprecating it until a truly usable alternative > is actually in the standard. If an alternative is added to the standard libraries, readM would have to remain. I think the generalization is not useful enough to introduce the monad version that we will regret later. readM can be added with the right type, when the alternative appears. Until then maybeRead is fine. From s.clover at gmail.com Sat Feb 9 19:23:56 2008 From: s.clover at gmail.com (Sterling Clover) Date: Sat Feb 9 19:22:46 2008 Subject: Proposal: Add Text.Read.maybeRead :: Read a => String -> Maybe a In-Reply-To: References: <20080207184648.GA19014@scytale.galois.com> <20080207231243.GA3429@soi.city.ac.uk> <2608b8a80802080250o293f701fxa5d86279e80a8071@mail.gmail.com> Message-ID: This discussion has pretty much convinced me as well that readM would be a mistake at this point. As to whether maybeRead trims trailing whitespace though...? --S On Feb 8, 2008, at 8:20 AM, Henning Thielemann wrote: > > On Fri, 8 Feb 2008, Aaron Denney wrote: > >> On 2008-02-08, Yitzchak Gale wrote: >>> I vote mildly in favor of maybeRead, >>> strongly against readM. >>> >>> "fail" refers only to failure of pattern matching. >>> The wart is that its name should have been >>> more specific, like "patternFail". Using >>> "fail" for a non-pattern-matching error is a >>> bug, not just a wart, in my opinion. >> >> Even if you do consider it a bug, it's an extremely useful bug. >> I don't see the point in deprecating it until a truly usable >> alternative >> is actually in the standard. > > If an alternative is added to the standard libraries, readM would > have to > remain. I think the generalization is not useful enough to > introduce the > monad version that we will regret later. readM can be added with > the right > type, when the alternative appears. Until then maybeRead is fine. > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries From david.waern at gmail.com Sun Feb 10 09:07:26 2008 From: david.waern at gmail.com (David Waern) Date: Sun Feb 10 09:06:11 2008 Subject: [Haskell] ANNOUNCE: Haddock version 2.0.0.0 In-Reply-To: <20080123151212.GA5232@soi.city.ac.uk> References: <20080123151212.GA5232@soi.city.ac.uk> Message-ID: 2008/1/23, Ross Paterson : > Also, the new haddock rejects some modules the old one accepted. > For example, it doesn't like extra doc comments that aren't attached > to anything. It also rejects > > data Pair = Pair {-# UNPACK #-} !Int -- ^ first field > {-# UNPACK #-} !Int -- ^ second field I just took a look a this last issue. It is not a bug, Haddock has never supported doc comments that are attached to the arguments of a non-record constructor. David From david.waern at gmail.com Sun Feb 10 11:55:32 2008 From: david.waern at gmail.com (David Waern) Date: Sun Feb 10 11:54:18 2008 Subject: [Haskell] ANNOUNCE: Haddock version 2.0.0.0 In-Reply-To: <47AF2576.6070204@serpentine.com> References: <20080123151212.GA5232@soi.city.ac.uk> <47AF2576.6070204@serpentine.com> Message-ID: 2008/2/10, Bryan O'Sullivan : > David Waern wrote: > >> It also rejects > >> > >> data Pair = Pair {-# UNPACK #-} !Int -- ^ first field > >> {-# UNPACK #-} !Int -- ^ second field > > > > I just took a look a this last issue. It is not a bug, > > Perhaps you mean "not a regression" :-) > > References: <20080123151212.GA5232@soi.city.ac.uk> <20080123172640.GB5232@soi.city.ac.uk> Message-ID: 2008/1/23, David Waern : > 2008/1/23, Ross Paterson : > > On Wed, Jan 23, 2008 at 05:57:18PM +0100, David Waern wrote: > > > 2008/1/23, Ross Paterson : > > > > If I add the new-style attributes to the base package, it hides those > > > > modules in the documentation for base, but packages that depend on base > > > > seem to generate links to locations in those hidden modules, e.g. uses > > > > of IO point at GHC.IOBase.IO. > > > > > > That's definitely a bug, I'm adding it to the TODO file. > > > > That one is a show-stopper for HackageDB. > > Right, we have to prioritize this one. I've now fixed this issue - a patch is available in the darcs repository. > > > > Also, the new haddock rejects some modules the old one accepted. > > > > For example, it doesn't like extra doc comments that aren't attached > > > > to anything. > > > > > > Hmm, it is possible that the parser has (accidentally) become a bit stricter. > > > > Some examples of things people do that were harmless before: > > > > -- | module header > > > > -- | extra comment describing module > > module MyModule where > > > > import Stuff -- ^ we might use this > > > > type MyInt = Int -- ^ comment I've tried these examples with Haddock 0.9 and it only accepts the last one. That's a regression in Haddock 2. But the other examples don't seem to be regressions. David From lennart at augustsson.net Sun Feb 10 18:33:16 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Sun Feb 10 18:31:59 2008 Subject: Proposal: Add Text.Read.maybeRead :: Read a => String -> Maybe a In-Reply-To: References: <20080207184648.GA19014@scytale.galois.com> Message-ID: Because the fail method is an abomination that should never have been included in the Monad class. 2008/2/7 Jeff Polakow : > > Hello, > > Why not allow an arbitrary monad? > > readM :: (Monad m, Read a) => String -> String -> m a > readM errMsg s = case reads s of > [(x, "")] -> return x > _ -> fail errMsg > > -Jeff > > > libraries-bounces@haskell.org wrote on 02/07/2008 01:46:48 PM: > > > > This function is typically defined once per project. So its > > about time this safe variant of 'read' made it into the base. > > > > maybeRead :: Read a => String -> Maybe a > > maybeRead s = case reads s of > > [(x, "")] -> Just x > > _ -> Nothing > > > > Consideration period: 1 week. > > > > Patch to Text.Read attached. > > > > [attachment "maybeRead.patch" deleted by Jeff Polakow/db/dbcom] > > _______________________________________________ > > Libraries mailing list > > Libraries@haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > > --- > > This e-mail may contain confidential and/or privileged information. If you > > are not the intended recipient (or have received this e-mail in error) > please notify the sender immediately and destroy this e-mail. Any > unauthorized copying, disclosure or distribution of the material in this > e-mail is strictly forbidden. > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20080210/39f9ed5f/attachment.htm From ross at soi.city.ac.uk Mon Feb 11 05:06:42 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Mon Feb 11 05:05:29 2008 Subject: Data.Ord and Heaps In-Reply-To: <47A7005C.8030404@tu-bs.de> References: <288B9431-ADC3-46D3-97F4-6A219388E015@quantentunnel.de> <47A7005C.8030404@tu-bs.de> Message-ID: <20080211100642.GA24057@soi.city.ac.uk> [redirecting to libraries] On Mon, Feb 04, 2008 at 01:09:00PM +0100, Stephan Friedrichs wrote: > apfelmus@quantentunnel.de wrote: >> [newtype Ord a => Reverse a = Reverse { unReverse :: a }] >> >> Yes. I mean "non-standard" in the software-reuse sense, i.e. Ord is for >> user-defined orderings and should be the only such mechanism in order >> to enable reuse. In fact, Data.Heap clearly shows that Data.Ord is >> currently missing functionality. > > Ah, now I see. The entire ordering policy mechanism - no matter how it > is going to be solved - belongs into Data.Ord and not in Data.Heap. As > soon as Data.Ord provides a solution, I'll use it in Data.Heap. Unfortunately the Data.Ord module is constrained to use only Haskell 98 features, because it is used by all implementations. So it could include the above Reverse (also mentioned in the group-by HW paper), but not the various OrdPolicy proposals. They could go in a separate module, though. Off on a tangent: the containers package, which collects portable implementations of general purpose data structures, could use a good priority queue implementation. However it is also constrained to use only Haskell 98 features, which would rule out using policies. Also, using weight-biased leftist trees (Cho & Sahni, 1996) instead of Knuth's rank-biased leftist trees would offer O(1) size for free. And they come out slightly faster in my test runs. From lemming at henning-thielemann.de Wed Feb 13 01:45:27 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Feb 13 01:44:04 2008 Subject: Pretty class as alternative for Show class Message-ID: There seems to be the need for (at least) two classes for showing values in Haskell: One class that outputs values in a way that can be copied and pasted into Haskell programs. This is useful in GHCi. Another class (say Pretty) that shows values in a prettily formatted way. Current libraries use the Show class for both applications depending on the taste of the author. A third class would be useful for outputting values with markup, say HTML or LaTeX. The Show class converts to String, the Pretty class could convert to a pretty printer data type like Doc. The Show class should output all data that is necessary to reconstruct the value, but not necessarily in the form of the underlying data structure, but maybe using appropriate generating functions. Thus e.g. 'show' for Doubles does not need a parameter for precision, it just emits all available digits. On the other hand a Pretty class should have such parameters (maybe then requiring a multi-parameter type class with functional dependency from value type to formatting style type). A nice infix operator like (//) like in the GSL wrapper could flatten the Pretty data to String, and thus is easy to use in GHCi. Matrix> fiboMatrix matrix [[1,0], [1,1]] Matrix> fiboMatrix // 3 /1.000 0.000\ \1.000 1.000/ where (//) :: Pretty style value => value -> style -> IO String x // p = putStr (Doc.toString (Pretty.toDoc p x)) class Pretty style value | value -> style where toDoc :: style -> value -> Doc If such a separation would become consensus then libraries could better separate the concerns of pretty output and re-usable output. From waldmann at imn.htwk-leipzig.de Wed Feb 13 02:42:48 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Wed Feb 13 02:41:25 2008 Subject: Pretty class as alternative for Show class In-Reply-To: References: Message-ID: <47B29F78.8050609@imn.htwk-leipzig.de> Henning Thielemann wrote: > The Show class converts to String, the Pretty class could convert to a > pretty printer data type like Doc. [...] Ah yes, I use this since a long time class ToDoc a where toDoc :: a -> Doc toDoc = toDocPrec 0 -- useful? toDocPrec :: Int -> a -> Doc http://141.57.11.163/cgi-bin/cvsweb/lib/Autolib/ToDoc/ I generally make even this output re-readable, and I'm reading is via Parsec: class Reader a where readerPrec :: Int -> Parser a http://141.57.11.163/cgi-bin/cvsweb/lib/Autolib/Reader/ and I also have the obvious DrIFT rules that can generate standard instances for most types. http://141.57.11.163/cgi-bin/cvsweb/drift/src/UserRuleToDoc.hs?rev=1.7 http://141.57.11.163/cgi-bin/cvsweb/drift/src/UserRuleReader.hs?rev=1.6 I will happily contribute this code to whatever Pretty class emerges. (Well, it's free, so I'd have no way to not contribute it ...) best regards, Johannes. From johan.tibell at gmail.com Wed Feb 13 02:43:07 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed Feb 13 02:41:45 2008 Subject: Pretty class as alternative for Show class In-Reply-To: References: Message-ID: <90889fe70802122343s535fa620g5555e72b7210c2d5@mail.gmail.com> On Feb 13, 2008 7:45 AM, Henning Thielemann wrote: > > There seems to be the need for (at least) two classes for showing values > in Haskell: One class that outputs values in a way that can be copied and > pasted into Haskell programs. This is useful in GHCi. Another class (say > Pretty) that shows values in a prettily formatted way. Current libraries > use the Show class for both applications depending on the taste of the > author. A third class would be useful for outputting values with markup, > say HTML or LaTeX. I've started to do this for my own code now. I use Show as an equivalent of Python's 'repr' and pretty for displaying things to users. -- Johan From john at repetae.net Wed Feb 13 03:01:35 2008 From: john at repetae.net (John Meacham) Date: Wed Feb 13 03:00:11 2008 Subject: Pretty class as alternative for Show class In-Reply-To: References: Message-ID: <20080213080135.GA9671@sliver.repetae.net> See my 'Doc' project. which includes both a show alternative class like you describe as well as a class abstracting different pretty printers. http://repetae.net/repos/Doc I use it in quite a few of my projects and it has served me well. John -- John Meacham - ?repetae.net?john? From lemming at henning-thielemann.de Wed Feb 13 07:27:32 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Feb 13 07:26:34 2008 Subject: Labelled graphs in fgl In-Reply-To: <6FFC9311-57E7-475F-A3EE-194F31A2A74D@eecs.oregonstate.edu> References: <6FFC9311-57E7-475F-A3EE-194F31A2A74D@eecs.oregonstate.edu> Message-ID: Is there a reason why graphs in fgl are labeled by default, and unlabelled graphs must be constructed by labeling with () ? In my opinion the more natural design would be to number the nodes and edges with an Enum type instead of Int and to retrieve the labels from an array. This would support the "from simple to complex" design. From ross at soi.city.ac.uk Wed Feb 13 08:05:14 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Feb 13 08:04:10 2008 Subject: [Haskell] ANNOUNCE: Haddock version 2.0.0.0 In-Reply-To: References: <20080123151212.GA5232@soi.city.ac.uk> <20080123172640.GB5232@soi.city.ac.uk> Message-ID: <20080213130514.GA9961@soi.city.ac.uk> On Sun, Feb 10, 2008 at 10:35:28PM +0100, David Waern wrote: > 2008/1/23, David Waern : > > > > 2008/1/23, Ross Paterson : > > > > > If I add the new-style attributes to the base package, it hides those > > > > > modules in the documentation for base, but packages that depend on base > > > > > seem to generate links to locations in those hidden modules, e.g. uses > > > > > of IO point at GHC.IOBase.IO. > > I've now fixed this issue - a patch is available in the darcs repository. OK, that seems to be fine now. If you build the libraries in ghc-6.8.2 (with the added OPTIONS_HADDOCK pragmas) with haddock-2.1, Data-Array.html is almost empty. The old Haddock had problems with re-exports from another package: * re-exported functions/types/classes were just shown as hyperlinked names without docs (the docs aren't stored in the interface file) * re-exported modules weren't shown at all (no reason that I can think of). However the new haddock doesn't even show the re-exported names. From lemming at henning-thielemann.de Wed Feb 13 08:15:10 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Feb 13 08:13:45 2008 Subject: Pretty class as alternative for Show class In-Reply-To: <20080213080135.GA9671@sliver.repetae.net> References: <20080213080135.GA9671@sliver.repetae.net> Message-ID: On Wed, 13 Feb 2008, John Meacham wrote: > See my 'Doc' project. which includes both a show alternative class like > you describe as > well as a class abstracting different pretty printers. > > http://repetae.net/repos/Doc > > I use it in quite a few of my projects and it has served me well. It seems like it was a good idea for me to ask. - What about uploading all three packages to Hackage (Johannes Waldmann's, Johan Tibell's and John Meacham's - the package idea seems to be related to the first name :-) and propose them as addition to the standard Show class? It would help people to convince no to abuse the Show class for pretty printing. From david.waern at gmail.com Wed Feb 13 08:20:00 2008 From: david.waern at gmail.com (David Waern) Date: Wed Feb 13 08:18:39 2008 Subject: [Haskell] ANNOUNCE: Haddock version 2.0.0.0 In-Reply-To: <20080213130514.GA9961@soi.city.ac.uk> References: <20080123151212.GA5232@soi.city.ac.uk> <20080123172640.GB5232@soi.city.ac.uk> <20080213130514.GA9961@soi.city.ac.uk> Message-ID: 2008/2/13, Ross Paterson : > > On Sun, Feb 10, 2008 at 10:35:28PM +0100, David Waern wrote: > > 2008/1/23, David Waern : > > > > > 2008/1/23, Ross Paterson : > > > > > > If I add the new-style attributes to the base package, it hides > those > > > > > > modules in the documentation for base, but packages that depend > on base > > > > > > seem to generate links to locations in those hidden modules, e.g. > uses > > > > > > of IO point at GHC.IOBase.IO. > > > > I've now fixed this issue - a patch is available in the darcs > repository. > > OK, that seems to be fine now. > > If you build the libraries in ghc-6.8.2 (with the added OPTIONS_HADDOCK > pragmas) with haddock-2.1, Data-Array.html is almost empty. The > old Haddock had problems with re-exports from another package: > > * re-exported functions/types/classes were just shown as hyperlinked > names without docs (the docs aren't stored in the interface file) > * re-exported modules weren't shown at all (no reason that I can think > of). > > However the new haddock doesn't even show the re-exported names. > Oh, interesting. We should be able show the docs for re-exports, since the new Haddock do store them in the interface files. Thanks for the report, David -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20080213/bca4e856/attachment.htm From ross at soi.city.ac.uk Wed Feb 13 08:38:35 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Feb 13 08:37:21 2008 Subject: [Haskell] ANNOUNCE: Haddock version 2.0.0.0 In-Reply-To: References: <20080123151212.GA5232@soi.city.ac.uk> <20080123172640.GB5232@soi.city.ac.uk> <20080213130514.GA9961@soi.city.ac.uk> Message-ID: <20080213133834.GB9961@soi.city.ac.uk> On Wed, Feb 13, 2008 at 02:20:00PM +0100, David Waern wrote: > Oh, interesting. We should be able show the docs for re-exports, since > the new Haddock do store them in the interface files. That's wonderful news. cf the complaint about Data.Array on haskell-cafe: the functions have fine documentation, but it's all in the base package and so isn't being shown. From Christian.Maeder at dfki.de Wed Feb 13 09:01:21 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Feb 13 08:59:58 2008 Subject: Pretty class as alternative for Show class In-Reply-To: <20080213080135.GA9671@sliver.repetae.net> References: <20080213080135.GA9671@sliver.repetae.net> Message-ID: <47B2F831.707@dfki.de> John Meacham wrote: > See my 'Doc' project. which includes both a show alternative class like > you describe as > well as a class abstracting different pretty printers. > > http://repetae.net/repos/Doc Why should I use your DocLike module (instead of Text.PrettyPrint.HughesPJ directly)? from module DocLike: x <+> y = x <> char ' ' <> y x <$> y = x <> char '\n' <> y encloseSep l r s ds = enclose l r (hcat $ punctuate s ds) enclose l r x = l <> x <> r list = encloseSep lbracket rbracket comma tupled = encloseSep lparen rparen comma semiBraces = encloseSep lbrace rbrace semi 1. The indentation is wrong for Doc from your module Pretty (and strings): *Pretty> text "a" DocLike.<+> (text "b" DocLike.<$> text "c") :: Doc a b c 2. encloseSep may produce too long lines without breaks The HughesPJ output is correct: *DocLike> P.text "a" <+> (P.text "b" <$> P.text "c") a b c Cheers Christian From johan.tibell at gmail.com Wed Feb 13 10:47:55 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed Feb 13 10:46:32 2008 Subject: Pretty class as alternative for Show class In-Reply-To: References: <20080213080135.GA9671@sliver.repetae.net> Message-ID: <90889fe70802130747t7946257bj72859cd3b50c9e3b@mail.gmail.com> On Feb 13, 2008 2:15 PM, Henning Thielemann wrote: > It seems like it was a good idea for me to ask. - What about uploading > all three packages to Hackage (Johannes Waldmann's, Johan Tibell's and > John Meacham's - the package idea seems to be related to the first name > :-) and propose them as addition to the standard Show class? It would help > people to convince no to abuse the Show class for pretty printing. My Pretty class is exactly the same as the Show class (i.e. returns a String). I just want two versions of the same thing. It's like Python's repr and str. Both returns strings but with different purposes. Relying on a pp library is often too heavyweight for my needs. -- Johan From igloo at earth.li Wed Feb 13 10:52:19 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Feb 13 10:50:55 2008 Subject: darcs patch: Small documentation fix In-Reply-To: <47a98e3f.2533440a.3040.fffff192@mx.google.com> References: <47a98e3f.2533440a.3040.fffff192@mx.google.com> Message-ID: <20080213155219.GA13861@matrix.chaos.earth.li> On Wed, Feb 06, 2008 at 11:38:53AM +0100, vandijk.roel@gmail.com wrote: > Wed Feb 6 01:58:29 CET 2008 Roel van Dijk > * Small documentation fix Thanks for the patch, Roel! I've applied it. Thanks Ian From dons at galois.com Wed Feb 13 17:31:10 2008 From: dons at galois.com (Don Stewart) Date: Wed Feb 13 17:30:03 2008 Subject: Proposal: Add System.Exit.exitSuccess :: IO a Message-ID: <20080213223110.GG3264@scytale.galois.com> For symmetry with exitFailure :: IO a. Should be pretty uncontroversial. Patch attached. Consideration period: 2 weeks, or until there's no traffic on the subject for a week. ------------------------------------------------------------------------ New patches: [Add exitSuccess :: IO a. For symmetry with exitFailure Don Stewart **20080213222644] { hunk ./System/Exit.hs 16 - ( + ( hunk ./System/Exit.hs 20 + , exitSuccess -- :: IO a hunk ./System/Exit.hs 77 +-- | The computation 'exitSuccess' is equivalent to +-- 'exitWith' 'ExitSuccess', It terminates the program +-- sucessfully. +exitSuccess :: IO a +exitSuccess = exitWith ExitSuccess + } Context: [untabify Don Stewart **20080213221950] [untabify only Don Stewart **20080213221856] [whitespace only Don Stewart **20080207191939] [FIX dynamic001 dynamic002: isTupleTyCon had rotted Simon Marlow **20080205103904 In the patch "Tuple tycons have parens around their names", the names of the tuple tycons were changed to include parens, but isTupleTyCon was not updated to match, which made tuple types show as "(,) a b" rather than "(a,b)" ] [deforestation rules for enumFromThenTo; based on a patch from Robin Houston Ian Lynagh **20080203152755] [Whitespace only Don Stewart **20080207183954] [FIX #1936: hGetBufNonBlocking was blocking on stdin/stdout/stderr Simon Marlow **20080124092203] [The default uncaught exception handler was adding an extra \n Simon Marlow **20080124091216] [add comment about lack of _chsize_s() Simon Marlow **20080123131248] [Windows: large file support for hFileSize and hSeek (#1771) Simon Marlow **20080123102904 ] [Export topHandler, topHandlerFastExit from GHC.TopHandler Ian Lynagh **20080120182429 We now use one of these in ghc when running with ghc -e ] [haddock attributes for haddock-2.0 Ross Paterson **20080120022308] [Data.List.sort: force elements from start to end. Bertram Felgenhauer **20071121101458 this prevents a stack overflow on sort (take 10^6 [1..]) ] [Fix comment on GHC.Ptr.minusPtr simonpj@microsoft.com**20080109114736] [Remove redundant imports of GHC.Err simonpj@microsoft.com**20080104091314 GHC.Base SOURCE-imports GHC.Err, and re-exports 'error'. So other modules need only import GHC.Base. This doesn't change the fact that these other modules are all compiled before GHC.Err, so they are all part of the module loop that starts with GHC.Base and finishes with GHC.Err. But it does reduce the occurrence of those SOURCE imports. ] [Generalise type of forever :: (Monad m) => m a -> m b Don Stewart **20080129191940] [Tuple tycons have parens around their names simonpj@microsoft**20071220171812 The name of the pair TyCon, in the Typeable instance, should be "(,)" not ",". Don't merge to 6.8; it's a minor API change. ] [Add groupWith, sortWith, the, to support generalised list comprehensions simonpj@microsoft.com**20071220111929 This the base-library patch to support the main compiler patch Implement generalised list comprehensions It just adds three functions to GHC.Exts. ] [Add GHC.Prim to exposedModules in the Haddock 0.x hook David Waern *-20071209173931 Please merge to the stable branch ] [Add GHC.Prim to exposedModules in the Haddock 0.x hook David Waern **20071209173931 Please merge to the stable branch ] [Simplify the GHC.Prim hack in base.cabal/Setup.hs Ian Lynagh **20071202215758] [Implement 'openTempFile' for nhc98. Malcolm.Wallace@cs.york.ac.uk**20071207133335] [docs: describe the changes to forkIO, and document forkOnIO Simon Marlow **20071205091423] [doc only: use realToFrac instead of fromRational.toRational Simon Marlow **20071205091334] [Add singletonP to GHC.PArr Roman Leshchinskiy **20071205220859] [FIX #1621: bug in Windows code for getCPUTime Simon Marlow **20071205120118 We were reading the components of FILETIME as CLong, when they should be unsigned. Word32 seems to be the correct type here. ] [protect console handler against concurrent access (#1922) Simon Marlow **20071204153940] [protect against concurrent access to the signal handlers (#1922) Simon Marlow **20071204110817] [restore fdToHandle' to avoid breaking clients (#1109) Simon Marlow **20071130135122 ] [note about how to convert CTime (aka EpochTime) to UTCTime Simon Marlow **20071130101648] [Fix some URLs Ian Lynagh **20071126214213] [Fix some links in haddock docs Ian Lynagh **20071126184428] [Don't try to make haddock links to the mtl package as we don't depend on it Ian Lynagh **20071126170631] [Escape some special characters in haddock docs Ian Lynagh **20071126163443] [FIX BUILD: maybeUpdateFile: ignore failures when removing the target Simon Marlow **20071123092219] [FIX #1753 Simon Marlow **20071122094207 hClose should close the Handle and unlock the file even if calling close() fails for some reason. ] [remove lockFile.h from install-includes Simon Marlow **20071121102248] [oops, we forgot to export traceShow Simon Marlow **20071121094300] [Fix compilation with GHC 6.2.x Simon Marlow **20071121084341] [Move file locking into the RTS, fixing #629, #1109 Simon Marlow **20071120121053 File locking (of the Haskell 98 variety) was previously done using a static table with linear search, which had two problems: the array had a fixed size and was sometimes too small (#1109), and performance of lockFile/unlockFile was suboptimal due to the linear search. Also the algorithm failed to count readers as required by Haskell 98 (#629). Now it's done using a hash table (provided by the RTS). Furthermore I avoided the extra fstat() for every open file by passing the dev_t and ino_t into lockFile. This and the improvements to the locking algorithm result in a healthy 20% or so performance increase for opening/closing files (see openFile008 test). ] [Only overwrite GHC/Prim.hs and GHC/Primopwrappers.hs if they change Simon Marlow **20071120102042 This avoids make doing unnecessary work after 'setup makefile'. ] [fix comment Simon Marlow **20071116091227] [Fix ` characters in elem's haddock docs Ian Lynagh **20071110173052] [Filter out GHC.Prim also for the Haddock step David Waern **20071109000806 Please merge to the GHC 6.8.2 branch ] [Add module of special magic GHC desugaring helper functions Simon Marlow **20071102160054 Currently containing only one such helper: (>>>) for arrow desugaring ] [add Control.Category to the nhc98 build Malcolm.Wallace@cs.york.ac.uk**20071030120459] [fix nhc98 build: need a qualified Prelude import Malcolm.Wallace@cs.york.ac.uk**20071030120410] [Fix performance regression: re-instate -funbox-strict-fields Simon Marlow **20071029150730 Yikes! While investigating the increase in code size with GHC 6.8 relative to 6.6, I noticed that in the transition to Cabal for the libraries we lost -funbox-strict-fields, which is more or less depended on by the IO library for performance. I'm astonished that we didn't notice this earlier! To reduce the chances of this happening again, I put -funbox-strict-fields in the OPTIONS_GHC pragma of the modules that need it. {-# UNPACK #-} pragmas would be better, though. ] [FIX BUILD: Haddock 1.x fails to parse (Prelude..) Simon Marlow **20071029131921] [new Control.Category, ghc ticket #1773 Ashley Yakeley **20071029022526] [new Control.Compositor module Ashley Yakeley **20071013074851 The Compositor class is a superclass of Arrow. ] [Fix doc building with Haddock 0.9 Simon Marlow **20071024090947 I was using a recent build here, which is more tolerant. ] [FIX #1258: document that openTempFile is secure(ish) Simon Marlow **20071023130928 Also change the mode from 0666 to 0600, which seems like a more sensible value and matches what C's mkstemp() does. ] [Clean up .cabal file a bit Duncan Coutts **20071022132708 specify build-type and cabal-version >= 1.2 put extra-tmp-files in the right place use os(windows) rather than os(mingw32) ] [FIX #1652: openTempFile should accept an empty string for the directory Simon Marlow **20071018122345] [clean up duplicate code Simon Marlow **20071017141311] [expose the value of +RTS -N as GHC.Conc.numCapabilities (see #1733) Simon Marlow **20071009132042] [base in 6.8 and head branch should be version 3.0 Don Stewart **20071007150408] [typo Simon Marlow **20070917130703] [put extra-tmp-files field in the right place Simon Marlow **20070914140812] [Add more entries to boring file Ian Lynagh **20070913210500] [Add a boring file Ian Lynagh **20070913204641] [TAG 2007-09-13 Ian Lynagh **20070913215720] [FIX #1689 (openTempFile returns wrong filename) Tim Chevalier **20070913052025] [TAG ghc-6.8 branched 2007-09-03 Ian Lynagh **20070903155541] [Remove some incorrect rules; fixes #1658: CSE [of Doubles] changes semantics Ian Lynagh **20070904134140] [make hWaitForInput/hReady not fail with "invalid argument" on Windows Simon Marlow **20070830131115 See #1198. This doesn't fully fix it, because hReady still always returns False on file handles. I'm not really sure how to fix that. ] [Fix haddock docs in Hashtable Ian Lynagh **20070830154131] [Fix building HashTable: Use ord rather than fromEnum Ian Lynagh **20070830150214] [Better hash functions for Data.HashTable, from Jan-Willem Maessen Ian Lynagh **20070830142844] [Remove redundant include/Makefile Ian Lynagh **20070828205659] [Make arrays safer (e.g. trac #1046) Ian Lynagh **20070810163405] [delete configure droppings in setup clean Simon Marlow **20070824104100] [FIX #1282: 64-bit unchecked shifts are not exported from base Simon Marlow **20070823135033 I've exported these functions from GHC.Exts. They are still implemented using the FFI underneath, though. To avoid conditional exports, on a 64-bit build: uncheckedShiftL64# = uncheckShiftL# (etc.) which has a different type than the 32-bit version of uncheckedShiftL64#, but at least GHC.Exts exports the same names. ] [Fix hashInt Ian Lynagh **20070821140706 As pointed out in http://www.haskell.org/pipermail/glasgow-haskell-bugs/2007-August/009545.html the old behaviour was Prelude Data.HashTable> map hashInt [0..10] [0,-1,-1,-2,-2,-2,-3,-3,-4,-4,-4] Fixed according to the "Fibonacci Hashing" algorithm described in http://www.brpreiss.com/books/opus4/html/page213.html http://www.brpreiss.com/books/opus4/html/page214.html ] [test impl(ghc) instead of IsGHC Ross Paterson **20070819233500] [fpstring.h has moved to bytestring Ross Paterson **20070819233815] [remove now-unused SIG constants Ross Paterson **20070819233745] [include Win32 extra-libraries for non-GHC's too Ross Paterson **20070819233611] [Don't import Distribution.Setup in Setup.hs as we no longer need it Ian Lynagh **20070816151643] [Correct the swapMVar haddock doc Ian Lynagh **20070814145028] [install Typeable.h for use by other packages Malcolm.Wallace@cs.york.ac.uk**20070813112855] [Don't try to build modules no longer living in base. Malcolm.Wallace@cs.york.ac.uk**20070813112803] [Move Data.{Foldable,Traversable} back to base Ian Lynagh **20070812165654 The Array instances are now in Data.Array. ] [Remove bits left over from the old build system Ian Lynagh **20070811135019] [Move the datamap001 (our only test) to the containers package Ian Lynagh **20070803180932] [Data.Array* and Data.PackedString have now moved to their own packages Ian Lynagh **20070801235542] [Remove a number of modules now in a "containers" package Ian Lynagh **20070801223858] [Remove System.Posix.Signals (moving to unix) Ian Lynagh **20070729215213] [bytestring is now in its own package Ian Lynagh **20070729132215] [Export throwErrnoPath* functions Ian Lynagh **20070722002923] [Add simple haddock docs for throwErrnoPath* functions Ian Lynagh **20070722002817] [Move throwErrnoPath* functions from unix:System.Posix.Error Ian Lynagh **20070722002746] [Clarify the swapMVar haddock doc Ian Lynagh **20070807185557] [fix Haddock markup Simon Marlow **20070802081717] [Temporarily fix breakage for nhc98. Malcolm.Wallace@cs.york.ac.uk**20070801163750 A recent patch to System.IO introduced a cyclic dependency on Foreign.C.Error, and also inadvertently dragged along System.Posix.Internals which has non-H'98 layout, causing many build problems. The solution for now is to #ifndef __NHC__ all of the recent the openTempFile additions, and mark them non-portable once again. (I also took the opportunity to note a number of other non-portable functions in their Haddock comments.) ] [Generalise the type of synthesize, as suggested by Trac #1571 simonpj@microsoft**20070801125208 I have not looked at the details, but the type checker is happy with the more general type, and more general types are usually a Good Thing. ] [Fix fdToHandle on Windows Ian Lynagh **20070730133139 The old setmode code was throwing an exception, and I'm not sure it is meant to do what we need anyway. For now we assume that all FDs are both readable and writable. ] [Correct Windows OS name in cabal configuration Ian Lynagh **20070729161739] [Use cabal configurations rather than Setup hacks Ian Lynagh **20070729132157] [Handle buffers should be allocated with newPinnedByteArray# always Simon Marlow **20070725095550 Not just on Windows. This change is required because we now use safe foreign calls for I/O on blocking file descriptors with the threaded RTS. Exposed by concio001.thr on MacOS X: MacOS apparently uses smaller buffers by default, so they weren't being allocated as large objects. ] [fix Hugs implementation of openTempFile Ross Paterson **20070724114003] [Hugs only: avoid dependency cycle Ross Paterson **20070724113852] [open(Binary)TempFile is now portable Ian Lynagh **20070722152752] [Tweak temporary file filename chooser Ian Lynagh **20070722105445] [Move open(Binary)TempFile to System.IO Ian Lynagh **20070722010205] [Rename openFd to fdToHandle' Ian Lynagh **20070721235538 The name collision with System.Posix.IO.openFd made my brain hurt. ] [Add a test for Data.Map, for a bug on the libraries@ list Ian Lynagh **20070721002119] [fix Data.Map.updateAt Bertram Felgenhauer **20070718150340 See http://haskell.org/pipermail/libraries/2007-July/007785.html for a piece of code triggering the bug. updateAt threw away parts of the tree making up the map. ] [in hClose, free the handle buffer by replacing it with an empty one Simon Marlow **20070719161419 This helps reduce the memory requirements for a closed but unfinalised Handle. ] [Implement GHC.Environment.getFullArgs Ian Lynagh **20070717141918 This returns all the arguments, including those normally eaten by the RTS (+RTS ... -RTS). This is mainly for ghc-inplace, where we need to pass /all/ the arguments on to the real ghc. e.g. ioref001(ghci) was failing because the +RTS -K32m -RTS wasn't getting passed on. ] [Define stripPrefix; fixes trac #1464 Ian Lynagh **20070714235204] [no need to hide Maybe Malcolm.Wallace@cs.york.ac.uk**20070710154058] [Add a more efficient Data.List.foldl' for GHC (from GHC's utils/Util.lhs) Ian Lynagh **20070706205526] [Remove include-dirs ../../includes and ../../rts Ian Lynagh **20070705205356 We get these by virtue of depending on the rts package. ] [FIX #1131 (newArray_ allocates an array full of garbage) Simon Marlow **20070704102020 Now newArray_ returns a deterministic result in the ST monad, and behaves as before in other contexts. The current newArray_ is renamed to unsafeNewArray_; the MArray class therefore has one more method than before. ] [change nhc98 option from -prelude to --prelude Malcolm.Wallace@cs.york.ac.uk**20070702150355] [Word is a type synonym in nhc98 - so class instance not permitted. Malcolm.Wallace@cs.york.ac.uk**20070629122035] [fix bug in writes to blocking FDs in the non-threaded RTS Simon Marlow **20070628134320] [Modernize printf. lennart.augustsson@credit-suisse.com**20070628083852 Add instances for Int8, Int16, Int32, Int64, Word, Word8, Word16, Word32, and Word64. Handle + flag. Handle X, E, and G formatting characters. Rewrite internals to make it simpler. ] [Speed up number printing and remove the need for Array by using the standard 'intToDigit' routine John Meacham **20070608182353] [Use "-- //" (2 spaces) rather than "-- //" (1) to avoid tripping haddock up Ian Lynagh **20070627010930 Are we nearly there yet? ] [Use a combination of Haskell/C comments to ensure robustness. Malcolm.Wallace@cs.york.ac.uk**20070626095222 e.g. -- // ensures that _no_ preprocessor will try to tokenise the rest of the line. ] [Change C-style comments to Haskell-style. Malcolm.Wallace@cs.york.ac.uk**20070625094515 These two headers are only ever used for pre-processing Haskell code, and are never seen by any C tools except cpp. Using the Haskell comment convention means that cpphs no longer needs to be given the --strip option to remove C comments from open code. This is a Good Thing, because all of /* */ and // are valid Haskell operator names, and there is no compelling reason to forbid using them in files which also happen to have C-preprocessor directives. ] [makefileHook needs to generate PrimopWrappers.hs too Simon Marlow **20070622073424] [Hugs now gets MonadFix(mfix) from its prelude Ross Paterson **20070620000343] [Typo (consUtils.hs -> consUtils.h) Ian Lynagh **20070619124140] [install dependent include files and Typeable.h Bertram Felgenhauer **20070613041734] [update prototype following inputReady->fdReady change Simon Marlow **20070614095309] [FIX hGetBuf001: cut-and-pasto in readRawBufferNoBlock Simon Marlow **20070614094222] [fix description of CWStringLen Ross Paterson **20070605223345] [Remove unsafeCoerce-importing kludgery in favor of Unsafe.Coerce Isaac Dupree **20070601203625] [--configure-option and --ghc-option are now provided by Cabal Ross Paterson **20070604115233] [Data.PackedString: Data.Generics is GHC-only Ross Paterson **20070529232427] [Add Data instance for PackedString; patch from greenrd in trac #1263 Ian Lynagh **20070529205420] [Control.Concurrent documentation fix shae@ScannedInAvian.com**20070524163325] [add nhc98-options: field to .cabal file Malcolm.Wallace@cs.york.ac.uk**20070528122626] [add a dummy implementation of System.Timeout.timeout for nhc98 Malcolm.Wallace@cs.york.ac.uk**20070528110309] [Add System.Timeout to base.cabal Ian Lynagh **20070527123314 Filtered out for non-GHC by Setup.hs. ] [add module Data.Fixed to nhc98 build Malcolm.Wallace@cs.york.ac.uk**20070525141021] [DIRS now lives in package Makefile, not script/pkgdirlist Malcolm.Wallace@cs.york.ac.uk**20070525111749] [delete unused constants Ross Paterson **20070525001741] [remove System.Cmd and System.Time too Malcolm.Wallace@cs.york.ac.uk**20070524163200] [remove locale as well Malcolm.Wallace@cs.york.ac.uk**20070524161943] [nhc98 version of instance Show (a->b) copied from Prelude Malcolm.Wallace@cs.york.ac.uk**20070524160615] [remove directory, pretty, and random bits from base for nhc98 Malcolm.Wallace@cs.york.ac.uk**20070524160608] [Remove Makefile and package.conf.in (used in the old build system) Ian Lynagh **20070524142545] [Split off process package Ian Lynagh **20070523210523] [Fix comment: maperrno is in Win32Utils.c, not runProcess.c Ian Lynagh **20070523181331] [System.Locale is now split out Ian Lynagh **20070519132638] [Split off directory, random and old-time packages Ian Lynagh **20070519120642] [Remove Control.Parallel*, now in package parallel Ian Lynagh **20070518165431] [Remove the pretty-printing modules (now in package pretty( Ian Lynagh **20070518162521] [add install-includes: field Simon Marlow **20070517094948] [correct the documentation for newForeignPtr Simon Marlow **20070516082019] [When doing safe writes, handle EAGAIN rather than raising an exception Simon Marlow **20070515114615 It might be that stdin was set to O_NONBLOCK by someone else, and we should handle this case. (this happens with GHCi, I'm not quite sure why) ] [Use FilePath to make paths when building GHC/Prim.hs and GHC/PrimopWrappers.hs Ian Lynagh **20070514110409] [Build GHC/Prim.hs and GHC/PrimopWrappers.hs from Cabal Ian Lynagh **20070509142655] [fix imports for non-GHC Ross Paterson **20070513001138] [Give an example of how intersection takes elements from the first set Ian Lynagh **20070512160253] [further clarify the docs for 'evaluate' Malcolm.Wallace@cs.york.ac.uk**20070508101124] [improve documentation for evaluate Simon Marlow **20070508081712] [FIX: #724 (tee complains if used in a process started by ghc) Simon Marlow **20070507123537 Now, we only set O_NONBLOCK on file descriptors that we create ourselves. File descriptors that we inherit (stdin, stdout, stderr) are kept in blocking mode. The way we deal with this differs between the threaded and non-threaded runtimes: - with -threaded, we just make a safe foreign call to read(), which may block, but this is ok. - without -threaded, we test the descriptor with select() before attempting any I/O. This isn't completely safe - someone else might read the data between the select() and the read() - but it's a reasonable compromise and doesn't seem to measurably affect performance. ] [the "unknown" types are no longer required Simon Marlow **20070426135931] [Make Control.Exception buildable by nhc98. Malcolm.Wallace@cs.york.ac.uk**20070504105548 The nhc98 does not have true exceptions, but these additions should be enough infrastructure to pretend that it does. Only IO exceptions will actually work. ] [Trim imports, remove a cycle simonpj@microsoft**20070503123010 A first attempt at removing gratuitous cycles in the base package. I've removed the useless module GHC.Dynamic, which gets rid of a cycle; and trimmed off various unnecesary imports. This also fixes the IsString import problem. ] [Be less quiet about building the base package simonpj@microsoft**20070503093707] [Remove Splittable class (a vestige of linear implicit parameters) simonpj@microsoft**20070221104329] [Add IsString to exports of GHC.Exts simonpj@microsoft**20070221104249] [tweak documentation as per suggestion from Marc Weber on libraries@haskell.org Simon Marlow **20070426075921] [Add extra libraries when compiling with GHC on Windows Ian Lynagh **20070424213127] [Follow Cabal changes in Setup.hs Ian Lynagh **20070418114345] [inclusion of libc.h is conditional on __APPLE__ Malcolm.Wallace@cs.york.ac.uk**20070417085556] [MERGE: fix ugly uses of memcpy foreign import inside ST Simon Marlow **20070416101530 fixes cg026 ] [Fix configure with no --with-cc Ian Lynagh **20070415165143] [MacOS 10.3 needs #include as well Malcolm.Wallace@cs.york.ac.uk**20070414155507] [For nhc98 only, use hsc2hs to determine System.Posix.Types. Malcolm.Wallace@cs.york.ac.uk**20070413155831 Avoids the existing autoconf stuff, by introducing an auxiliary module called NHC.PosixTypes that uses hsc2hs, which is then simply re-exported from System.Posix.Types. ] [we need a makefileHook too Simon Marlow **20070413151307] [Remove unnecesary SOURCE import of GHC.Err in GHC.Pack Ian Lynagh **20070412235908] [add System.Posix.Types to default nhc98 build Malcolm.Wallace@cs.york.ac.uk**20070412195026] [mark System.IO.openTempFile as non-portable in haddocks Malcolm.Wallace@cs.york.ac.uk**20070412135359] [Don't turn on -Werror in Data.Fixed Ian Lynagh **20070411155721 This may be responsible for the x86_64/Linux nightly build failing. ] [Fix -Wall warnings Ian Lynagh **20070411004929] [Add missing case in removePrefix Ian Lynagh **20070411002537] [Allow additional options to pass on to ./configure to be given Ian Lynagh **20070406151856] [Hugs only: fix location of unsafeCoerce Ross Paterson **20070406113731] [fix isPortableBuild test Ross Paterson **20070406111304] [Unsafe.Coerce doesn't need Prelude Ian Lynagh **20070405175930] [make Setup and base.cabal suitable for building the libraries with GHC Ian Lynagh **20070308163824] [HsByteArray doesn't exist Ian Lynagh **20070404163051] [Don't use Fd/FD in foreign decls Ian Lynagh **20070404155822 Using CInt makes it much easier to verify that it is right, and we won't get caught out by possible newtype switches between CInt/Int. ] [HsByteArray doesn't exist Ian Lynagh **20070404155732] [Fix braino Ian Lynagh **20070404144508] [Fix incorrect changes to C types in a foreign import for nhc98. Malcolm.Wallace@cs.york.ac.uk**20070404120954 If we use type CTime, it needs to be imported. Also, CTime is not an instance of Integral, so use some other mechanism to convert it. ] [Fix C/Haskell type mismatches Ian Lynagh **20070403194943] [add new module Unsafe.Coerce to build system Malcolm.Wallace@cs.york.ac.uk**20070403131333] [Fix type mismatches between foreign imports and HsBase.h Ian Lynagh **20070403001611 Merge to stable, checking for interface changes. ] [put 'unsafeCoerce' in a standard location Malcolm.Wallace@cs.york.ac.uk**20061113114103] [fix for nhc98 build Malcolm.Wallace@cs.york.ac.uk**20070402141712] [Function crossMapP for fixing desugaring of comprehensions Manuel M T Chakravarty **20070402082906 Merge into 6.6 branch. ] [Add min/max handling operations for IntSet/IntMap jeanphilippe.bernardy@gmail.com**20070315072352] [Monoid instance for Maybe and two wrappers: First and Last. trac proposal #1189 Jeffrey Yasskin **20070309062550] [Fix the type of wgencat Ian Lynagh **20070329164223] [fix strictness of foldr/build rule for take, see #1219 Simon Marlow **20070327103941] [remove Makefile.inc (only affects nhc98) Malcolm.Wallace@cs.york.ac.uk**20070320120057] [copyBytes copies bytes, not elements; fixes trac #1203 Ian Lynagh **20070312113555] [Add ioeGetLocation, ioeSetLocation to System/IO/Error.hs; trac #1191 Ian Lynagh **20070304130315] [fix race condition in prodServiceThread Simon Marlow **20070307134330 See #1187 ] [Prevent duplication of unsafePerformIO on a multiprocessor Simon Marlow **20070306145424 Fixes #986. The idea is to add a new operation noDuplicate :: IO () it is guaranteed that if two threads have executed noDuplicate, then they are not duplicating any computation. We now provide two new unsafe operations: unsafeDupablePerformIO :: IO a -> a unsafeDupableInterleaveIO :: IO a -> IO a which are equivalent to the old unsafePerformIO and unsafeInterleaveIO respectively. The new versions of these functions are defined as: unsafePerformIO m = unsafeDupablePerformIO (noDuplicate >> m) unsafeInterleaveIO m = unsafeDupableInterleaveIO (noDuplicate >> m) ] [expand docs for forkOS Simon Marlow **20070305160921] [document timeout limitations Peter Simons **20070228223540] [So many people were involved in the writing of this module that Peter Simons **20070228223415 it feels unfair to single anyone out as the lone copyright holder. ] [This patch adds a timeout function to the base libraries. Trac #980 is Peter Simons **20070126222615 concerned with this issue. The design guideline for this implementation is that 'timeout N E' should behave exactly the same as E as long as E doesn't time out. In our implementation, this means that E has the same myThreadId it would have without the timeout wrapper. Any exception E might throw cancels the timeout and propagates further up. It also possible for E to receive exceptions thrown to it by another thread. ] [PArr: fixed permutations Manuel M T Chakravarty **20070305055807] [Add Data.String, containing IsString(fromString); trac proposal #1126 Ian Lynagh **20070130134841 This is used by the overloaded strings extension (-foverloaded-strings in GHC). ] [GHC.PArr: add bounds checking Manuel M T Chakravarty **20070302053224] [Bump nhc98 stack size for System/Time.hsc sven.panne@aedion.de**20070301153009] [FDs are CInts now, fixing non-GHC builds sven.panne@aedion.de**20070225105620] [Fixed PArr.dropP Manuel M T Chakravarty **20070222032405 - Thanks to Audrey Tang for the bug report ] [Keep the same FD in both halves of a duplex handle when dup'ing Ian Lynagh **20070220141039 Otherwise we only close one of the FDs when closing the handle. Fixes trac #1149. ] [Remove more redundant FD conversions Ian Lynagh **20070220092520] [Fix FD changes on Windows Ian Lynagh **20070220091516] [Consistently use CInt rather than Int for FDs Ian Lynagh **20070219233854] [Fix the types of minView/maxView (ticket #1134) jeanphilippe.bernardy@gmail.com**20070210065115] [fix for hashString, from Jan-Willem Maessen (see #1137) Simon Marlow **20070215094304 ] [fix to getUSecOfDay(): arithmetic was overflowing Simon Marlow **20070214161719] [The Windows counterpart to 'wrapround of thread delays' Ian Lynagh **20070209173510] [wrapround of thread delays Neil Davies **20070129160519 * made the wrapround of the underlying O/S occur before the wrapround of the delayed threads by making threads delay in microseconds since O/S epoch (1970 - Unix, 1601 - Windows) stored in Word64. * removed redundant calls reading O/S realtime clock * removed rounding to 1/50th of sec for timers * Only for Unix version of scheduler. ] [Whitespace changes only Ian Lynagh **20070206232722] [Add some type sigs Ian Lynagh **20070206232439] [Use static inline rather than extern inline/inline Ian Lynagh **20070205203628 I understand this is more portable, and it also fixes warnings when C things we are wrapping are themselves static inlines (which FD_ISSET is on ppc OS X). ] [add derived instances for Dual monoid Ross Paterson **20070202190847] [add doc pointers to Foldable Ross Paterson **20070202110931 Could be applied to STABLE. ] [Eliminate some warnings Ian Lynagh **20060729220854 Eliminate warnings in the libraries caused by mixing pattern matching with numeric literal matching. ] [Remove IsString(fromString) from the Prelude Ian Lynagh **20070130124136] [Add Kleisli composition Don Stewart **20061113015442] [IsString is GHC-only (so why is it in the Prelude?) Ross Paterson **20070123183007] [Applicative and Monad instances for Tree Ross Paterson **20070115174510] [Add IsString class for overloaded string literals. lennart@augustsson.net**20061221210532] [Added examples, more detailed documentation to Data.List Extracting sublists functions Andriy Palamarchuk **20061204164710] [fix threadDelay Simon Marlow **20070117091702 In "Add support for the IO manager thread" I accidentally spammed part of "Make sure the threaded threadDelay sleeps at least as long as it is asked", which is why the ThreadDelay001 test has been failing. ] [update section on "blocking" Simon Marlow **20070116124328] [Fix crash with (minBound :: Int*) `div (-1) as result is maxBound + 1. Ian Lynagh **20070115142005] [version of example using Tomasz Zielonka's technique Ross Paterson **20070105175907] [Added Unknowns for higher kinds Pepe Iborra **20061108155938] [Improved the Show instance for Unknown Pepe Iborra **20060813111816] [Show instance for GHC.Base.Unknown mnislaih@gmail.com**20060801233530] [Introduce Unknowns for the closure viewer. Add breakpointCond which was missing mnislaih@gmail.com**20060725174537] [Fix missing comma in Fractional documentation Alec Berryman **20061201173237] [Mention that throwTo does not guarantee promptness of delivery simonpj@microsoft**20061211123215] [Add note about synhronous delivery of throwTo simonpj@microsoft**20061211122257] [documentation for installHandler Simon Marlow **20061205154927 merge to 6.6 ] [dos2unix Simon Marlow **20061204095439] [don't try to compile this on Unix Simon Marlow **20061204095427] [TAG 6.6 release Ian Lynagh **20061011124740] [TAG Version 2.1 Ian Lynagh **20061009114014] [Bump version number Ian Lynagh **20061009114009] [Add support for the IO manager thread on Windows Simon Marlow **20061201152042 Fixes #637. The test program in that report now works for me with -threaded, but it doesn't work without -threaded (I don't know if that's new behaviour or not, though). ] [deriving (Eq, Ord, Enum, Show, Read, Typeab) for ConsoleEvent Simon Marlow **20061201144032] [Make sure the threaded threadDelay sleeps at least as long as it is asked to Ian Lynagh **20061128204807] [Add comments about argument order to the definitions of gmapQ and constrFields simonpj@microsoft**20061124164505] [Hugs: add Control.Parallel.Strategies Ross Paterson **20061124161039] [Move instance of Show Ptr to Ptr.hs (fewer orphans) simonpj@microsoft.com**20061124100639] [Add type signatures simonpj@microsoft.com**20061124100621] [Add an example of the use of unfoldr, following doc feedback from dozer Don Stewart **20061124011249] [trim imports Ross Paterson **20061123190352] [Data.Graph is now portable (enable for nhc98) Malcolm.Wallace@cs.york.ac.uk**20061123174913] [remove Data.FunctorM and Data.Queue Ross Paterson **20061112001046 These were deprecated in 6.6, and can thus be removed in 6.8. ] [make Data.Graph portable (no change to the interface) Ross Paterson **20061122010040 The algorithm now uses STArrays on GHC and IntSets elsewhere. (Hugs has STArrays, but avoiding them saves a -98, and boxed arrays aren't fast under Hugs anyway.) ] [One less unsafeCoerce# in the tree Don Stewart **20061120120242] [typo in comment Ross Paterson **20061120115106] [fix shift docs to match ffi spec Ross Paterson **20061117003144] [(nhc98) use new primitive implementations of h{Put,Get}Buf. Malcolm.Wallace@cs.york.ac.uk**20061116173104] [The wrong 'cycle' was exported from Data.ByteString.Lazy.Char8, spotted by sjanssen Don Stewart **20061110021311] [LPS chunk sizes should be 16 bytes, not 17. Don Stewart **20061110021254] [Update comments on Prelude organisation in GHC/Base.lhs Ian Lynagh **20061115001926] [Control.Parallel.Strategies clean-up: Added export list to avoid exporting seq, fixed import list strangeness that haddock choked on, and moved the deprecated functions to a separate section. bringert@cs.chalmers.se**20061113224202] [Control.Parallel.Strategies: added NFData instances for Data.Int.*, Data.Word.*, Maybe, Either, Map, Set, Tree, IntMap, IntSet. bringert@cs.chalmers.se**20061113221843] [Control.Parallel.Strategies: deprecate sPar, sSeq, Assoc, fstPairFstList, force and sforce. bringert@cs.chalmers.se**20061113215219 Code comments indicated that sPar and sSeq have been superceded by sparking and demanding, and that Assoc, fstPairFstList, force and sforce are examples and hacks needed by the Lolita system. ] [add Control.Monad.Instances to nhc98 build Malcolm.Wallace@cs.york.ac.uk**20061113113221] [Control.Parallel.Strategies: clarified documentation of parListChunk. bringert@cs.chalmers.se**20061112232904] [Added and cleaned up Haddock comments in Control.Parallel.Strategies. bringert@cs.chalmers.se**20061112220445 Many of the definitions in Control.Parallel.Strategies had missing or unclear Haddock comments. I converted most of the existing plain code comments to haddock comments, added some missing documentation and cleaned up the existing Haddock mark-up. ] [Fix broken pragmas; spotted by Bulat Ziganshin Ian Lynagh **20061111205916] [add doc link to bound threads section Ross Paterson **20060929103252] [hide Data.Array.IO.Internals Ross Paterson **20061111113248 It's hidden from haddock, and everything it exports is re-exported by Data.Array.IO. ] [add Data.Function Malcolm.Wallace@cs.york.ac.uk**20061110142710] [add Data.Function Ross Paterson **20061110141354] [whitespace only Ross Paterson **20061110141326] [move fix to Data.Function Ross Paterson **20061110141120] [import Prelude Ross Paterson **20061110140445] [Added Data.Function (Trac ticket #979). Nils Anders Danielsson **20061110122503 + A module with simple combinators working solely on and with functions. + The only new function is "on". + Some functions from the Prelude are re-exported. ] [__hscore_long_path_size is not portable beyond GHC Malcolm.Wallace@cs.york.ac.uk**20061110113222] [redefine writeFile and appendFile using withFile Ross Paterson **20061107140359] [add withFile and withBinaryFile (#966) Ross Paterson **20061107134510] [remove conflicting import for nhc98 Malcolm.Wallace@cs.york.ac.uk**20061108111215] [Add intercalate to Data.List (ticket #971) Josef Svenningsson **20061102122052] [non-GHC: fix canonicalizeFilePath Ross Paterson **20061107133902 I've also removed the #ifdef __GLASGOW_HASKELL__ from the proper Windows versions of a few functions. These will need testing with Hugs on Windows. ] [enable canonicalizePath for non-GHC platforms Simon Marlow **20061107121141] [Update documentation for hWaitForInput Simon Marlow **20061107111430 See #972 Merge to 6.6 branch. ] [Use unchecked shifts to implement Data.Bits.rotate Samuel Bronson **20061012125553 This should get rid of those cases, maybe lower the size enough that the inliner will like it? ] [fix Haddock module headers Ross Paterson **20061106124140] [fix example in docs Ross Paterson **20061106115628] [Add intercalate and split to Data.List Josef Svenningsson *-20061024172357] [Data.Generics.Basics is GHC-only Ross Paterson **20061102111736] [#ifdef around non-portable Data.Generics.Basics Malcolm.Wallace@cs.york.ac.uk**20061102103445] [Add deriving Data to Complex simonpj@microsoft**20061101102059] [minor clarification of RandomGen doc Ross Paterson **20061030230842] [rearrange docs a bit Ross Paterson **20061030161223] [Add intercalate and split to Data.List Josef Svenningsson **20061024172357] [Export pseq from Control.Parallel, and use it in Control.Parallel.Strategies Simon Marlow **20061027150141] [`par` should be infixr 0 Simon Marlow **20061027130800 Alas, I didn't spot this due to lack of testing, and the symptom is that an expression like x `par` y `seq z will have exactly the wrong parallelism properties. The workaround is to add parantheses. I think we could push this to the 6.6 branch. ] [fix example in comment Ross Paterson **20061023163925] [Use the new Any type for dynamics (GHC only) simonpj@microsoft**20061019160408] [add Data.Sequence to nhc98 build Malcolm.Wallace@cs.york.ac.uk**20061012135200] [Remove Data.FiniteMap, add Control.Applicative, Data.Traversable, and Malcolm.Wallace@cs.york.ac.uk**20061012095605 Data.Foldable to the nhc98 build. ] [STM invariants tharris@microsoft.com**20061007123253] [Inline shift in GHC's Bits instances for {Int,Word}{,8,16,32,64} Samuel Bronson **20061009020906] [Don't create GHC.Prim when bootstrapping; we can't, and we don't need it Ian Lynagh **20061004165355] [Data.ByteString: fix lazyness of take, drop & splitAt Don Stewart **20061005011703 ByteString.Lazy's take, drop and splitAt were too strict when demanding a byte string. Spotted by Einar Karttunen. Thanks to him and to Bertram Felgenhauer for explaining the problem and the fix. ] [Fix syntax error that prevents building Haddock documentation on Windows brianlsmith@gmail.com**20060917013530] [Hugs only: unbreak typeRepKey Ross Paterson **20060929102743] [make hGetBufNonBlocking do something on Windows w/ -threaded Simon Marlow **20060927145811 hGetBufNonBlocking will behave the same as hGetBuf on Windows now, which is better than just crashing (which it did previously). ] [add typeRepKey :: TypeRep -> IO Int Simon Marlow **20060927100342 See feature request #880 ] [fix header comment Ross Paterson **20060926135843] [Add strict versions of insertWith and insertWithKey (Data.Map) jeanphilippe.bernardy@gmail.com**20060910162443] [doc tweaks, including more precise equations for evaluate Ross Paterson **20060910115259] [Sync Data.ByteString with stable branch Don Stewart **20060909050111 This patch: * hides the LPS constructor (its in .Base if you need it) * adds functions to convert between strict and lazy bytestrings * and adds readInteger ] [Typeable1 instances for STM and TVar Ross Paterson **20060904231425] [remove obsolete Hugs stuff Ross Paterson **20060904223944] [Cleaner isInfixOf suggestion from Ross Paterson John Goerzen **20060901143654] [New function isInfixOf that searches a list for a given sublist John Goerzen **20060831151556 Example: isInfixOf "Haskell" "I really like Haskell." -> True isInfixOf "Ial" "I really like Haskell." -> False This function was first implemented in MissingH as MissingH.List.contains ] [Better doc on Data.Map.lookup: explain what the monad is for jeanphilippe.bernardy@gmail.com**20060903133440] [fix hDuplicateTo on Windows Simon Marlow **20060901150016 deja vu - I'm sure I remember fixing this before... ] [Improve documentation of atomically simonpj@microsoft**20060714120207] [Add missing method genRange for StdGen (fixes #794) simonpj@microsoft**20060707151901 MERGE TO STABLE Trac #794 reports (correctly) that the implementation of StdGen only returns numbers in the range (0..something) rather than (minBound, maxBound), which is what StdGen's genRange claims. This commit fixes the problem, by implementing genRange for StdGen (previously it just used the default method). ] [mark nhc98 import hack Ross Paterson **20060831125219] [remove some outdated comments Simon Marlow **20060831104200] [import Control.Arrow.ArrowZero to help nhc98's type checker Malcolm.Wallace@cs.york.ac.uk**20060831101105] [remove Text.Regex(.Posix) from nhc98 build Malcolm.Wallace@cs.york.ac.uk**20060831101016] [add Data.Foldable.{msum,asum}, plus tweaks to comments Ross Paterson **20060830163521] [fix doc typo Ross Paterson **20060830134123] [add Data.Foldable.{for_,forM_} and Data.Traversable.{for,forM} Ross Paterson **20060830133805 generalizing Control.Monad.{forM_,forM} ] [Make length a good consumer simonpj@microsoft*-20060508142726 Make length into a good consumer. Fixes Trac bug #707. (Before length simply didn't use foldr.) ] [Add Control.Monad.forM and forM_ Don Stewart **20060824081118 flip mapM_ is more and more common, I find. Several suggestions have been made to add this, as foreach or something similar. This patch does just that: forM :: (Monad m) => [a] -> (a -> m b) -> m [b] forM_ :: (Monad m) => [a] -> (a -> m b) -> m () So we can write: Prelude Control.Monad> forM_ [1..4] $ \x -> print x 1 2 3 4 ] [Hide internal module from haddock in Data.ByteString Don Stewart **20060828011515] [add advice on avoiding import ambiguities Ross Paterson **20060827170407] [expand advice on importing these modules Ross Paterson **20060827164044] [add Haddock marker Ross Paterson **20060827115140] [Clarify how one hides Prelude.catch Don Stewart **20060826124346 User feedback indicated that an example was required, of how to hide Prelude.catch, so add such an example to the docs ] [Workaround for OSes that don't have intmax_t and uintmax_t Ian Lynagh **20060825134936 OpenBSD (and possibly others) do not have intmax_t and uintmax_t types: http://www.mail-archive.com/haskell-prime@haskell.org/msg01548.html so substitute (unsigned) long long if we have them, otherwise (unsigned) long. ] [add docs for par Simon Marlow **20060825110610] [document minimal complete definition for Bits Ross Paterson **20060824140504] [C regex library bits have moved to the regex-posix package Simon Marlow **20060824132311] [Add shared Typeable support (ghc only) Esa Ilari Vuokko **20060823003126] [this should have been removed with the previous patch Simon Marlow **20060824121223] [remove Text.Regx & Text.Regex.Posix Simon Marlow **20060824094615 These are subsumed by the new regex-base, regex-posix and regex-compat packages. ] [explicitly tag Data.ByteString rules with the FPS prefix. Don Stewart **20060824041326] [Add spec rules for sections in Data.ByteString Don Stewart **20060824012611] [Sync Data.ByteString with current stable branch, 0.7 Don Stewart **20060823143338] [add notes about why copyFile doesn't remove the target Simon Marlow **20060823095059] [copyFile: try removing the target file before opening it for writing Simon Marlow *-20060822121909] [copyFile: try removing the target file before opening it for writing Simon Marlow **20060822121909] [add alternative functors and extra instances Ross Paterson **20060821152151 * Alternative class, for functors with a monoid * instances for Const * instances for arrows ] [generate Haddock docs on all platforms Simon Marlow **20060821131612] [remove extra comma from import Ross Paterson **20060819173954] [fix docs for withC(A)StringLen Ross Paterson **20060818170328] [use Haskell'98 compliant indentation in do blocks Malcolm.Wallace@cs.york.ac.uk**20060818130810] [use correct names of IOArray operations for nhc98 Malcolm.Wallace@cs.york.ac.uk**20060818130714] [add mapMaybe and mapEither, plus WithKey variants Ross Paterson **20060817235041] [remove Text.Html from nhc98 build Malcolm.Wallace@cs.york.ac.uk**20060817135502] [eliminate more HOST_OS tests Ross Paterson **20060815190609] [Hugs only: disable unused process primitives Ross Paterson **20060813184435 These were the cause of Hugs bug #30, I think, and weren't used by Hugs anyway. ] [markup fix to Data.HashTable Ross Paterson **20060812103835] [revert removal of ghcconfig.h from package.conf.in Ross Paterson **20060812082702 as it's preprocessed with -undef (pointed out by Esa Ilari Vuokko) ] [fix Data.HashTable for non-GHC Ross Paterson **20060811231521] [remove deprecated 'withObject' Simon Marlow **20060811152350] [Jan-Willem Maessen's improved implementation of Data.HashTable Simon Marlow **20060811151024 Rather than incrementally enlarging the hash table, this version just does it in one go when the table gets too full. ] [Warning police: Make some prototypes from the RTS known sven.panne@aedion.de**20060811144629] [Warning police: Removed useless catch-all clause sven.panne@aedion.de**20060811142208] [reduce dependency on ghcconfig.h Ross Paterson **20060811124030 The only remaining use is in cbits/dirUtils.h, which tests solaris2_HOST_OS (Also System.Info uses ghcplatform.h and several modules import MachDeps.h to get SIZEOF_* and ALIGNMENT_* from ghcautoconf.h) ] [(non-GHC only) track MArray interface change Ross Paterson **20060810182902] [move Text.Html to a separate package Simon Marlow **20060810113017] [bump version to 2.0 Simon Marlow **20060810112833] [Remove deprecated Data.FiniteMap and Data.Set interfaces Simon Marlow **20060809153810] [move altzone test from ghc to base package Ross Paterson **20060809124259] [remove unnecessary #include "ghcconfig.h" Ross Paterson **20060809123812] [Change the API of MArray to allow resizable arrays Simon Marlow **20060809100548 See #704 The MArray class doesn't currently allow a mutable array to change its size, because of the pure function bounds :: (HasBounds a, Ix i) => a i e -> (i,i) This patch removes the HasBounds class, and adds getBounds :: (MArray a e m, Ix i) => a i e -> m (i,i) to the MArray class, and bounds :: (IArray a e, Ix i) => a i e -> (i,i) to the IArray class. The reason that bounds had to be incorporated into the IArray class is because I couldn't make DiffArray work without doing this. DiffArray acts as a layer converting an MArray into an IArray, and there was no way (that I could find) to define an instance of HasBounds for DiffArray. ] [deprecate this module. Simon Marlow **20060808100708] [add traceShow (see #474) Simon Marlow **20060807155545] [remove spurious 'extern "C" {' Simon Marlow **20060724160258] [Fix unsafeIndex for large ranges Simon Marlow **20060721100225] [disambiguate uses of foldr for nhc98 to compile without errors Malcolm.Wallace@cs.york.ac.uk**20060711161614] [make Control.Monad.Instances compilable by nhc98 Malcolm.Wallace@cs.york.ac.uk**20060711160941] [breakpointCond Lemmih **20060708055528] [UNDO: Merge "unrecognized long opt" fix from 6.4.2 Simon Marlow **20060705142537 This patch undid the previous patch, "RequireOrder: do not collect unrecognised options after a non-opt". I asked Sven to revert it, but didn't get an answer. See bug #473. ] [Avoid strictness in accumulator for unpackFoldr Don Stewart **20060703091806 The seq on the accumulator for unpackFoldr will break in the presence of head/build rewrite rules. The empty list case will be forced, producing an exception. This is a known issue with seq and rewrite rules that we just stumbled on to. ] [Disable unpack/build fusion Don Stewart **20060702083913 unpack/build on bytestrings seems to trigger a bug when interacting with head/build fusion in GHC.List. The bytestring001 testcase catches it. I'll investigate further, but best to disable this for now (its not often used anyway). Note that with -frules-off or ghc 6.4.2 things are fine. It seems to have emerged with the recent rules changes. ] [Import Data.ByteString.Lazy, improve ByteString Fusion, and resync with FPS head Don Stewart **20060701084345 This patch imports the Data.ByteString.Lazy module, and its helpers, providing a ByteString implemented as a lazy list of strict cache-sized chunks. This type allows the usual lazy operations to be written on bytestrings, including lazy IO, with much improved space and time over the [Char] equivalents. ] [Wibble in docs for new ForeignPtr functionsn Don Stewart **20060609075924] [comments for Applicative and Traversable Ross Paterson **20060622170436] [default to NoBuffering on Windows for a read/write text file Simon Marlow **20060622144446 Fixes (works around) #679 ] [remove dead code Simon Marlow **20060622144433] [clarify and expand docs Simon Marlow **20060622112911] [Add minView and maxView to Map and Set jeanphilippe.bernardy@gmail.com**20060616180121] [add signature for registerDelay Ross Paterson **20060614114456] [a few doc comments Ross Paterson **20060613142704] [Optimised foreign pointer representation, for heap-allocated objects Don Stewart **20060608015011] [Add the inline function, and many comments simonpj@microsoft.com**20060605115814 This commit adds the 'inline' function described in the related patch in the compiler. I've also added comments about the 'lazy' function. ] [small intro to exceptions Ross Paterson **20060525111604] [export breakpoint Simon Marlow **20060525090456] [Merge in changes from fps head. Highlights: Don Stewart **20060525065012 Wed May 24 15:49:38 EST 2006 sjanssen@cse.unl.edu * instance Monoid ByteString Wed May 24 15:04:04 EST 2006 Duncan Coutts * Rearange export lists for the .Char8 modules Wed May 24 14:59:56 EST 2006 Duncan Coutts * Implement mapAccumL and reimplement mapIndexed using loopU Wed May 24 14:47:32 EST 2006 Duncan Coutts * Change the implementation of the unfoldr(N) functions. Use a more compact implementation for unfoldrN and change it's behaviour to only return Just in the case that it actually 'overflowed' the N, so the boundary case of unfolding exactly N gives Nothing. Implement unfoldr and Lazy.unfoldr in terms of unfoldrN. Use fibonacci growth for the chunk size in unfoldr Wed May 24 08:32:29 EST 2006 sjanssen@cse.unl.edu * Add unfoldr to ByteString and .Char8 A preliminary implementation of unfoldr. Wed May 24 01:39:41 EST 2006 Duncan Coutts * Reorder the export lists to better match the Data.List api Tue May 23 14:04:32 EST 2006 Don Stewart * pack{Byte,Char} -> singleton. As per fptools convention Tue May 23 14:00:51 EST 2006 Don Stewart * elemIndexLast -> elemIndexEnd Tue May 23 13:57:34 EST 2006 Don Stewart * In the search for a more orthogonal api, we kill breakFirst/breakLast, which were of dubious value Tue May 23 12:24:09 EST 2006 Don Stewart * Abolish elems. It's name implied it was unpack, but its type didn't. it made no sense Tue May 23 10:42:09 EST 2006 Duncan Coutts * Minor doc tidyup. Use haddock markup better. Tue May 23 11:00:31 EST 2006 Don Stewart * Simplify the join() implementation. Spotted by Duncan. ] [add a way to ask the IO manager thread to exit Simon Marlow **20060524121823] [Sync with FPS head, including the following patches: Don Stewart **20060520030436 Thu May 18 15:45:46 EST 2006 sjanssen@cse.unl.edu * Export unsafeTake and unsafeDrop Fri May 19 11:53:08 EST 2006 Don Stewart * Add foldl1' Fri May 19 13:41:24 EST 2006 Don Stewart * Add fuseable scanl, scanl1 + properties Fri May 19 18:20:40 EST 2006 Don Stewart * Spotted another chance to use unsafeTake,Drop (in groupBy) Thu May 18 09:24:25 EST 2006 Duncan Coutts * More effecient findIndexOrEnd based on the impl of findIndex Thu May 18 09:22:49 EST 2006 Duncan Coutts * Eliminate special case in findIndex since it's handled anyway. Thu May 18 09:19:08 EST 2006 Duncan Coutts * Add unsafeTake and unsafeDrop These versions assume the n is in the bounds of the bytestring, saving two comparison tests. Then use them in varous places where we think this holds. These cases need double checking (and there are a few remaining internal uses of take / drop that might be possible to convert). Not exported for the moment. Tue May 16 23:15:11 EST 2006 Don Stewart * Handle n < 0 in drop and splitAt. Spotted by QC. Tue May 16 22:46:22 EST 2006 Don Stewart * Handle n <= 0 cases for unfoldr and replicate. Spotted by QC Tue May 16 21:34:11 EST 2006 Don Stewart * mapF -> map', filterF -> filter' ] [haddock fix Ross Paterson **20060518154723] [simplify indexing in Data.Sequence Ross Paterson **20060518154316] [Move Eq, Ord, Show instances for ThreadId to GHC.Conc Simon Marlow **20060518113339 Eliminates orphans. ] [Better error handling in the IO manager thread Simon Marlow **20060518113303 In particular, handle EBADF just like rts/posix/Select.c, by waking up all the waiting threads. Other errors are thrown, instead of just being ignored. ] [#define _REENTRANT 1 (needed to get the right errno on some OSs) Simon Marlow **20060518104151 Part 2 of the fix for threaded RTS problems on Solaris and possibly *BSD (Part 1 was the same change in ghc/includes/Rts.h). ] [copyCString* should be in IO. Spotted by Tomasz Zielonka Don Stewart **20060518012154] [add import Prelude to get dependencies right for Data/Fixed.hs Duncan Coutts **20060517222044 Hopefully this fixes parallel builds. ] [Fix negative index handling in splitAt, replicate and unfoldrN. Move mapF, filterF -> map', filter' while we're here Don Stewart **20060517020150] [Use our own realloc. Thus reduction functions (like filter) allocate on the Haskell heap. Makes around 10% difference. Don Stewart **20060513051736] [Last two CInt fixes for 64 bit, and bracket writeFile while we're here Don Stewart **20060512050750] [Some small optimisations, generalise the type of unfold Don Stewart **20060510043309 Tue May 9 22:36:29 EST 2006 Duncan Coutts * Surely the error function should not be inlined. Tue May 9 22:35:53 EST 2006 Duncan Coutts * Reorder memory writes for better cache locality. Tue May 9 23:28:09 EST 2006 Duncan Coutts * Generalise the type of unfoldrN The type of unfoldrN was overly constrained: unfoldrN :: Int -> (Word8 -> Maybe (Word8, Word8)) -> Word8 -> ByteString if we compare that to unfoldr: unfoldr :: (b -> Maybe (a, b)) -> b -> [a] So we can generalise unfoldrN to this type: unfoldrN :: Int -> (a -> Maybe (Word8, a)) -> a -> ByteString and something similar for the .Char8 version. If people really do want to use it a lot with Word8/Char then perhaps we should add a specialise pragma. Wed May 10 13:26:40 EST 2006 Don Stewart * Add foldl', and thus a fusion rule for length . {map,filter,fold}, that avoids creating an array at all if the end of the pipeline is a 'length' reduction **END OF DESCRIPTION*** Place the long patch description above the ***END OF DESCRIPTION*** marker. The first line of this file will be the patch name. This patch contains the following changes: M ./Data/ByteString.hs -8 +38 M ./Data/ByteString/Char8.hs -6 +12 ] [portable implementation of WordPtr/IntPtr for non-GHC Ross Paterson **20060510001826 plus much tweaking of imports to avoid cycles ] [add WordPtr and IntPtr types to Foreign.Ptr, with associated conversions Simon Marlow **20060509092606 As suggested by John Meacham. I had to move the Show instance for Ptr into GHC.ForeignPtr to avoid recursive dependencies. ] [add CIntPtr, CUIntPtr, CIntMax, CUIntMax types Simon Marlow **20060509092427] [add GHC.Dynamic Simon Marlow **20060509082739] [Two things. #if defined(__GLASGOW_HASKELL__) on INLINE [n] pragmas (for jhc). And careful use of INLINE on words/unwords halves runtime for those functions Don Stewart **20060509023425] [Make length a good consumer simonpj@microsoft**20060508142726 Make length into a good consumer. Fixes Trac bug #707. (Before length simply didn't use foldr.) ] [Trim imports simonpj@microsoft**20060508142557] [Make unsafePerformIO lazy simonpj@microsoft**20060508142507 The stricteness analyser used to have a HACK which ensured that NOINLNE things were not strictness-analysed. The reason was unsafePerformIO. Left to itself, the strictness analyser would discover this strictness for unsafePerformIO: unsafePerformIO: C(U(AV)) But then consider this sub-expression unsafePerformIO (\s -> let r = f x in case writeIORef v r s of (# s1, _ #) -> (# s1, r #) The strictness analyser will now find that r is sure to be eval'd, and may then hoist it out. This makes tests/lib/should_run/memo002 deadlock. Solving this by making all NOINLINE things have no strictness info is overkill. In particular, it's overkill for runST, which is perfectly respectable. Consider f x = runST (return x) This should be strict in x. So the new plan is to define unsafePerformIO using the 'lazy' combinator: unsafePerformIO (IO m) = lazy (case m realWorld# of (# _, r #) -> r) Remember, 'lazy' is a wired-in identity-function Id, of type a->a, which is magically NON-STRICT, and is inlined after strictness analysis. So unsafePerformIO will look non-strict, and that's what we want. ] [Sync with FPS head. Don Stewart **20060508122322 Mon May 8 10:40:14 EST 2006 Don Stewart * Fix all uses for Int that should be CInt or CSize in ffi imports. Spotted by Igloo, dcoutts Mon May 8 16:09:41 EST 2006 Don Stewart * Import nicer loop/loop fusion rule from ghc-ndp Mon May 8 17:36:07 EST 2006 Don Stewart * Fix stack leak in split on > 60M strings Mon May 8 17:50:13 EST 2006 Don Stewart * Try same fix for stack overflow in elemIndices ] [Fix all uses for Int that should be CInt or CSize in ffi imports. Spotted by Duncan and Ian Don Stewart **20060508010311] [Fixed import list syntax Sven Panne **20060507155008] [Faster filterF, filterNotByte dons@cse.unsw.edu.au**20060507042301] [Much faster find, findIndex. Hint from sjanssen dons@cse.unsw.edu.au**20060507033048] [Merge "unrecognized long opt" fix from 6.4.2 Sven Panne **20060506110519] [ dons@cse.unsw.edu.au**20060506061029 Sat May 6 13:01:34 EST 2006 Don Stewart * Do loopU realloc on the Haskell heap. And add a really tough stress test Sat May 6 12:28:58 EST 2006 Don Stewart * Use simple, 3x faster concat. Plus QC properties. Suggested by sjanssen and dcoutts Sat May 6 15:59:31 EST 2006 Don Stewart * dcoutt's packByte bug squashed With inlinePerformIO, ghc head was compiling: packByte 255 `compare` packByte 127 into roughly case mallocByteString 2 of ForeignPtr f internals -> case writeWord8OffAddr# f 0 255 of _ -> case writeWord8OffAddr# f 0 127 of _ -> case eqAddr# f f of False -> case compare (GHC.Prim.plusAddr# f 0) (GHC.Prim.plusAddr# f 0) which is rather stunning. unsafePerformIO seems to prevent whatever magic inlining was leading to this. Only affected the head. ] [Add array fusion versions of map, filter and foldl dons@cse.unsw.edu.au**20060505060858 This patch adds fusable map, filter and foldl, using the array fusion code for unlifted, flat arrays, from the Data Parallel Haskell branch, after kind help from Roman Leshchinskiy, Pipelines of maps, filters and folds should now need to walk the bytestring once only, and intermediate bytestrings won't be constructed. ] [fix for non-GHC Ross Paterson **20060504093044] [use bracket in appendFile (like writeFile) Ross Paterson **20060504091528] [writeFile: close the file on error Simon Marlow **20060504084505 Suggested by Ross Paterson, via Neil Mitchell ] [Sync with FPS head dons@cse.unsw.edu.au**20060503105259 This patch brings Data.ByteString into sync with the FPS head. The most significant of which is the new Haskell counting sort. Changes: Sun Apr 30 18:16:29 EST 2006 sjanssen@cse.unl.edu * Fix foldr1 in Data.ByteString and Data.ByteString.Char8 Mon May 1 11:51:16 EST 2006 Don Stewart * Add group and groupBy. Suggested by conversation between sjanssen and petekaz on #haskell Mon May 1 16:42:04 EST 2006 sjanssen@cse.unl.edu * Fix groupBy to match Data.List.groupBy. Wed May 3 15:01:07 EST 2006 sjanssen@cse.unl.edu * Migrate to counting sort. Data.ByteString.sort used C's qsort(), which is O(n log n). The new algorithm is O(n), and is faster for strings larger than approximately thirty bytes. We also reduce our dependency on cbits! ] [improve performance of Integer->String conversion Simon Marlow **20060503113306 See http://www.haskell.org//pipermail/libraries/2006-April/005227.html Submitted by: bertram.felgenhauer@googlemail.com ] [inline withMVar, modifyMVar, modifyMVar_ Simon Marlow **20060503111152] [Fix string truncating in hGetLine -- it was a pasto from Simon's code Simon Marlow **20060503103504 (from Don Stewart) ] [Merge in Data.ByteString head. Fixes ByteString+cbits in hugs Don Stewart **20060429040733] [Import Data.ByteString from fps 0.5. Don Stewart **20060428130718 Fast, packed byte vectors, providing a better PackedString. ] [fix previous patch Ross Paterson **20060501154847] [fixes for non-GHC Ross Paterson **20060501144322] [fix imports for mingw32 && !GHC Ross Paterson **20060427163248] [RequireOrder: do not collect unrecognised options after a non-opt Simon Marlow **20060426121110 The documentation for RequireOrder says "no option processing after first non-option", so it doesn't seem right that we should process the rest of the arguments to collect the unrecognised ones. Presumably the client wants to know about the unrecognised options up to the first non-option, and will be using a different option parser for the rest of the command line. eg. before: Prelude System.Console.GetOpt> getOpt' RequireOrder [] ["bar","--foo"] ([],["bar","--foo"],["--foo"],[]) after: Prelude System.Console.GetOpt> getOpt' RequireOrder [] ["bar","--foo"] ([],["bar","--foo"],[],[]) ] [fix for Haddock 0.7 Ashley Yakeley **20060426072521] [add Data.Fixed module Ashley Yakeley **20060425071853] [add instances Ross Paterson **20060424102146] [add superclasses to Applicative and Traversable Ross Paterson **20060411144734 Functor is now a superclass of Applicative, and Functor and Foldable are now superclasses of Traversable. The new hierarchy makes clear the inclusions between the classes, but means more work in defining instances. Default definitions are provided to help. ] [add Functor and Monad instances for Prelude types Ross Paterson **20060410111443] [GHC.Base.breakpoint Lemmih **20060407125827] [Track the GHC source tree reorganisation Simon Marlow **20060407041631] [in the show instance for Exception, print the type of dynamic exceptions Simon Marlow **20060406112444 Unfortunately this requires some recursve module hackery to get at the show instance for Typeable. ] [implement ForeignEnvPtr, newForeignPtrEnv, addForeignPtrEnv for GHC Simon Marlow **20060405155448] [add forkOnIO :: Int -> IO () -> IO ThreadId Simon Marlow **20060327135018] [Rework previous: not a gcc bug after all Simon Marlow **20060323161229 It turns out that we were relying on behaviour that is undefined in C, and undefined behaviour in C means "the compiler can do whatever the hell it likes with your entire program". So avoid that. ] [work around a gcc 4.1.0 codegen bug in -O2 by forcing -O1 for GHC.Show Simon Marlow **20060323134514 See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26824 ] [commit mysteriously missing parts of "runIOFastExit" patch Simon Marlow **20060321101535] [add runIOFastExit :: IO a -> IO a Simon Marlow **20060320124333 Similar to runIO, but calls stg_exit() directly to exit, rather than shutdownHaskellAndExit(). Needed for running GHCi in the test suite. ] [Fix a broken invariant Simon Marlow **20060316134151 Patch from #694, for the problem "empty is an identity for <> and $$" is currently broken by eg. isEmpty (empty<>empty)" ] [Add unsafeSTToIO :: ST s a -> IO a Simon Marlow **20060315160232 Implementation for Hugs is missing, but should be easy. We need this for the forthcoming nested data parallelism implementation. ] [Added 'alter' jeanphilippe.bernardy@gmail.com**20060315143539 Added 'alter :: (Maybe a -> Maybe a) -> k -> Map k a -> Map k a' to IntMap and Map This addresses ticket #665 ] [deprecate FunctorM in favour of Foldable and Traversable Ross Paterson **20060315092942 as discussed on the libraries list. ] [Simplify Eq, Ord, and Show instances for UArray Simon Marlow **20060313142701 The Eq, Ord, and Show instances of UArray were written out longhand with one instance per element type. It is possible to condense these into a single instance for each class, at the expense of using more extensions (non-std context on instance declaration). Suggestion by: Frederik Eaton ] [Oops typo in intSet notMember jeanphilippe.bernardy@gmail.com**20060311224713] [IntMap lookup now returns monad instead of Maybe. jeanphilippe.bernardy@gmail.com**20060311224502] [Added notMember to Data.IntSet and Data.IntMap jeanphilippe.bernardy@gmail.com**20060311085221] [add Data.Set.notMember and Data.Map.notMember John Meacham **20060309191806] [addToClockTime: handle picoseconds properly Simon Marlow **20060310114532 fixes #588 ] [make head/build rule apply to all types, not just Bool. John Meacham **20060303045753] [Avoid overflow when normalising clock times Ian Lynagh **20060210144638] [Years have 365 days, not 30*365 Ian Lynagh **20060210142853] [declare blkcmp() static Simon Marlow **20060223134317] [typo in comment in Foldable class Ross Paterson **20060209004901] [simplify fmap Ross Paterson **20060206095048] [update ref in comment Ross Paterson **20060206095139] [Give -foverlapping-instances to Data.Typeable simonpj@microsoft**20060206133439 For some time, GHC has made -fallow-overlapping-instances "sticky": any instance in a module compiled with -fallow-overlapping-instances can overlap when imported, regardless of whether the importing module allows overlap. (If there is an overlap, both instances must come from modules thus compiled.) Instances in Data.Typeable might well want to be overlapped, so this commit adds the flag to Data.Typeable (with an explanatory comment) ] [Add -fno-bang-patterns to modules using both bang and glasgow-exts simonpj@microsoft.com**20060203175759] [When splitting a bucket, keep the contents in the same order Simon Marlow **20060201130427 To retain the property that multiple inserts shadow each other (see ticket #661, test hash001) ] [add foldr/build optimisation for take and replicate Simon Marlow **20060126164603 This allows take to be deforested, and improves performance of replicate and replicateM/replicateM_. We have a separate problem that means expressions involving [n..m] aren't being completely optimised because eftIntFB isn't being inlined but otherwise the results look good. Sadly this has invalidated a number of the nofib benchmarks which were erroneously using take to duplicate work in a misguided attempt to lengthen their runtimes (ToDo). ] [Generate PrimopWrappers.hs with Haddock docs Simon Marlow **20060124131121 Patch originally from Dinko Tenev , modified to add log message by me. ] [[project @ 2006-01-19 14:47:15 by ross] ross**20060119144715 backport warning avoidance from Haddock ] [[project @ 2006-01-18 11:45:47 by malcolm] malcolm**20060118114547 Fix import of Ix for nhc98. ] [[project @ 2006-01-17 09:38:38 by ross] ross**20060117093838 add Ix instance for GeneralCategory. ] [TAG Initial conversion from CVS complete John Goerzen **20060112154126] Patch bundle hash: 90e9c9a32c1e54a0a84e99bacd19707f1d87e177 From ndmitchell at gmail.com Wed Feb 13 17:36:48 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Feb 13 17:35:22 2008 Subject: Proposal: Add System.Exit.exitSuccess :: IO a In-Reply-To: <20080213223110.GG3264@scytale.galois.com> References: <20080213223110.GG3264@scytale.galois.com> Message-ID: <404396ef0802131436w50990116q111a598d527a85b5@mail.gmail.com> Hi On Feb 13, 2008 10:31 PM, Don Stewart wrote: > For symmetry with exitFailure :: IO a. Should be pretty uncontroversial. > > Patch attached. Consideration period: 2 weeks, or until there's no > traffic on the subject for a week. (+1) - will be really useful. Thanks Neil From john at repetae.net Wed Feb 13 22:46:31 2008 From: john at repetae.net (John Meacham) Date: Wed Feb 13 22:45:05 2008 Subject: Pretty class as alternative for Show class In-Reply-To: <47B2F831.707@dfki.de> References: <20080213080135.GA9671@sliver.repetae.net> <47B2F831.707@dfki.de> Message-ID: <20080214034631.GE9671@sliver.repetae.net> On Wed, Feb 13, 2008 at 03:01:21PM +0100, Christian Maeder wrote: > John Meacham wrote: > > See my 'Doc' project. which includes both a show alternative class like > > you describe as > > well as a class abstracting different pretty printers. > > > > http://repetae.net/repos/Doc > > Why should I use your DocLike module (instead of > Text.PrettyPrint.HughesPJ directly)? Because then the same code will work with any of the pretty printers out there, Strings, and ShowS directly. It is an abstract type. I also have ones that spit out html and one that spits out ascii text along with a function that goes from screen position to what was used to create it so you can find out what people clicked a mouse on. > > from module DocLike: > > x <+> y = x <> char ' ' <> y > x <$> y = x <> char '\n' <> y > encloseSep l r s ds = enclose l r (hcat $ punctuate s ds) > enclose l r x = l <> x <> r > list = encloseSep lbracket rbracket comma > tupled = encloseSep lparen rparen comma > semiBraces = encloseSep lbrace rbrace semi > > 1. The indentation is wrong for Doc from your module Pretty (and strings): > > *Pretty> text "a" DocLike.<+> (text "b" DocLike.<$> text "c") :: Doc > a b > c > > 2. encloseSep may produce too long lines without breaks > > The HughesPJ output is correct: > > *DocLike> P.text "a" <+> (P.text "b" <$> P.text "c") > a b > c This is simply due to the underlying implementation you are using, there are many instances, you should get exactly the same results as you do with HughesPJ if you use the HughesPJ instance as it is what is used to do the formatting. It is possible however that I did not override all the needed methods for the HughesPJ instance as I more often use a modified version of Daan's parser that can handle things like html and ansi color codes so might not have noticed if I forgot one. those are only default implementations, suitable for things like 'String' or 'ShowS', it is expected instances that use a real back end would override them with more interesting things. John -- John Meacham - ?repetae.net?john? From Christian.Maeder at dfki.de Thu Feb 14 03:41:27 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Feb 14 03:40:20 2008 Subject: Labelled graphs in fgl In-Reply-To: References: <6FFC9311-57E7-475F-A3EE-194F31A2A74D@eecs.oregonstate.edu> Message-ID: <47B3FEB7.40508@dfki.de> Henning Thielemann wrote: > Is there a reason why graphs in fgl are labeled by default, and unlabelled > graphs must be constructed by labeling with () ? In my opinion the more > natural design would be to number the nodes and edges with an Enum type > instead of Int and to retrieve the labels from an array. This would > support the "from simple to complex" design. The design of the fgl could be improved. Labels for nodes (only) are (also) supported by Data.Graph.Inductive.NodeMap. (Keeping just a list of edges makes it difficult - leaves it to the user - to find certain edges after insertions or deletions) Sometimes the "from simple to complex"-design contradicts the possibility of reuse by generalizations, though. Cheers Christian From Christian.Maeder at dfki.de Thu Feb 14 03:56:15 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Feb 14 03:54:50 2008 Subject: Pretty class as alternative for Show class In-Reply-To: <20080214034631.GE9671@sliver.repetae.net> References: <20080213080135.GA9671@sliver.repetae.net> <47B2F831.707@dfki.de> <20080214034631.GE9671@sliver.repetae.net> Message-ID: <47B4022F.5000401@dfki.de> John Meacham wrote: >> The HughesPJ output is correct: >> >> *DocLike> P.text "a" <+> (P.text "b" <$> P.text "c") >> a b >> c Could Daan's parser (that I only looked at) create such "correct" output, too? > I more often use a > modified version of Daan's parser that can handle things like html and > ansi color codes so might not have noticed if I forgot one. I would like to combine the advantages of HughesPJ (above) and Daan's parser (including soft breaks). Cheers Christian From Christian.Maeder at dfki.de Thu Feb 14 04:17:53 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Feb 14 04:17:23 2008 Subject: Pretty class as alternative for Show class In-Reply-To: <20080214034631.GE9671@sliver.repetae.net> References: <20080213080135.GA9671@sliver.repetae.net> <47B2F831.707@dfki.de> <20080214034631.GE9671@sliver.repetae.net> Message-ID: <47B40741.5090909@dfki.de> John Meacham wrote: > Because then the same code will work with any of the pretty printers out > there, Strings, and ShowS directly. It is an abstract type. I also have > ones that spit out html and one that spits out ascii text along with a > function that goes from screen position to what was used to create it so > you can find out what people clicked a mouse on. Browsers break html-code for you, but the most important part (namely to compose vertically if horizontally does not fit into the width) is missing from your DocLike class. (Producing strings is no problem for any pretty printer library.) Christian From lemming at henning-thielemann.de Thu Feb 14 04:29:57 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Feb 14 04:28:30 2008 Subject: Labelled graphs in fgl In-Reply-To: <47B3FEB7.40508@dfki.de> References: <6FFC9311-57E7-475F-A3EE-194F31A2A74D@eecs.oregonstate.edu> <47B3FEB7.40508@dfki.de> Message-ID: On Thu, 14 Feb 2008, Christian Maeder wrote: > Henning Thielemann wrote: > > Is there a reason why graphs in fgl are labeled by default, and unlabelled > > graphs must be constructed by labeling with () ? In my opinion the more > > natural design would be to number the nodes and edges with an Enum type > > instead of Int and to retrieve the labels from an array. This would > > support the "from simple to complex" design. > > The design of the fgl could be improved. Labels for nodes (only) are > (also) supported by Data.Graph.Inductive.NodeMap. I was not aware of NodeMap so far. It seems to add a mapping from labels to nodes, whereas node labels (that is mappings from Node to a Label of arbitrary type) are already provided by the Data.Graph.Inductive.Graph.Graph type constructor class and the type concrete Data.Graph.Inductive.Tree.Gr type constructor. A graph type is 'gr a b', but 'a' is not an index type. The nodes are indexed by Node which is a synonym for Int. For the tasks I had so far there was no need for the label type 'a', I just needed a more specific index type than Node (=Int), say an enumeration. The library designer seems to appreciate that applications may not need the labels, and provided functions like mkUGraph and type synonyms like Data.Graph.Inductive.Tree.UGr = Gr () (), which seems for me the wrong way around. It would be simple to add labels to an arbitrary indexed but unlabeled graph, say Ix i => gr i. > (Keeping just a list of edges makes it difficult - leaves it to the user > - to find certain edges after insertions or deletions) From Christian.Maeder at dfki.de Thu Feb 14 05:13:35 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Feb 14 05:12:09 2008 Subject: Labelled graphs in fgl In-Reply-To: References: <6FFC9311-57E7-475F-A3EE-194F31A2A74D@eecs.oregonstate.edu> <47B3FEB7.40508@dfki.de> Message-ID: <47B4144F.6010206@dfki.de> Henning Thielemann wrote: > 'gr a b', but 'a' is not an index type. The nodes are indexed by Node > which is a synonym for Int. For the tasks I had so far there was no need > for the label type 'a', I just needed a more specific index type than Node > (=Int), say an enumeration. > The library designer seems to appreciate that applications may not need > the labels, and provided functions like mkUGraph and type synonyms like > Data.Graph.Inductive.Tree.UGr = Gr () (), which seems for me the wrong way > around. It would be simple to add labels to an arbitrary indexed but > unlabeled graph, say Ix i => gr i. I agree that Ix (or only Ord) may be desirable as node types, but still some applications may need more sophisticated labels or may want to change the labels associated to nodes. For these cases I don't see how you get rid of specializations to "()" without duplicating the library. Christian From lemming at henning-thielemann.de Thu Feb 14 05:32:16 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Feb 14 05:30:50 2008 Subject: Labeled graphs in fgl In-Reply-To: <47B4144F.6010206@dfki.de> References: <6FFC9311-57E7-475F-A3EE-194F31A2A74D@eecs.oregonstate.edu> <47B3FEB7.40508@dfki.de> <47B4144F.6010206@dfki.de> Message-ID: On Thu, 14 Feb 2008, Christian Maeder wrote: > Henning Thielemann wrote: > > 'gr a b', but 'a' is not an index type. The nodes are indexed by Node > > which is a synonym for Int. For the tasks I had so far there was no need > > for the label type 'a', I just needed a more specific index type than Node > > (=Int), say an enumeration. > > The library designer seems to appreciate that applications may not need > > the labels, and provided functions like mkUGraph and type synonyms like > > Data.Graph.Inductive.Tree.UGr = Gr () (), which seems for me the wrong way > > around. It would be simple to add labels to an arbitrary indexed but > > unlabeled graph, say Ix i => gr i. > > I agree that Ix (or only Ord) may be desirable as node types, but still > some applications may need more sophisticated labels > or may want to change the labels associated to nodes. No problem. If the node labels are in a separate array you can even do in-place updates in ST monad. > For these cases I don't see how you get rid of specializations to "()" > without duplicating the library. The library could provide a record like LabeledGraph i nodeLabel edgeLabel = LG (Gr i) (Array i nodeLabel) (Map (i,i) edgeLabel) with the interface that is now used for (Graph gr). However, I suspect that finding the label for an edge is then less efficient then now. From duncan.coutts at worc.ox.ac.uk Thu Feb 14 05:54:37 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Feb 14 05:54:25 2008 Subject: Proposal: add new forms of unsafePerformIO and unsafeInterleaveIO Message-ID: <1202986477.21103.223.camel@localhost> This proposal is to add two new variations on unsafePerformIO and one new form of unsafeInterleaveIO to the System.IO.Unsafe module in the base library (which already exports unsafePerformIO and unsafeInterleaveIO). The additions are documented and portable to non-ghc. Summary and documentation below, see patch attached to the ticket for code details. http://hackage.haskell.org/trac/ghc/ticket/2095 Suggested timescale: ~2 weeks, ends Friday 29th February Summary * unsafeDupablePerformIO and unsafeDupableInterleaveIO When GHC added SMP support the previous unsafePerform/InterleaveIO got renamed to these two functions and new unsafePerform/InterleaveIO functions were added that provide protection against duplication in a multi-threaded context. This protection comes at some cost so there are cases where it is ok to uses these weaker forms if duplicating the IO action is safe. These are already defined and documented in GHC.IOBase, this patch just exports them. * unsafeInlinePerformIO This is an even less safe form of unsafePerformIO. It is used in the Data.ByteString implementation and is very occasionally needed in other projects. If it is needed it is better that it be supplied in a portable form from a standard module with a sensible name and with full documentation. Haddock Documentation This version of 'unsafePerformIO' is slightly more efficient, because it omits the check that the IO is only being performed by a single thread. Hence, when you write 'unsafeDupablePerformIO', there is a possibility that the IO action may be performed multiple times (on a multiprocessor), and you should therefore ensure that it gives the same results each time. unsafeDupablePerformIO :: IO a -> a TODO: Actually, unsafeDupableInterleaveIO is not yet documented, that will have to be fixed. unsafeDupableInterleaveIO :: IO a -> IO a This variant of 'unsafePerformIO' is quite /mind-bogglingly unsafe/. It unstitches the dependency chain that holds the IO monad together and breaks all your ordinary intuitions about IO, sequencing and side effects. Avoid it unless you really know what you are doing. It is only safe for operations which are genuinely pure (not just externally pure) for example reading from an immutable foreign data structure. In particular, you should do no memory allocation inside an 'unsafeInlinePerformIO' block. This is because an allocation is a constant and is likely to be floated out and shared. More generally, any part of any IO action that does not depend on a function argument is likely to be floated to the top level and have its result shared. It is more efficient because in addition to the checks that 'unsafeDupablePerformIO' omits, we also inline. Additionally we do not pretend that the body is lazy which allows the strictness analyser to see the strictness in the body. In turn this allows some re-ordering of operations and any corresponding side-effects. With GHC it compiles to essentially no code and it exposes the body to further inlining. unsafeInlinePerformIO :: IO a -> a From gale at sefer.org Thu Feb 14 06:11:45 2008 From: gale at sefer.org (Yitzchak Gale) Date: Thu Feb 14 06:10:17 2008 Subject: Proposal: add new forms of unsafePerformIO and unsafeInterleaveIO In-Reply-To: <1202986477.21103.223.camel@localhost> References: <1202986477.21103.223.camel@localhost> Message-ID: <2608b8a80802140311i5db1ab01l72a9f03c95a7e2c6@mail.gmail.com> Duncan Coutts wrote: > The additions are documented and portable to non-ghc. This sounds like a worthy addition to the library. The documentation for unsafeInlinePerformIO is a description of how it behaves in GHC. Can you describe the semantics in a compiler-independent way? Thanks, Yitz From apfelmus at quantentunnel.de Thu Feb 14 06:53:19 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Thu Feb 14 06:52:02 2008 Subject: Data.Ord and Heaps In-Reply-To: <20080211100642.GA24057@soi.city.ac.uk> References: <288B9431-ADC3-46D3-97F4-6A219388E015@quantentunnel.de> <47A7005C.8030404@tu-bs.de> <20080211100642.GA24057@soi.city.ac.uk> Message-ID: <47B42BAF.8060907@quantentunnel.de> Ross Paterson wrote: > Stephan Friedrichs wrote: >> apfelmus wrote: >>> [newtype Ord a => Reverse a = Reverse { unReverse :: a }] >>> >>> Yes. I mean "non-standard" in the software-reuse sense, i.e. Ord is for >>> user-defined orderings and should be the only such mechanism in order >>> to enable reuse. In fact, Data.Heap clearly shows that Data.Ord is >>> currently missing functionality. >> Ah, now I see. The entire ordering policy mechanism - no matter how it >> is going to be solved - belongs into Data.Ord and not in Data.Heap. As >> soon as Data.Ord provides a solution, I'll use it in Data.Heap. > > Unfortunately the Data.Ord module is constrained to use only Haskell > 98 features, because it is used by all implementations. So it could > include the above Reverse (also mentioned in the group-by HW paper), > but not the various OrdPolicy proposals. The advantage of policies is that the Heap interface is implemented exactly once. Using Reverse is no problem, but you'd have to implement one normal version (MinHeap a) and one boilerplate version (MinHeap (Reverse a)). Implementing Heap p a for both p = Identity and p = Reverse at once can eliminate this boilerplate. Fortunately, the "polymorphic policies" Identity and Reverse can be implemented in Haskell98! data OrdBy p a = OrdBy { unOrdBy :: a } class OrdPolicy p where compare' :: Ord a => OrdBy p a -> OrdBy p a -> Ordering instance (Ord a, OrdPolicy p) => Ord (OrdBy p a) where compare = compare' class Heap h where empty :: Ord a => h a insert :: Ord a => a -> h a -> h a viewHead :: Ord a => h a -> Maybe (a, h a) data HeapP p a = ... -- MinHeap (OrdBy p a) instance OrdPolicy p => Heap (HeapP p) where ... What probably can't be done in Haskell98 are policies p that only work for specific types, i.e. such that OrdBy p a is not always an instance of Ord . Of course, there is the question whether they are needed or whether they are just overengineering. I hope that Stephan Friedrichs has a compelling example for the former? :) That being said, I think there might be a Haskell98 way to implement even them. The trick here is that while class contexts like Ord (OrdBy p a) are not H98, contexts like Ord (p a) with type variables only are. class Identity f where to :: a -> f a from :: f a -> a -- subject to to . from = id and from . to = id -- the latter holds automatically thanks to parametricity data Heap p a = ... -- MinHeap (p a) empty :: (Identity p, Ord (p a)) => Heap p a insert :: (Identity p, Ord (p a)) => a -> Heap p a -> Heap p a viewHead :: (Identity p, Ord (p a)) => Heap p a -> Maybe (a, Heap p a) In other words, the context (Identity p, Ord (p a)) expresses what a multi-parameter type class OrdPolicy p a would do, too. I wonder whether this trick can be used to encode arbitrary multi-parameter type classes in plain Haskell98. I guess not, because interestingly, Ord (p a) is not a valid context for class or instance declarations, it's only ok for function definitions. So, defining stuff like instance Show (p a) => Show (Heap p a) where ... is not possible, which limits this approach somewhat. Another limit of non-polymorphic policies is that the Heap class would have to be multi-parameter (which it should be anyway of course, but that's not H98). Regards, apfelmus From Christian.Maeder at dfki.de Thu Feb 14 06:58:10 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Feb 14 06:56:44 2008 Subject: Labeled graphs in fgl In-Reply-To: References: <6FFC9311-57E7-475F-A3EE-194F31A2A74D@eecs.oregonstate.edu> <47B3FEB7.40508@dfki.de> <47B4144F.6010206@dfki.de> Message-ID: <47B42CD2.6030104@dfki.de> Henning Thielemann wrote: > The library could provide a record like > > LabeledGraph i nodeLabel edgeLabel = > LG (Gr i) (Array i nodeLabel) (Map (i,i) edgeLabel) > > with the interface that is now used for (Graph gr). > However, I suspect that finding the label for an edge is then less > efficient then now. Interesting, the nodeLabel bit looks good (although I would use a "Map i nodeLabel"). Considering that "Gr i" is also implemented as something like "Map i " the structure is already duplicated, although keeping the separate node labels in sync is fairly easy and maybe the price for the added value (namely node labels). In particular during decomposing the graph the node-label-map does not need to be changed (although lookups may be faster in smaller maps). W.r.t edge labels more needs to be done: 1. there may be several edges between a node pair 2. Getting a whole context (all in- and outgoing labelled edges) of a node is less efficient (as you said above) 3. Some identity of edges (i.e. a unique number, apart from the label) is desirable, to locate or (re-)insert/delete certain edges. W.r.t to the fgl-Design I would more complain about the many type synonyms for tuples instead of using new (algebraic data) types. Also wrapper types are an idea to keep the general implementation but present a simplified interface to users of unlabeled graphs. Cheers Christian From ndmitchell at gmail.com Thu Feb 14 08:41:31 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Feb 14 08:40:03 2008 Subject: Proposal: add new forms of unsafePerformIO and unsafeInterleaveIO In-Reply-To: <2608b8a80802140311i5db1ab01l72a9f03c95a7e2c6@mail.gmail.com> References: <1202986477.21103.223.camel@localhost> <2608b8a80802140311i5db1ab01l72a9f03c95a7e2c6@mail.gmail.com> Message-ID: <404396ef0802140541h7d192d19i98aebf5b90f4594f@mail.gmail.com> Hi (+1). I need this in Supero and Uniplate, its essential. > The documentation for unsafeInlinePerformIO is a > description of how it behaves in GHC. Can you > describe the semantics in a compiler-independent > way? We don't want to describe the semantics, we probably want to describe the minimum preconditions and postconditions. The GHC description serves as a nice basis for that - since all other compilers probably provide more guarantees. Thanks Neil From rl at cse.unsw.edu.au Thu Feb 14 10:06:36 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Thu Feb 14 10:05:14 2008 Subject: Proposal: add new forms of unsafePerformIO and unsafeInterleaveIO In-Reply-To: <2608b8a80802140311i5db1ab01l72a9f03c95a7e2c6@mail.gmail.com> References: <1202986477.21103.223.camel@localhost> <2608b8a80802140311i5db1ab01l72a9f03c95a7e2c6@mail.gmail.com> Message-ID: <47B458FC.7040602@cse.unsw.edu.au> Yitzchak Gale wrote: > > The documentation for unsafeInlinePerformIO is a > description of how it behaves in GHC. Can you > describe the semantics in a compiler-independent > way? Also, the name isn't very intuitive. Something like unsafePerformPureIO would be better. Other than that, yes please :) Roman From droundy at darcs.net Thu Feb 14 14:16:29 2008 From: droundy at darcs.net (David Roundy) Date: Thu Feb 14 14:15:01 2008 Subject: Proposal: add new forms of unsafePerformIO and unsafeInterleaveIO In-Reply-To: <2608b8a80802140311i5db1ab01l72a9f03c95a7e2c6@mail.gmail.com> References: <1202986477.21103.223.camel@localhost> <2608b8a80802140311i5db1ab01l72a9f03c95a7e2c6@mail.gmail.com> Message-ID: <20080214191628.GM17316@darcs.net> On Thu, Feb 14, 2008 at 01:11:45PM +0200, Yitzchak Gale wrote: > Duncan Coutts wrote: > > The additions are documented and portable to non-ghc. > > This sounds like a worthy addition to the library. I agree. -- David Roundy Department of Physics Oregon State University From john at repetae.net Thu Feb 14 15:00:55 2008 From: john at repetae.net (John Meacham) Date: Thu Feb 14 14:59:25 2008 Subject: Proposal: add new forms of unsafePerformIO and unsafeInterleaveIO In-Reply-To: <1202986477.21103.223.camel@localhost> References: <1202986477.21103.223.camel@localhost> Message-ID: <20080214200055.GB11884@sliver.repetae.net> I mildly prefer 'Idempotent' to 'Dupable'. feels more descriptive to me. This is even useful in jhc without threading, as expressions can be marked 'idempotent and cheap' giving the compiler freedom to duplicate them when it makes sense. However, I am worried about the 'Inline' in the other one, in jhc, unsafePerformIO is always inlined, it uses a different trick (my 'dependingOn' primitive) to ensure the world is not unified with another one. Can we come up with a term that describes the difference other than 'inline' as that is a ghc specific quirk. incidentally, jhc has another form of unsafePerformIO that does not wrap its argument in a new exception handler. It can be used when you know the argument won't raise an ioError or if it does, it handles them itself. (normal calls to things like error and pattern match failures are fine. it is just haskell98 io errors that metter for this one) John -- John Meacham - ?repetae.net?john? From john at repetae.net Thu Feb 14 15:21:12 2008 From: john at repetae.net (John Meacham) Date: Thu Feb 14 15:19:43 2008 Subject: Proposal: Add Text.Read.maybeRead :: Read a => String -> Maybe a In-Reply-To: <47ACBD16.9010408@gmail.com> References: <20080208171120.GA27582@scytale.galois.com> <49a77b7a0802081226vdec9db5jc21ef24fff7a5804@mail.gmail.com> <47ACBD16.9010408@gmail.com> Message-ID: <20080214202112.GC11884@sliver.repetae.net> On Fri, Feb 08, 2008 at 09:35:34PM +0100, Twan van Laarhoven wrote: > David Menendez wrote: >>> Isn't the MonadPlus approach also by-default-safe? >> >> Safe, yes, but is it more useful? > > Yes. In this case, take a parsing monad for example. You could write: > > parseInt :: CharParser () Int > parseInt = do ds <- many digit > readM ds > > And it would work automatically. A reading error would be propagated to the > parser monad, and it would backtrack/report the error/whatever. Yes. this is exactly the sort of thing I use this for. (I have had readM in my standard toolkit for a while). John -- John Meacham - ?repetae.net?john? From john at repetae.net Thu Feb 14 15:29:28 2008 From: john at repetae.net (John Meacham) Date: Thu Feb 14 15:27:58 2008 Subject: Pretty class as alternative for Show class In-Reply-To: <47B4022F.5000401@dfki.de> References: <20080213080135.GA9671@sliver.repetae.net> <47B2F831.707@dfki.de> <20080214034631.GE9671@sliver.repetae.net> <47B4022F.5000401@dfki.de> Message-ID: <20080214202927.GD11884@sliver.repetae.net> On Thu, Feb 14, 2008 at 09:56:15AM +0100, Christian Maeder wrote: > John Meacham wrote: > >> The HughesPJ output is correct: > >> > >> *DocLike> P.text "a" <+> (P.text "b" <$> P.text "c") > >> a b > >> c > > Could Daan's parser (that I only looked at) create such "correct" > output, too? I believe so, I generally use daan's because I find it easier to create good layout in and i think it is strictly more powerful. I didn't try to hard to match up the operators exactly between the two instances but I probably should, as I didn't use the hughespj one much. it is likely I can get them to produce the same results with some tweaking and I might want to add a couple more forms of line break into the class. here is a link to his paper on his pretty printer http://citeseer.ist.psu.edu/480959.html -- John Meacham - ?repetae.net?john? From stefanor at cox.net Thu Feb 14 17:18:09 2008 From: stefanor at cox.net (Stefan O'Rear) Date: Thu Feb 14 17:16:42 2008 Subject: Proposal: add new forms of unsafePerformIO and unsafeInterleaveIO In-Reply-To: <1202986477.21103.223.camel@localhost> References: <1202986477.21103.223.camel@localhost> Message-ID: <20080214221809.GA4080@localhost.localdomain> On Thu, Feb 14, 2008 at 10:54:37AM +0000, Duncan Coutts wrote: > This version of 'unsafePerformIO' is slightly more efficient, because it > omits the check that the IO is only being performed by a single thread. > Hence, when you write 'unsafeDupablePerformIO', there is a possibility > that the IO action may be performed multiple times (on a > multiprocessor), and you should therefore ensure that it gives the same > results each time. > > unsafeDupablePerformIO :: IO a -> a > > TODO: Actually, unsafeDupableInterleaveIO is not yet documented, > that will have to be fixed. > > unsafeDupableInterleaveIO :: IO a -> IO a I propose that unsafeDupablePerformIO be renamed to unsafePerformIO, since it satisfies all of the properties guaranteed of unsafePerformIO. GHC's unsafePerformIO guarantees more, and should be called unsafePerformIOAtMostOnce or something. Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/libraries/attachments/20080214/753920d6/attachment.bin From isaacdupree at charter.net Thu Feb 14 21:59:22 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Thu Feb 14 21:57:54 2008 Subject: Proposal: add new forms of unsafePerformIO and unsafeInterleaveIO In-Reply-To: <20080214221809.GA4080@localhost.localdomain> References: <1202986477.21103.223.camel@localhost> <20080214221809.GA4080@localhost.localdomain> Message-ID: <47B5000A.8000404@charter.net> Stefan O'Rear wrote: > I propose that unsafeDupablePerformIO be renamed to unsafePerformIO, > since it satisfies all of the properties guaranteed of unsafePerformIO. > GHC's unsafePerformIO guarantees more similar to 'let' denoting sharing normally, and not doing a computation more than needed (most of the time). hmm. From cgibbard at gmail.com Thu Feb 14 22:15:12 2008 From: cgibbard at gmail.com (Cale Gibbard) Date: Thu Feb 14 22:13:43 2008 Subject: select and selectSplit Message-ID: <89ca3d1f0802141915y2390a5e7pb53da4c2a796f74a@mail.gmail.com> I know Bulat will be terribly disappointed by my suggestion to make an addition to Data.List ;) but I mentioned the following couple of functions on #haskell and got some positive response that they were things other people ended up writing all the time as well, so I decided I'd propose them here as additions to Data.List and see what kind of reaction I got: -- | The 'select' function takes a list and produces a list of pairs -- consisting of an element of the list together with a list of the -- remaining elements. select :: [a] -> [(a,[a])] select [] = [] select (x:xs) = (x,xs) : [(y,x:ys) | (y,ys) <- select xs] -- | The 'selectSplit' function takes a list and produces a list of -- triples consisting of a prefix of the list, the element after it, -- and the remainder of the list. selectSplit :: [a] -> [([a],a,[a])] selectSplit [] = [] selectSplit (x:xs) = ([],x,xs) : [(x:lys,y,rys) | (lys,y,rys) <- selectSplit xs] These tend to be very handy in the list monad. The names are off the top of my head. Logan Capaldo also suggested 'pick' for the first, which is a name that I've used as well. Faxathisia mentioned that it's called 'select' in Prolog as well. As a side note, the state transformer makes it relatively easy to pick n elements using this: pick n = runStateT . replicateM n . StateT $ select (Showing that select is secretly an operation in a state transformed list monad, where the state is a list of elements.) If the order of the pairs in the MTL is fixed in the future in order to better reflect the available instances of Functor/etc., at that point we may want to consider flipping the pairs in the result of select to match. - Cale From ndmitchell at gmail.com Fri Feb 15 05:02:18 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri Feb 15 05:00:46 2008 Subject: select and selectSplit In-Reply-To: <89ca3d1f0802141915y2390a5e7pb53da4c2a796f74a@mail.gmail.com> References: <89ca3d1f0802141915y2390a5e7pb53da4c2a796f74a@mail.gmail.com> Message-ID: <404396ef0802150202w6aecd787ja94996396132cc5c@mail.gmail.com> Hi > select :: [a] -> [(a,[a])] > selectSplit :: [a] -> [([a],a,[a])] Not entirely certain about the names, but the functions are good. Perhaps the reason I am dubious is the select/poll conventions. Is there not some word in combinatorics for extracting any single element out of a set? It sounds like Maths should have beaten us to this naming, as it typically does for Data.List. I have selectSplit defined in a few of my projects, and have called it "allItems" on at least one occasion - which is an even worse name. (+0.8) as it currently stands, but (+1) if it gets a better (more Mathsy) name. I don't support the flipping of the select arguments, ever, as currently it returns a very logical pair of ("this item","everything else") - flipping the order goes against the intution of the order of cons. Thanks Neil From wnoise at ofb.net Fri Feb 15 05:14:33 2008 From: wnoise at ofb.net (Aaron Denney) Date: Fri Feb 15 05:13:20 2008 Subject: select and selectSplit References: <89ca3d1f0802141915y2390a5e7pb53da4c2a796f74a@mail.gmail.com> Message-ID: On 2008-02-15, Cale Gibbard wrote: > -- | The 'select' function takes a list and produces a list of pairs > -- consisting of an element of the list together with a list of the > -- remaining elements. > select :: [a] -> [(a,[a])] > select [] = [] > select (x:xs) = (x,xs) : [(y,x:ys) | (y,ys) <- select xs] A couple tounge-in-cheek suggestions: "banishments" -- all possible ways a society can divide itself up into one banished person, and the rest of society. Or perhaps "hermits". > -- | The 'selectSplit' function takes a list and produces a list of > -- triples consisting of a prefix of the list, the element after it, > -- and the remainder of the list. > selectSplit :: [a] -> [([a],a,[a])] > selectSplit [] = [] > selectSplit (x:xs) = ([],x,xs) : [(x:lys,y,rys) | (lys,y,rys) <- selectSplit xs] I kind of want to call this "positionalPivots", because of the "pivoting element" used in dividing everything up into elements less than, and greater than a particular one. This is all possible choices, but it's using positional order, not comparison order to do this partioning. But I actually don't really see much utility in either of these. Do you have some examples of use, and how they're a commonly abstracted pattern that deserves using up namespace because of the utility of a common vocabulary? -- Aaron Denney -><- From conor at strictlypositive.org Fri Feb 15 05:47:50 2008 From: conor at strictlypositive.org (Conor McBride) Date: Fri Feb 15 05:45:48 2008 Subject: select and selectSplit In-Reply-To: <89ca3d1f0802141915y2390a5e7pb53da4c2a796f74a@mail.gmail.com> References: <89ca3d1f0802141915y2390a5e7pb53da4c2a796f74a@mail.gmail.com> Message-ID: <426D5CB8-16C8-4E07-82A7-2BB9C0FA996F@strictlypositive.org> Hi [statutory math warning: calculus, comonads] > On 15 Feb 2008, at 03:15, Cale Gibbard wrote: >> I know Bulat will be terribly disappointed by my suggestion to >> make an >> addition to Data.List ;) but I mentioned the following couple of >> functions on #haskell and got some positive response that they were >> things other people ended up writing all the time as well, so I >> decided I'd propose them here as additions to Data.List and see what >> kind of reaction I got: >> These selectors ring a bell with me. In Nottingham, Morningside, and a few other places, they're known as instances of "Hancock's cursor down operator" as documented here: http://sneezy.cs.nott.ac.uk/containers/blog/?p=20 More Haskellily than that blog article, the general form is (more or less, and therein lies another story...) down :: Deriv f f' => f x -> f (x, f' x) where Deriv is the usual differential operator calculating from a container its type of one-hole contexts. The effect of down is to decorate each x-element of an (f x)-structure with its own context, thus calculating the collection of ways in which one can visit an element, zipper style. The name makes sense in the context where you're navigating some tree structure given by the fixpoint of f, but "select" is probably a less loaded choice. This generalisation may be too far away from what looks like (and is) a handy pair of list functions, so I wouldn't blame anyone from adding them to the library largely as is. I just thought I'd mention the wedge of which they are the thin end. Second things first: > -- | The 'selectSplit' function takes a list and produces a list of > -- triples consisting of a prefix of the list, the element after it, > -- and the remainder of the list. > selectSplit :: [a] -> [([a],a,[a])] > selectSplit [] = [] > selectSplit (x:xs) = ([],x,xs) : [(x:lys,y,rys) | (lys,y,rys) <- > selectSplit xs] This guy corresponds to instance Deriv [] (Prod [] []) where newtype Prod f g x = Prod (f x, g x) That is, a one-hole context in a list is a pair of lists---the elements before the hole, the elements after the hole. > -- | The 'select' function takes a list and produces a list of pairs > -- consisting of an element of the list together with a list of the > -- remaining elements. > select :: [a] -> [(a,[a])] > select [] = [] > select (x:xs) = (x,xs) : [(y,x:ys) | (y,ys) <- select xs] This one, as confirmed by its example usage > As a side note, the state transformer makes it relatively easy to pick > n elements using this: > pick n = runStateT . replicateM n . StateT $ select is somehow seeing lists as *bags*, ie, finite multisets, or lists under arbitrary permutation. newtype Bag x = Bag [x] The power series expansion of Bag is an old pal: Bag x = 1 + x + x^2/2! + x^3/3! + ... representing the choice of an n-tuple, but not distingushing the n! ways in which it can be ordered. Correspondingly instance Deriv Bag Bag a one-hole context in a jumbled collection of elements is a jumbled collection of the remaining elements. > If the order of the pairs in the MTL is fixed in the future in order > to better reflect the available instances of Functor/etc., at that > point we may want to consider flipping the pairs in the result of > select to match. It's tempting to suggest something like data Deriv f f' => Selection f f' x = x :@ f' x and then select :: Deriv f f' => f x -> f (Selection f f' x) but it may be too grotty for normal use. My motivation is to get my hands on the fact that Deriv f f' => Comonad (Selection f f') where the comonad operations make sense like this: counit :: Selection f f' x -> x returns the selected element cojoin :: Selection f f' x -> Selection f f' (Selection f f' x) decorates each element in the selection with the context in which *it* would be selected, showing you your possible sideways moves (including staying put, ie, decorating the selected element with its existing context). So, the original plug :: Selection f f' x -> f x is "up", cojoin is "sideways" and select is "down". Er, um, applications of these things? I have some. You can find one in a draft I must get around to putting words in: http://strictlypositive.org/Holes.pdf http://strictlypositive.org/Holes.lhs It's a bit enigmatic at the moment, but basically Lucas Dixon suggested to me that (as people who do a lot of substitution) we might benefit from making it quicker to jump over large closed chunks of terms: from the root of a term, he wanted, in constant time to get one of: (0) a guarantee the term is closed (1) the position of its only variable (2) the node where paths to at least two variables diverge The derivative allows us to build a representation of terms where the root is connected to other interesting points by "tubes": lists of one-hole contexts through closed stuff. The compression algorithm which makes an ordinary term into a tube network makes key usage of Hancock's "down" operator: we're looking for the "all subterms closed but one" pattern, so we want to search the possible decompositions of each node. Perhaps "differentiate" is the right name? Oops. I seem to have got a bit carried away. Apologies Conor From haskell at list.mightyreason.com Fri Feb 15 06:15:56 2008 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Fri Feb 15 06:14:35 2008 Subject: select and selectSplit In-Reply-To: References: <89ca3d1f0802141915y2390a5e7pb53da4c2a796f74a@mail.gmail.com> Message-ID: <47B5746C.3060406@list.mightyreason.com> Aaron Denney wrote: > But I actually don't really see much utility in either of these. > Do you have some examples of use, and how they're a commonly abstracted > pattern that deserves using up namespace because of the utility of a > common vocabulary? > As mentioned in another reply, the select treats the source list like an unordered (perhaps multi) set. I was using something quite similar in a scrabble dictionary lookup to get all the ways to 'select' a tile from the current hand, returning [ (Tile,Remaining Hand)]. From waldmann at imn.htwk-leipzig.de Fri Feb 15 06:44:21 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Fri Feb 15 06:42:51 2008 Subject: select and selectSplit In-Reply-To: <47B5746C.3060406@list.mightyreason.com> References: <89ca3d1f0802141915y2390a5e7pb53da4c2a796f74a@mail.gmail.com> <47B5746C.3060406@list.mightyreason.com> Message-ID: <47B57B15.1050804@imn.htwk-leipzig.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Kuklewicz wrote: > As mentioned in another reply, the select treats the source list like an > unordered (perhaps multi) set. See - the proposed function is in the "wrong" module; it uses a concrete data type (List) which normally represents an abstract Sequence type but here some abstract data type (Bag) is intended. (my "favourite Haskell code smell": list obsession :-) Why then, are there so many of these functions? My theory is - because "lists are there" (since LISP) and there is (in Haskell) no agreement on those abstract types, and in fact implementations (Data.Set) change rather frequently, so programmers are hesitant to commit to them. But of course we'd only need an agreement on interfaces, then you'd not commit to one implementation. Again, Java did this right, they have interfaces for Set, Map. They even treat List as interface. Sure, they had fewer design choices as their type system has less freedom, just some special form of one-parameter type classes. But then, their syntax encourages the use of interface types - they are as easy to write as a class type. I'm not actually advocating to introduce more syntactic sugar to Haskell (for existential types), I think proper (refactoring) tool support would help a great deal already. Best regards, Johannes. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHtXsV3ZnXZuOVyMIRAkl2AJ9CIxJoWM7d3UIl0s79E9d480dLVwCfeR0X gGdkZc/ioA80rwcTbTL8Pds= =X/pa -----END PGP SIGNATURE----- From haskell at list.mightyreason.com Fri Feb 15 07:07:21 2008 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Fri Feb 15 07:05:51 2008 Subject: select and selectSplit In-Reply-To: <47B57B15.1050804@imn.htwk-leipzig.de> References: <89ca3d1f0802141915y2390a5e7pb53da4c2a796f74a@mail.gmail.com> <47B5746C.3060406@list.mightyreason.com> <47B57B15.1050804@imn.htwk-leipzig.de> Message-ID: <47B58079.8060606@list.mightyreason.com> Johannes Waldmann wrote: > Chris Kuklewicz wrote: > >> As mentioned in another reply, the select treats the source list like an >> unordered (perhaps multi) set. > > See - the proposed function is in the "wrong" module; > it uses a concrete data type (List) > which normally represents an abstract Sequence type > but here some abstract data type (Bag) is intended. > (my "favourite Haskell code smell": list obsession :-) > > Why then, are there so many of these functions? Lists are the right thing for any small collection (scrabble hands only have 7 tiles at most). Sorted lists make great implementations of sets if you do not need the O(log n) member testing: union, intersection, difference are all trivial in O(n+m) time (and even findMin/deleteMin,minView; use Data.Seq instead of Data.List if you also need *max*). A list of [(item,count)] is then great model of multisets; this is what my scrabble program uses. I never need member testing -- I do need the 'select' operation, which got called pullTile in my code. Data.Set|Map would have been O(log 7) instead of O(7) in building the "remaining hand", but this savings is swamped by the constant factor when n=7. > My theory is - because "lists are there" (since LISP) > and there is (in Haskell) no agreement on those abstract types, > and in fact implementations (Data.Set) change rather frequently, > so programmers are hesitant to commit to them. > > But of course we'd only need an agreement on interfaces, > then you'd not commit to one implementation. Again, Java did this right, > they have interfaces for Set, Map. They even treat List as interface. There are several third party libraries (e.g. Edison) that provide such for Haskell. > Sure, they had fewer design choices as their type system has less freedom, > just some special form of one-parameter type classes. The original collections were one-parameter type classes that stored "Object". Java then had to reinvent Collections using generics. And these are NOT simply one-parameter type classes. The first type parameter is always the first argument "this" in Java, which is the collection type (e.g. HashSet). The second type parameter is the type of the item being stored and retrieved (which acts sort-of-like a newtype--the storage is the same as "Object" to be compatible with old libraries). > But then, their syntax encourages the use of interface types - > they are as easy to write as a class type. Haskell needs MultiParamterTypeClasses to do a great job with a collections interface (type of collection and type of item). This is not Haskell98. These need FunctionalDependencies to be convenient -- which were never fully and happily embraced, even as an extensions. The Associated* extensions which are not yet stable will hopefully solve this. > > I'm not actually advocating to introduce more syntactic sugar > to Haskell (for existential types), I think proper (refactoring) > tool support would help a great deal already. > > Best regards, Johannes. From conor at strictlypositive.org Fri Feb 15 07:32:55 2008 From: conor at strictlypositive.org (Conor McBride) Date: Fri Feb 15 07:30:56 2008 Subject: select and selectSplit In-Reply-To: <47B58079.8060606@list.mightyreason.com> References: <89ca3d1f0802141915y2390a5e7pb53da4c2a796f74a@mail.gmail.com> <47B5746C.3060406@list.mightyreason.com> <47B57B15.1050804@imn.htwk-leipzig.de> <47B58079.8060606@list.mightyreason.com> Message-ID: Hi On 15 Feb 2008, at 12:07, Chris Kuklewicz wrote: > Johannes Waldmann wrote: >> Chris Kuklewicz wrote: >>> As mentioned in another reply, the select treats the source list >>> like an >>> unordered (perhaps multi) set. >> See - the proposed function is in the "wrong" module; >> it uses a concrete data type (List) >> which normally represents an abstract Sequence type >> but here some abstract data type (Bag) is intended. [..] > Lists are the right thing for any small collection (scrabble hands > only have 7 tiles at most). I'm inclined to agree with you if by "thing" you mean "representation", but disagree if by "thing" you mean "type". If lists are being used to represent finite multisets, it's probably a good thing to pack them in a newtype, whether or not it's being treated as an abstract datatype. We should use types as signs of structure, not just as descriptions of data layout. For example, we should expect to have instance Eq x => Eq (Bag x) but not with the same semantics as equality on lists. What morals one can afford in terms of enforcing representation hiding is a trickier question, but it is at least relatively cheap to make type distinctions which are healthily suggestive. All the best Conor From lemming at henning-thielemann.de Fri Feb 15 07:53:50 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Feb 15 07:52:38 2008 Subject: select and selectSplit In-Reply-To: <89ca3d1f0802141915y2390a5e7pb53da4c2a796f74a@mail.gmail.com> References: <89ca3d1f0802141915y2390a5e7pb53da4c2a796f74a@mail.gmail.com> Message-ID: On Thu, 14 Feb 2008, Cale Gibbard wrote: > I know Bulat will be terribly disappointed by my suggestion to make an > addition to Data.List ;) but I mentioned the following couple of > functions on #haskell and got some positive response that they were > things other people ended up writing all the time as well, so I > decided I'd propose them here as additions to Data.List and see what > kind of reaction I got: > > -- | The 'select' function takes a list and produces a list of pairs > -- consisting of an element of the list together with a list of the > -- remaining elements. > select :: [a] -> [(a,[a])] > select [] = [] > select (x:xs) = (x,xs) : [(y,x:ys) | (y,ys) <- select xs] > > -- | The 'selectSplit' function takes a list and produces a list of > -- triples consisting of a prefix of the list, the element after it, > -- and the remainder of the list. > selectSplit :: [a] -> [([a],a,[a])] > selectSplit [] = [] > selectSplit (x:xs) = ([],x,xs) : [(x:lys,y,rys) | (lys,y,rys) <- selectSplit xs] I use these functions regularly, too. select c = init $ zipWith (\xs (y:ys) -> (y, xs++ys)) (List.inits c) (List.tails c) From cgibbard at gmail.com Fri Feb 15 08:11:53 2008 From: cgibbard at gmail.com (Cale Gibbard) Date: Fri Feb 15 08:10:21 2008 Subject: select and selectSplit In-Reply-To: <47B57B15.1050804@imn.htwk-leipzig.de> References: <89ca3d1f0802141915y2390a5e7pb53da4c2a796f74a@mail.gmail.com> <47B5746C.3060406@list.mightyreason.com> <47B57B15.1050804@imn.htwk-leipzig.de> Message-ID: <89ca3d1f0802150511jeca2d85j25713d1aa633a87c@mail.gmail.com> On 15/02/2008, Johannes Waldmann wrote: > See - the proposed function is in the "wrong" module; > it uses a concrete data type (List) > which normally represents an abstract Sequence type > but here some abstract data type (Bag) is intended. > (my "favourite Haskell code smell": list obsession :-) > > Why then, are there so many of these functions? Lists are our loops. It has nothing to do with an aversion to using other sequence types. Lists reify linear recursion directly. So the real question I suppose is why loops are so popular. - Cale From jed at 59A2.org Fri Feb 15 11:20:35 2008 From: jed at 59A2.org (Jed Brown) Date: Fri Feb 15 11:18:12 2008 Subject: Storable instance for Complex Message-ID: <87ve4qxkbw.fsf@59A2.org> I propose that the following instance be added to base: instance (RealFloat a, Storable a) => Storable (Complex a) where sizeOf z = 2 * sizeOf (realPart z) alignment z = sizeOf (realPart z) peek p = do [r,i] <- peekArray 2 (castPtr p) return (r :+ i) poke p (r :+ i) = pokeArray (castPtr p) [r,i] This instance is binary compatible with C99, C++ and Fortran complex types. It is currently needed by at least two independent packages: hmatrix and fft. Since it is natural for user code to use both of these packages, we need to move the instance to a common location. http://hackage.haskell.org/trac/ghc/ticket/2099 Jed -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20080215/85b5b543/attachment.bin From lemming at henning-thielemann.de Fri Feb 15 11:29:05 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Feb 15 11:27:40 2008 Subject: Storable instance for Complex In-Reply-To: <87ve4qxkbw.fsf@59A2.org> References: <87ve4qxkbw.fsf@59A2.org> Message-ID: On Fri, 15 Feb 2008, Jed Brown wrote: > I propose that the following instance be added to base: > > instance (RealFloat a, Storable a) => Storable (Complex a) where > sizeOf z = 2 * sizeOf (realPart z) > alignment z = sizeOf (realPart z) > peek p = do > [r,i] <- peekArray 2 (castPtr p) > return (r :+ i) > poke p (r :+ i) = pokeArray (castPtr p) [r,i] > > This instance is binary compatible with C99, C++ and Fortran complex types. > > It is currently needed by at least two independent packages: hmatrix and > fft. Since it is natural for user code to use both of these packages, we > need to move the instance to a common location. > > http://hackage.haskell.org/trac/ghc/ticket/2099 I also need it for signal processing. From wnoise at ofb.net Fri Feb 15 16:34:28 2008 From: wnoise at ofb.net (Aaron Denney) Date: Fri Feb 15 16:33:09 2008 Subject: Storable instance for Complex References: <87ve4qxkbw.fsf@59A2.org> Message-ID: On 2008-02-15, Jed Brown wrote: > I propose that the following instance be added to base: > > instance (RealFloat a, Storable a) =3D> Storable (Complex a) where > sizeOf z =3D 2 * sizeOf (realPart z) > alignment z =3D sizeOf (realPart z) > peek p =3D do > [r,i] <- peekArray 2 (castPtr p) > return (r :+ i) > poke p (r :+ i) =3D pokeArray (castPtr p) [r,i] I've been using a slightly different instance: instance (RealFloat a, Storable a) => Storable (Complex a) where sizeOf x = 2 * sizeOf (f x) alignment x = alignment (f x) poke x (a :+ b) = do let y = castPtr x poke y a pokeElemOff y 1 b peek x = do let y = castPtr x a <- peek y b <- peekElemOff y 1 return (a :+ b) f :: Complex a -> a f _ = undefined With a small constant number of elements, I think it makes more sense to just store them explicitly rather than through a list. I didn't even think of using realPart, but it makes sense. -- Aaron Denney -><- From roconnor at theorem.ca Fri Feb 15 16:36:25 2008 From: roconnor at theorem.ca (roconnor@theorem.ca) Date: Fri Feb 15 16:34:53 2008 Subject: [GHC] #974: Add unzipEithers, lefts, rights to Data.Either In-Reply-To: <053.59bba6fc96d56b1d4eb049045eb70a87@localhost> References: <044.771c90fc72736a1914b3f63a62b98bc6@localhost> <053.59bba6fc96d56b1d4eb049045eb70a87@localhost> Message-ID: On Fri, 15 Feb 2008, GHC wrote: > Comment (by igloo): > > Having reread the thread, I think we are here: > > We are agreed that we should add > {{{ > lefts :: [Either a b] -> [a] > rights :: [Either a b] -> [b] > }}} > and that we should add a function with type > {{{ > [Either a b] -> ([a],[b]) > }}} > Possible names include > {{{ > splitEithers > unzipEithers > partitionEithers > catEithers > leftRights > leftsAndRights > boths > demuxEithers > }}} > While choosing a name, we should bear in mind that we might want to define > a function with type > {{{ > (a -> Either b c) -> [a] -> ([b],[c]) > }}} > at some point in the future. I am reopening discussion of this trac. Here are mine (and some others) comments on the possible names: splitEithers - reject because the result of split should be such that the concatination of the resulting two lists should be (isomorphic) to the original list. unzipEithers - reject because unzip should have the same length as the original lists. Also unzipEithers suggests there is a zipEithers somewhere. catEithers - reject because this isn't a concatination. leftRights, leftAndRights, boths - reject because they are mnenomic enough. demux, demuxEithers - these are less popular options. demux is too general, but may make for an intersting class definition somewhere. partitionEithers - This is (I believe) the most popular (or least controversial) name. The output of our function has similar properties to the output of partition. The only objection possible objection is that partitionEithers perhaps should have type (a -> Either b c) -> [a] -> ([b],[c]), ie. partitonEithers should take a function as a parameter. The response to this objection by saying that the extra `Eithers' in the name fills the place of the predicate/function. Also the function of type (a -> Either b c) -> [a] -> ([b],[c]) is less widely used that the function we are trying to name in this trac. -- Russell O'Connor ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.'' From isaacdupree at charter.net Fri Feb 15 17:11:55 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Fri Feb 15 17:10:21 2008 Subject: select and selectSplit In-Reply-To: References: <89ca3d1f0802141915y2390a5e7pb53da4c2a796f74a@mail.gmail.com> Message-ID: <47B60E2B.5090204@charter.net> Aaron Denney wrote: > On 2008-02-15, Cale Gibbard wrote: >> -- | The 'select' function takes a list and produces a list of pairs >> -- consisting of an element of the list together with a list of the >> -- remaining elements. >> select :: [a] -> [(a,[a])] >> select [] = [] >> select (x:xs) = (x,xs) : [(y,x:ys) | (y,ys) <- select xs] > > A couple tounge-in-cheek suggestions: > > "banishments" -- all possible ways a society can divide itself up into > one banished person, and the rest of society. thank you for that name!!! It finally helped me figure out what the function was supposed to do. now, documentation that included examples would be nearly as good... select [1,2,3,4] = [(1,[2,3,4]), (2,[1,3,4]), (3,[1,2,4]), (4,[1,2,3])] --right? or we could call it "howToAbductEachElement" ;-) but that belongs in the Haskell list library even less than "banishments" From jed at 59A2.org Fri Feb 15 17:28:51 2008 From: jed at 59A2.org (Jed Brown) Date: Fri Feb 15 17:26:21 2008 Subject: Storable instance for Complex In-Reply-To: (Aaron Denney's message of "Fri, 15 Feb 2008 21:34:28 +0000 (UTC)") References: <87ve4qxkbw.fsf@59A2.org> Message-ID: <874pc9yhuk.fsf@59A2.org> On 15 Feb 2008, wnoise@ofb.net wrote: > On 2008-02-15, Jed Brown wrote: > > I propose that the following instance be added to base: > > > > instance (RealFloat a, Storable a) =3D> Storable (Complex a) where > > sizeOf z =3D 2 * sizeOf (realPart z) > > alignment z =3D sizeOf (realPart z) > > peek p =3D do > > [r,i] <- peekArray 2 (castPtr p) > > return (r :+ i) > > poke p (r :+ i) =3D pokeArray (castPtr p) [r,i] > > I've been using a slightly different instance: > > instance (RealFloat a, Storable a) => Storable (Complex a) where > sizeOf x = 2 * sizeOf (f x) > alignment x = alignment (f x) > poke x (a :+ b) = do let y = castPtr x > poke y a > pokeElemOff y 1 b > peek x = do let y = castPtr x > a <- peek y > b <- peekElemOff y 1 > return (a :+ b) > > f :: Complex a -> a > f _ = undefined > > With a small constant number of elements, I think it makes more sense to > just store them explicitly rather than through a list. I don't really care how it is written. I suspect these generate exactly the same code. The important thing is that an instance with this binary representation is put in one place since the current state prevents certain packages from being used together. Jed -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20080215/52932a1c/attachment.bin From conor at strictlypositive.org Fri Feb 15 17:30:01 2008 From: conor at strictlypositive.org (Conor McBride) Date: Fri Feb 15 17:28:34 2008 Subject: [GHC] #974: Add unzipEithers, lefts, rights to Data.Either In-Reply-To: References: <044.771c90fc72736a1914b3f63a62b98bc6@localhost> <053.59bba6fc96d56b1d4eb049045eb70a87@localhost> Message-ID: <6BD64F92-B975-4EC5-8795-513A8ACE238E@strictlypositive.org> Hi Russell On 15 Feb 2008, at 21:36, roconnor@theorem.ca wrote: > On Fri, 15 Feb 2008, GHC wrote: > >> Comment (by igloo): >> >> Having reread the thread, I think we are here: >> >> We are agreed that we should add >> {{{ >> lefts :: [Either a b] -> [a] >> rights :: [Either a b] -> [b] >> }}} >> and that we should add a function with type >> {{{ >> [Either a b] -> ([a],[b]) >> }}} Any chance of left-factoring foldMap from the above? It's funny: what's important about the [] on the left is that it's Foldable; what's important about the [] on the right is that it's Alternative. What's both? More than one candidate, but [] is a runaway winner perhaps. Curious stuff. What if we had left :: Either a b -> Maybe a right :: Either a b -> Maybe b may :: Alternative f => Maybe a -> f a and suitable other bits and pieces? I fear that foldMap ((may . left) &&& (may . right)) is a longer name than you were hoping for, but it says what it does on the tin. Cheers Conor From ross at soi.city.ac.uk Fri Feb 15 19:38:21 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Fri Feb 15 19:37:05 2008 Subject: Proposal: Add Text.Read.maybeRead :: Read a => String -> Maybe a In-Reply-To: <47ACBD16.9010408@gmail.com> References: <20080208171120.GA27582@scytale.galois.com> <49a77b7a0802081226vdec9db5jc21ef24fff7a5804@mail.gmail.com> <47ACBD16.9010408@gmail.com> Message-ID: <20080216003821.GA18265@soi.city.ac.uk> On Fri, Feb 08, 2008 at 09:35:34PM +0100, Twan van Laarhoven wrote: > David Menendez wrote: >>> Isn't the MonadPlus approach also by-default-safe? >> >> Safe, yes, but is it more useful? > > Yes. In this case, take a parsing monad for example. You could write: > > parseInt :: CharParser () Int > parseInt = do ds <- many digit > readM ds > > And it would work automatically. A reading error would be propagated to > the parser monad, and it would backtrack/report the error/whatever. In this example a read error indicates a bug, which you'd want to treat differently from a syntax error in the input. If one were using read as part of the parsing process, one could give better messages with something like parseInt :: CharParser () Int parseInt = do ds <- many alphaNum fromMaybe (fail "integer expected") $ maybeRead ds From ndmitchell at gmail.com Sat Feb 16 06:50:11 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sat Feb 16 06:48:37 2008 Subject: select and selectSplit In-Reply-To: <47B60E2B.5090204@charter.net> References: <89ca3d1f0802141915y2390a5e7pb53da4c2a796f74a@mail.gmail.com> <47B60E2B.5090204@charter.net> Message-ID: <404396ef0802160350o51e63f45if55b24ee9723d731@mail.gmail.com> Hi > now, documentation that included examples would be nearly as good... > select [1,2,3,4] = [(1,[2,3,4]), (2,[1,3,4]), (3,[1,2,4]), (4,[1,2,3])] For list examples, its often clearer to use type Char select "1234" = [('1',"234"), ... Thanks Neil From alcremi at pobox.com Sat Feb 16 18:13:18 2008 From: alcremi at pobox.com (Alain Cremieux) Date: Sat Feb 16 18:12:28 2008 Subject: [Alex] Feature request: Create a customizable state monad AlexState Message-ID: <47B76E0E.8060400@pobox.com> Hi, In Alex, very often I need to include elements in the basic monad of the wrapper ALEX_MONAD. For instance if I want to record the level of a comment, or a list of the comments. Several years ago I hacked the file wrapper.hs to include my own elements, by defining another entry point: #ifdef ALEX_MONAD data AlexState = AlexState { alex_pos :: !AlexPosn, -- position at current input location alex_inp :: String, -- the current input alex_chr :: !Char, -- the character before the input alex_scd :: !Int -- the current startcode */#ifdef ALEX_MONAD_USER_STATE , alex_ust :: AlexUserState -- defined in the user program #endif /* } and runAlex :: String -> Alex a -> Either String a runAlex input (Alex f) = case f (AlexState {alex_pos = alexStartPos, alex_inp = input, alex_chr = '\n', */#ifdef ALEX_MONAD_USER_STATE alex_ust = alexInitUserState, #endif /* alex_scd = 0}) of Left msg -> Left msg Right ( _, a ) -> Right a This way I can define my own elements, and initialize them. Now I'd like to have this change integrated in the development tree. Has anyone another idea as how to obtain the same result (knowing that now there are 2 variants, whith normal chars and with bytestrings) ? How would other Alex users do that ? Thanks, Alain From jed at 59A2.org Sun Feb 17 10:14:22 2008 From: jed at 59A2.org (Jed Brown) Date: Sun Feb 17 10:11:46 2008 Subject: Storable instance for Complex In-Reply-To: (Henning Thielemann's message of "Fri, 15 Feb 2008 17:29:05 +0100 (MET)") References: <87ve4qxkbw.fsf@59A2.org> Message-ID: <87k5l3ty29.fsf@59A2.org> On 15 Feb 2008, lemming@henning-thielemann.de wrote: > On Fri, 15 Feb 2008, Jed Brown wrote: >> I propose that the following instance be added to base: >> >> instance (RealFloat a, Storable a) => Storable (Complex a) where >> sizeOf z = 2 * sizeOf (realPart z) >> alignment z = sizeOf (realPart z) >> peek p = do >> [r,i] <- peekArray 2 (castPtr p) >> return (r :+ i) >> poke p (r :+ i) = pokeArray (castPtr p) [r,i] >> >> This instance is binary compatible with C99, C++ and Fortran complex types. >> >> It is currently needed by at least two independent packages: hmatrix and >> fft. Since it is natural for user code to use both of these packages, we >> need to move the instance to a common location. >> >> http://hackage.haskell.org/trac/ghc/ticket/2099 > > I also need it for signal processing. In light of the fact that several packages need this instance, I created a package storable-complex (on Hackage) which has the instance in Foreign.Storable.Complex. In the interest of enabling our packages to play nicely *now*, I would like to encourage everyone needing this instance to get it from this common source. When it (hopefully) makes it into base, we can use a flag in the .cabal file to get it from base instead of this package. Note on style: I decided I agree with Aaron about using explicit peek/poke rather than a list. Thus the instance in storable-complex is written: instance (RealFloat a, Storable a) => Storable (Complex a) where sizeOf z = 2 * sizeOf (realPart z) alignment z = sizeOf (realPart z) peek p = do let q = castPtr p r <- peek q i <- peekElemOff q 1 return (r :+ i) poke p (r :+ i) = do let q = (castPtr p) poke q r pokeElemOff q 1 i Is Storable/Complex really a special case, or are there other cases where equivalent instances are defined in different packages? If so, would a language extension allowing the user (importing the same instance from multiple sources) to specify that the instances are actually identical be helpful? Jed -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20080217/3c1af382/attachment.bin From lemming at henning-thielemann.de Sun Feb 17 15:52:06 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun Feb 17 15:50:31 2008 Subject: Storable instance for Complex In-Reply-To: <87k5l3ty29.fsf@59A2.org> References: <87ve4qxkbw.fsf@59A2.org> <87k5l3ty29.fsf@59A2.org> Message-ID: On Sun, 17 Feb 2008, Jed Brown wrote: > On 15 Feb 2008, lemming@henning-thielemann.de wrote: > > On Fri, 15 Feb 2008, Jed Brown wrote: > >> I propose that the following instance be added to base: > >> > >> instance (RealFloat a, Storable a) => Storable (Complex a) where > >> sizeOf z = 2 * sizeOf (realPart z) > >> alignment z = sizeOf (realPart z) > >> peek p = do > >> [r,i] <- peekArray 2 (castPtr p) > >> return (r :+ i) > >> poke p (r :+ i) = pokeArray (castPtr p) [r,i] > >> > >> This instance is binary compatible with C99, C++ and Fortran complex types. > >> > >> It is currently needed by at least two independent packages: hmatrix and > >> fft. Since it is natural for user code to use both of these packages, we > >> need to move the instance to a common location. > >> > >> http://hackage.haskell.org/trac/ghc/ticket/2099 > > > > I also need it for signal processing. > > In light of the fact that several packages need this instance, I created > a package storable-complex (on Hackage) which has the instance in > Foreign.Storable.Complex. In the interest of enabling our packages to > play nicely *now*, I would like to encourage everyone needing this > instance to get it from this common source. When it (hopefully) makes > it into base, we can use a flag in the .cabal file to get it from base > instead of this package. an instance for pairs would also be nice ... :-) From frederik at a5.repetae.net Sun Feb 17 16:30:01 2008 From: frederik at a5.repetae.net (Frederik Eaton) Date: Sun Feb 17 16:28:24 2008 Subject: sourceforge and HSQL In-Reply-To: References: <20060817001711.GD3356@a5.repetae.net> <20060817004940.GE3356@a5.repetae.net> <20060817211056.GR3356@a5.repetae.net> <44EEC0F7.3010302@cs.chalmers.se> <20070303173504.GA14521@a5.repetae.net> <4606A979.10408@cs.chalmers.se> <20080120044658.GA10424@a5.repetae.net> <4792D69D.7070103@serpentine.com> Message-ID: <20080217213001.GU13696@a5.repetae.net> Hello, I was trying to apply my patches to the HSQL, and I noticed that Bjorn has already applied them (thanks!) in 2006, and they are visible at http://darcs.haskell.org/HSQL/ I even have emails where he tells me that he applied them to CVS, sorry for missing that! However, there is still the problem that new users who search for "HSQL haskell" will find the following sourceforge page much higher in their search results than the darcs.haskell.org URL: http://htoolkit.sourceforge.net/ and they will be directed to download the buggy, two-year-old HSQL-1.7: https://sourceforge.net/project/showfiles.php?group_id=65248 rather than the latest version at http://darcs.haskell.org/HSQL/. I have tried to find out the answers to the following questions from Krasimir and then Duncan, but no response: 1. How do we get rid of the defunct HSQL versions at sourceforge.net? 2. How does one push patches to http://darcs.haskell.org/HSQL/? Who maintains that version? At this point, it seems #1 is more important than #2, since all the patches I care about have been committed to the darcs version and the darcs version compiles with the latest GHC/Cabal... Thanks, Frederik -- http://ofb.net/~frederik/ From duncan.coutts at worc.ox.ac.uk Sun Feb 17 19:10:20 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Feb 17 19:08:42 2008 Subject: sourceforge and HSQL In-Reply-To: <20080217213001.GU13696@a5.repetae.net> References: <20060817001711.GD3356@a5.repetae.net> <20060817004940.GE3356@a5.repetae.net> <20060817211056.GR3356@a5.repetae.net> <44EEC0F7.3010302@cs.chalmers.se> <20070303173504.GA14521@a5.repetae.net> <4606A979.10408@cs.chalmers.se> <20080120044658.GA10424@a5.repetae.net> <4792D69D.7070103@serpentine.com> <20080217213001.GU13696@a5.repetae.net> Message-ID: <1203293420.2102.9.camel@localhost> On Sun, 2008-02-17 at 21:30 +0000, Frederik Eaton wrote: > Hello, > > I was trying to apply my patches to the HSQL, and I noticed that Bjorn > has already applied them (thanks!) in 2006, and they are visible at > > http://darcs.haskell.org/HSQL/ > > I even have emails where he tells me that he applied them to CVS, > sorry for missing that! > > However, there is still the problem that new users who search for > "HSQL haskell" will find the following sourceforge page much higher in > their search results than the darcs.haskell.org URL: > > http://htoolkit.sourceforge.net/ > > and they will be directed to download the buggy, two-year-old > HSQL-1.7: > > https://sourceforge.net/project/showfiles.php?group_id=65248 > > rather than the latest version at http://darcs.haskell.org/HSQL/. > > I have tried to find out the answers to the following questions from > Krasimir and then Duncan, but no response: Yeah, sorry, forgot. > 1. How do we get rid of the defunct HSQL versions at sourceforge.net? You can ask Krasimir to add you as a project admin. This seems the most straightforward option. In the extreme case, SourceForge do have procedures to transfer projects when their maintainers disappear but that does not seem necessary at this stage. > 2. How does one push patches to http://darcs.haskell.org/HSQL/? Who > maintains that version? Have the darcs motd redirect to a new repo on code.haskell.org. You can ask someone to do this for you. So the old one will remain but be clearly marked as defunct. > At this point, it seems #1 is more important than #2, since all the > patches I care about have been committed to the darcs version and the > darcs version compiles with the latest GHC/Cabal... Then all you need is a release on hackage that works :-) Duncan From ashley at semantic.org Mon Feb 18 04:25:47 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Mon Feb 18 04:24:15 2008 Subject: Working with multiple time zones In-Reply-To: <20080217193717.GA3376@scytale.galois.com> References: <61d3022d0802161513v776274c3p4c3f185b8ed61535@mail.gmail.com> <61d3022d0802171110l6a90c92fwace7bd5c6fe9afe6@mail.gmail.com> <20080217193717.GA3376@scytale.galois.com> Message-ID: <47B94F1B.6060908@semantic.org> Don Stewart wrote: > Perhaps we should get a binding to tzset in the unix library? That's probably preferable to calling tzset() before every localtime_r. But perhaps we want a call that combines the putenv and the tzset, just so it exposes fewer implementation details. This is essentially an interface to the zoneinfo database rather than time functionality as such. Ideally there would be a better C interface to zoneinfo that wouldn't involve mucking around with (global) environment variables. -- Ashley Yakeley Seattle, WA From kr.angelov at gmail.com Mon Feb 18 04:28:54 2008 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Mon Feb 18 04:27:16 2008 Subject: sourceforge and HSQL In-Reply-To: <1203293420.2102.9.camel@localhost> References: <20060817001711.GD3356@a5.repetae.net> <20060817211056.GR3356@a5.repetae.net> <44EEC0F7.3010302@cs.chalmers.se> <20070303173504.GA14521@a5.repetae.net> <4606A979.10408@cs.chalmers.se> <20080120044658.GA10424@a5.repetae.net> <4792D69D.7070103@serpentine.com> <20080217213001.GU13696@a5.repetae.net> <1203293420.2102.9.camel@localhost> Message-ID: > > 1. How do we get rid of the defunct HSQL versions at sourceforge.net? > > You can ask Krasimir to add you as a project admin. This seems the most > straightforward option. In the extreme case, SourceForge do have > procedures to transfer projects when their maintainers disappear but > that does not seem necessary at this stage. If you give me Sourceforge account I will add you. > > 2. How does one push patches to http://darcs.haskell.org/HSQL/? Who > > maintains that version? Don't anyone with SSH key have a write permission to the repository? Regards, Krasimir From duncan.coutts at worc.ox.ac.uk Mon Feb 18 04:46:53 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Feb 18 04:45:44 2008 Subject: sourceforge and HSQL In-Reply-To: References: <20060817001711.GD3356@a5.repetae.net> <20060817211056.GR3356@a5.repetae.net> <44EEC0F7.3010302@cs.chalmers.se> <20070303173504.GA14521@a5.repetae.net> <4606A979.10408@cs.chalmers.se> <20080120044658.GA10424@a5.repetae.net> <4792D69D.7070103@serpentine.com> <20080217213001.GU13696@a5.repetae.net> <1203293420.2102.9.camel@localhost> Message-ID: <1203328013.2102.15.camel@localhost> On Mon, 2008-02-18 at 10:28 +0100, Krasimir Angelov wrote: > > > 1. How do we get rid of the defunct HSQL versions at sourceforge.net? > > > > You can ask Krasimir to add you as a project admin. This seems the most > > straightforward option. In the extreme case, SourceForge do have > > procedures to transfer projects when their maintainers disappear but > > that does not seem necessary at this stage. > > If you give me Sourceforge account I will add you. Just to be clear, it's Frederik Eaton who would like to take over maintenance. > > > 2. How does one push patches to http://darcs.haskell.org/HSQL/? Who > > > maintains that version? > > Don't anyone with SSH key have a write permission to the repository? That's true, however new accounts are not being given out so Frederik Eaton would not easily be able to get an account. The obvious choice therefore is to copy the repo to code.haskell.org. Duncan From waldmann at imn.htwk-leipzig.de Mon Feb 18 08:15:15 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Mon Feb 18 08:13:36 2008 Subject: select and selectSplit In-Reply-To: <89ca3d1f0802150511jeca2d85j25713d1aa633a87c@mail.gmail.com> References: <89ca3d1f0802141915y2390a5e7pb53da4c2a796f74a@mail.gmail.com> <47B5746C.3060406@list.mightyreason.com> <47B57B15.1050804@imn.htwk-leipzig.de> <89ca3d1f0802150511jeca2d85j25713d1aa633a87c@mail.gmail.com> Message-ID: <47B984E3.3060303@imn.htwk-leipzig.de> Cale Gibbard wrote: > Lists are our loops. It has nothing to do with an aversion to using > other sequence types. Lists reify linear recursion directly. So the > real question I suppose is why loops are so popular. Well, loops are certainly popular in imperative programming, because there you have only one world, and it goes through a linear sequence of states. But we don't need that in functional programming - and if we're using "State" (or sequencing), then it's perhaps a (premature) optimization (towards the von-Neumann execution model). Anyway, I don't care much about library functions I'm probably not going to use; but maintainability is an issue, and I agree with Bulat there. Best regards, Johannes. From cgibbard at gmail.com Mon Feb 18 11:03:37 2008 From: cgibbard at gmail.com (Cale Gibbard) Date: Mon Feb 18 11:01:57 2008 Subject: select and selectSplit In-Reply-To: <47B984E3.3060303@imn.htwk-leipzig.de> References: <89ca3d1f0802141915y2390a5e7pb53da4c2a796f74a@mail.gmail.com> <47B5746C.3060406@list.mightyreason.com> <47B57B15.1050804@imn.htwk-leipzig.de> <89ca3d1f0802150511jeca2d85j25713d1aa633a87c@mail.gmail.com> <47B984E3.3060303@imn.htwk-leipzig.de> Message-ID: <89ca3d1f0802180803p2c43f132oe7a3a1a7d6b3403e@mail.gmail.com> On 18/02/2008, Johannes Waldmann wrote: > Cale Gibbard wrote: > > > Lists are our loops. It has nothing to do with an aversion to using > > other sequence types. Lists reify linear recursion directly. So the > > real question I suppose is why loops are so popular. > > Well, loops are certainly popular in imperative programming, > because there you have only one world, > and it goes through a linear sequence of states. > > But we don't need that in functional programming - > and if we're using "State" (or sequencing), > then it's perhaps a (premature) optimization > (towards the von-Neumann execution model). I don't see this as the issue. State really has nothing to do with why loops are popular, at least in my mind. They come up a lot because they are the simplest possible kind of recursion, involving only one recursive call. You could think of the parameters to that recursive call as being the state if you like, but that seems artificial to me. From Christian.Maeder at dfki.de Tue Feb 19 05:59:04 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Feb 19 05:57:28 2008 Subject: darcs patch: [PROOF OF CONCEPT] build readline package with libedit In-Reply-To: <200802141927.11489.robdockins@fastmail.fm> References: <6d74b0d20801080838p5763ea07uf1bc8a16e21b6e08@mail.gmail.com> <200801211247.49138.robdockins@fastmail.fm> <6d74b0d20801210945n160870bbp5499e48c0b1115df@mail.gmail.com> <200802141927.11489.robdockins@fastmail.fm> Message-ID: <47BAB678.1030505@dfki.de> Robert Dockins wrote: > I've now built a Shellac-editline package using the bindings from the > editline-0.2. It's on hackage[1]. I've run the package through a quick > sanity check, but I have not extensively tested it. Thanks, I've compiled it and run a short test on an Intel Leopard with success. > [1]http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Shellac-editline-0.9 I wasn't amused to also change my sources to use editlineBackend instead of readlineBackend, besides changing the import to System.Console.Shell.Backend.Editline. Maybe the interfaces of the packages could be identical and one gets a warning when both packages are installed. (I suppose one package must be hidden then, during compilation.) 1. In order to compile under MacOS with editline and under Linux with readline it would be nice to use the same sources. In order to avoid several #ifdefs (maybe differently or suboptimal given) in user sources (to achieve 1.) such #ifdefs (or wrappers) should be part of the libraries (including the documentation for the license differences)! Cheers Christian From lemming at henning-thielemann.de Tue Feb 19 06:01:59 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Feb 19 06:00:15 2008 Subject: darcs patch: [PROOF OF CONCEPT] build readline package with libedit In-Reply-To: <47BAB678.1030505@dfki.de> References: <6d74b0d20801080838p5763ea07uf1bc8a16e21b6e08@mail.gmail.com> <200801211247.49138.robdockins@fastmail.fm> <6d74b0d20801210945n160870bbp5499e48c0b1115df@mail.gmail.com> <200802141927.11489.robdockins@fastmail.fm> <47BAB678.1030505@dfki.de> Message-ID: On Tue, 19 Feb 2008, Christian Maeder wrote: > In order to avoid several #ifdefs (maybe differently or suboptimal > given) in user sources (to achieve 1.) such #ifdefs (or wrappers) > should be part of the libraries (including the documentation for the > license differences)! Can Cabal-1.2's flag capability manage such a task? From duncan.coutts at worc.ox.ac.uk Tue Feb 19 06:31:02 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Feb 19 08:33:47 2008 Subject: darcs patch: [PROOF OF CONCEPT] build readline package with libedit In-Reply-To: References: <6d74b0d20801080838p5763ea07uf1bc8a16e21b6e08@mail.gmail.com> <200801211247.49138.robdockins@fastmail.fm> <6d74b0d20801210945n160870bbp5499e48c0b1115df@mail.gmail.com> <200802141927.11489.robdockins@fastmail.fm> <47BAB678.1030505@dfki.de> Message-ID: <1203420662.2102.55.camel@localhost> On Tue, 2008-02-19 at 12:01 +0100, Henning Thielemann wrote: > On Tue, 19 Feb 2008, Christian Maeder wrote: > > > In order to avoid several #ifdefs (maybe differently or suboptimal > > given) in user sources (to achieve 1.) such #ifdefs (or wrappers) > > should be part of the libraries (including the documentation for the > > license differences)! > > Can Cabal-1.2's flag capability manage such a task? I don't think I understand the problem clearly enough to say. Perhaps someone can try explaining it in more detail. Duncan From nominolo at googlemail.com Tue Feb 19 08:44:28 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Tue Feb 19 08:42:51 2008 Subject: darcs patch: [PROOF OF CONCEPT] build readline package with libedit In-Reply-To: <1203420662.2102.55.camel@localhost> References: <6d74b0d20801080838p5763ea07uf1bc8a16e21b6e08@mail.gmail.com> <200801211247.49138.robdockins@fastmail.fm> <6d74b0d20801210945n160870bbp5499e48c0b1115df@mail.gmail.com> <200802141927.11489.robdockins@fastmail.fm> <47BAB678.1030505@dfki.de> <1203420662.2102.55.camel@localhost> Message-ID: <26B10ABB-D784-4529-8E17-4EFBFF8A968C@googlemail.com> On 19 feb 2008, at 12.31, Duncan Coutts wrote: > > On Tue, 2008-02-19 at 12:01 +0100, Henning Thielemann wrote: >> On Tue, 19 Feb 2008, Christian Maeder wrote: >> >>> In order to avoid several #ifdefs (maybe differently or suboptimal >>> given) in user sources (to achieve 1.) such #ifdefs (or wrappers) >>> should be part of the libraries (including the documentation for the >>> license differences)! >> >> Can Cabal-1.2's flag capability manage such a task? > > I don't think I understand the problem clearly enough to say. Perhaps > someone can try explaining it in more detail. > I don't think Cabal can help easily here since it works on the module level. It also won't rename modules which would be required in this case, I think. / Thomas From lemming at henning-thielemann.de Tue Feb 19 09:10:01 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Feb 19 09:08:17 2008 Subject: darcs patch: [PROOF OF CONCEPT] build readline package with libedit In-Reply-To: <26B10ABB-D784-4529-8E17-4EFBFF8A968C@googlemail.com> References: <6d74b0d20801080838p5763ea07uf1bc8a16e21b6e08@mail.gmail.com> <200801211247.49138.robdockins@fastmail.fm> <6d74b0d20801210945n160870bbp5499e48c0b1115df@mail.gmail.com> <200802141927.11489.robdockins@fastmail.fm> <47BAB678.1030505@dfki.de> <1203420662.2102.55.camel@localhost> <26B10ABB-D784-4529-8E17-4EFBFF8A968C@googlemail.com> Message-ID: On Tue, 19 Feb 2008, Thomas Schilling wrote: > I don't think Cabal can help easily here since it works on the module > level. It also won't rename modules which would be required in this > case, I think. You can separate the differences out in two modules with the same name but different source directories and add a Cabal switch on a flag that chooses between two Hs-Source-Dirs. From Christian.Maeder at dfki.de Tue Feb 19 09:22:34 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Feb 19 09:20:48 2008 Subject: darcs patch: [PROOF OF CONCEPT] build readline package with libedit In-Reply-To: <1203420662.2102.55.camel@localhost> References: <6d74b0d20801080838p5763ea07uf1bc8a16e21b6e08@mail.gmail.com> <200801211247.49138.robdockins@fastmail.fm> <6d74b0d20801210945n160870bbp5499e48c0b1115df@mail.gmail.com> <200802141927.11489.robdockins@fastmail.fm> <47BAB678.1030505@dfki.de> <1203420662.2102.55.camel@localhost> Message-ID: <47BAE62A.7090202@dfki.de> Duncan Coutts wrote: > On Tue, 2008-02-19 at 12:01 +0100, Henning Thielemann wrote: >> On Tue, 19 Feb 2008, Christian Maeder wrote: >> >>> In order to avoid several #ifdefs (maybe differently or suboptimal >>> given) in user sources (to achieve 1.) such #ifdefs (or wrappers) >>> should be part of the libraries (including the documentation for the >>> license differences)! >> Can Cabal-1.2's flag capability manage such a task? > > I don't think I understand the problem clearly enough to say. Perhaps > someone can try explaining it in more detail. Currently, we have packages Shellac-readline and Shellac-editline. with exposed-modules: System.Console.Shell.Backend.Readline resp. exposed-modules: System.Console.Shell.Backend.Editline Each module exports a single constant: Prelude> :browse System.Console.Shell.Backend.Editline editlineBackend :: System.Console.Shell.Backend.ShellBackend () Prelude> :browse System.Console.Shell.Backend.Readline readlineBackend :: System.Console.Shell.Backend.ShellBackend () On Macs I want to use Editline, under Linux Readline, Therefore I #ifdef my sources. (The functionality seems to be the same for both packages) My questions are: 1. Should not the exported constants have the same name 2. Should not even the module name be the same in both packages As long as not both packages are installed the compiler would pick the proper package without my #ifdefs. HTH Christian From ahey at iee.org Tue Feb 19 10:33:02 2008 From: ahey at iee.org (Adrian Hey) Date: Tue Feb 19 10:31:20 2008 Subject: cpuTimePrecision wrong on Windows? Message-ID: <47BAF6AE.2070800@iee.org> Hello folks, One odd thing I noticed is that the cpuTimePrecision on Windows seems to be "hardwired" in the source code to 1000000000. I don't know if this is supposed to be the same on all windows platforms or if it depends on hardware, but it seems to be wrong on my machine. At least getCPUTime always seems to return a multiple of 125000000 (1/8 of cpuTimePrecision). Regards -- Adrian Hey From robdockins at fastmail.fm Tue Feb 19 12:52:09 2008 From: robdockins at fastmail.fm (Robert Dockins) Date: Tue Feb 19 12:50:17 2008 Subject: darcs patch: [PROOF OF CONCEPT] build readline package with libedit In-Reply-To: <47BAE62A.7090202@dfki.de> References: <6d74b0d20801080838p5763ea07uf1bc8a16e21b6e08@mail.gmail.com> <1203420662.2102.55.camel@localhost> <47BAE62A.7090202@dfki.de> Message-ID: <200802191252.09847.robdockins@fastmail.fm> On Tuesday 19 February 2008 09:22:34 am Christian Maeder wrote: > Duncan Coutts wrote: > > On Tue, 2008-02-19 at 12:01 +0100, Henning Thielemann wrote: > >> On Tue, 19 Feb 2008, Christian Maeder wrote: > >>> In order to avoid several #ifdefs (maybe differently or suboptimal > >>> given) in user sources (to achieve 1.) such #ifdefs (or wrappers) > >>> should be part of the libraries (including the documentation for the > >>> license differences)! > >> > >> Can Cabal-1.2's flag capability manage such a task? > > > > I don't think I understand the problem clearly enough to say. Perhaps > > someone can try explaining it in more detail. > > Currently, we have packages Shellac-readline and Shellac-editline. > with > > exposed-modules: System.Console.Shell.Backend.Readline > > resp. > > exposed-modules: System.Console.Shell.Backend.Editline > > Each module exports a single constant: > > Prelude> :browse System.Console.Shell.Backend.Editline > editlineBackend :: System.Console.Shell.Backend.ShellBackend () > Prelude> :browse System.Console.Shell.Backend.Readline > readlineBackend :: System.Console.Shell.Backend.ShellBackend () > > On Macs I want to use Editline, under Linux Readline, Therefore I #ifdef > my sources. (The functionality seems to be the same for both packages) > > My questions are: > > 1. Should not the exported constants have the same name > 2. Should not even the module name be the same in both packages I don't think so. I personally view such "top level" overloading as undesirable. There might possibly be a legitimate reason to want both modules avaliable simultaneously. Punning the module name would make that impossible. If you want a package that multiplexes the editline package or the readline package depending on avaliability, that would be easy to do. It would just require wraping up the #ifdef stuff needed into a single place. I can probably find a few minutes this afternoon/evening to do this. > As long as not both packages are installed the compiler would pick the > proper package without my #ifdefs. > > HTH Christian From Christian.Maeder at dfki.de Tue Feb 19 13:35:51 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Feb 19 13:34:05 2008 Subject: darcs patch: [PROOF OF CONCEPT] build readline package with libedit In-Reply-To: <200802191252.09847.robdockins@fastmail.fm> References: <6d74b0d20801080838p5763ea07uf1bc8a16e21b6e08@mail.gmail.com> <1203420662.2102.55.camel@localhost> <47BAE62A.7090202@dfki.de> <200802191252.09847.robdockins@fastmail.fm> Message-ID: <47BB2187.9070106@dfki.de> Robert Dockins wrote: > If you want a package that multiplexes the editline package or the readline > package depending on avaliability, that would be easy to do. It would just > require wraping up the #ifdef stuff needed into a single place. I can > probably find a few minutes this afternoon/evening to do this. Yes, that's exactly what I want, although a third module name is needed. How do you set up the cabal file for such a package? The license entry could simply mention the possible readline dependency. Cheers Christian (Maybe that's useful for other packages, too, that can be realized via readline or editline, or even for the common bits of the readline and editline packages, since it's not the module System.Console.Editline.Readline ifself) From robdockins at fastmail.fm Tue Feb 19 15:38:23 2008 From: robdockins at fastmail.fm (Robert Dockins) Date: Tue Feb 19 15:36:28 2008 Subject: darcs patch: [PROOF OF CONCEPT] build readline package with libedit In-Reply-To: <47BB2187.9070106@dfki.de> References: <6d74b0d20801080838p5763ea07uf1bc8a16e21b6e08@mail.gmail.com> <200802191252.09847.robdockins@fastmail.fm> <47BB2187.9070106@dfki.de> Message-ID: <200802191538.23307.robdockins@fastmail.fm> On Tuesday 19 February 2008 01:35:51 pm Christian Maeder wrote: > Robert Dockins wrote: > > If you want a package that multiplexes the editline package or the > > readline package depending on avaliability, that would be easy to do. It > > would just require wraping up the #ifdef stuff needed into a single > > place. I can probably find a few minutes this afternoon/evening to do > > this. > > Yes, that's exactly what I want, although a third module name is needed. Ok. Here we go. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Shellac-compatline-0.9 > How do you set up the cabal file for such a package? Cabal configuration flags can do this sort of thing. > The license entry could simply mention the possible readline dependency. > > Cheers Christian > > (Maybe that's useful for other packages, too, that can be realized via > readline or editline, or even for the common bits of the readline and > editline packages, since it's not the module > System.Console.Editline.Readline ifself) Rob Dockins From judah.jacobson at gmail.com Tue Feb 19 16:59:04 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Tue Feb 19 16:57:18 2008 Subject: darcs patch: [PROOF OF CONCEPT] build readline package with libedit In-Reply-To: <47BB2187.9070106@dfki.de> References: <6d74b0d20801080838p5763ea07uf1bc8a16e21b6e08@mail.gmail.com> <1203420662.2102.55.camel@localhost> <47BAE62A.7090202@dfki.de> <200802191252.09847.robdockins@fastmail.fm> <47BB2187.9070106@dfki.de> Message-ID: <6d74b0d20802191359s1ff7cd36h477deaa61319ddcb@mail.gmail.com> I've actually put together a readline-compat package like you described: http://code.haskell.org/readline-compat I hadn't put it on hackage yet because I've been waiting for a resolution to http://hackage.haskell.org/trac/ghc/ticket/2053 -Judah On Tue, Feb 19, 2008 at 10:35 AM, Christian Maeder wrote: > Robert Dockins wrote: > > If you want a package that multiplexes the editline package or the readline > > package depending on avaliability, that would be easy to do. It would just > > require wraping up the #ifdef stuff needed into a single place. I can > > probably find a few minutes this afternoon/evening to do this. > > Yes, that's exactly what I want, although a third module name is needed. > How do you set up the cabal file for such a package? > > The license entry could simply mention the possible readline dependency. > > Cheers Christian > > (Maybe that's useful for other packages, too, that can be realized via > readline or editline, or even for the common bits of the readline and > editline packages, since it's not the module > System.Console.Editline.Readline ifself) > > > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From chak at cse.unsw.edu.au Tue Feb 19 19:28:55 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue Feb 19 19:28:00 2008 Subject: darcs patch: [PROOF OF CONCEPT] build readline package with libedit In-Reply-To: <1203420662.2102.55.camel@localhost> References: <6d74b0d20801080838p5763ea07uf1bc8a16e21b6e08@mail.gmail.com> <200801211247.49138.robdockins@fastmail.fm> <6d74b0d20801210945n160870bbp5499e48c0b1115df@mail.gmail.com> <200802141927.11489.robdockins@fastmail.fm> <47BAB678.1030505@dfki.de> <1203420662.2102.55.camel@localhost> Message-ID: <25F5D8D5-66E5-4EEA-96C3-B0F925D514C5@cse.unsw.edu.au> Duncan Coutts: > > On Tue, 2008-02-19 at 12:01 +0100, Henning Thielemann wrote: >> On Tue, 19 Feb 2008, Christian Maeder wrote: >> >>> In order to avoid several #ifdefs (maybe differently or suboptimal >>> given) in user sources (to achieve 1.) such #ifdefs (or wrappers) >>> should be part of the libraries (including the documentation for the >>> license differences)! >> >> Can Cabal-1.2's flag capability manage such a task? > > I don't think I understand the problem clearly enough to say. Perhaps > someone can try explaining it in more detail. Maybe I am reading this the wrong way, but didn't we say we DON'T want to build the readline package with libedit, but rather have a separate editline package. A fundamental reason for avoiding building the same library interface with alternatively readline and editline was that the license of that package would then have to change on a build per build basis. I think we concluded that (a) that would be confusing and (b) is not support by Cabal's package meta information. Manuel From ahey at iee.org Wed Feb 20 05:46:30 2008 From: ahey at iee.org (Adrian Hey) Date: Wed Feb 20 05:44:44 2008 Subject: cpuTimePrecision wrong on Windows? In-Reply-To: <47BAF6AE.2070800@iee.org> References: <47BAF6AE.2070800@iee.org> Message-ID: <47BC0506.5010201@iee.org> Adrian Hey wrote: > At least getCPUTime always seems to > return a multiple of 125000000 (1/8 of cpuTimePrecision). Actually, that's wrong. A little more intelligent experimentation reveals that (on my system at least) getCPUTime always returns a multiple of 15625000000 (cpuTimePrecision = 15.625 mS IOW). It's still not the same as the figure exported by System.CPUTime though :-( Regards -- Adrian Hey From Christian.Maeder at dfki.de Wed Feb 20 08:11:01 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Feb 20 08:09:13 2008 Subject: darcs patch: [PROOF OF CONCEPT] build readline package with libedit In-Reply-To: <200802191538.23307.robdockins@fastmail.fm> References: <6d74b0d20801080838p5763ea07uf1bc8a16e21b6e08@mail.gmail.com> <200802191252.09847.robdockins@fastmail.fm> <47BB2187.9070106@dfki.de> <200802191538.23307.robdockins@fastmail.fm> Message-ID: <47BC26E5.3070804@dfki.de> Robert Dockins wrote: > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Shellac-compatline-0.9 Brilliant, it works as expected. Thanks again. >> How do you set up the cabal file for such a package? > > Cabal configuration flags can do this sort of thing. Yes, good to see this. >> The license entry could simply mention the possible readline dependency. We'll see if the license will be a problem. Cheers Christian From lemming at henning-thielemann.de Wed Feb 20 10:17:55 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Feb 20 10:15:34 2008 Subject: [Haskell-cafe] The Proliferation of List-Like Types In-Reply-To: References: Message-ID: > Now, to help solve this problem, I wrote ListLike[2], providing a > set of typeclasses that make list operations generic. I also provided > default instances of ListLike for: > > ListLike Data.ByteString.ByteString Word8 > ListLike Data.ByteString.Lazy.ByteString Word8 > ListLike [a] a > (Integral i, Ix i) => ListLike (Array i e) e > (Ord key, Eq val) => ListLike (Map key val) (key, val) It's a multi-parameter type class, right? So it's difficult to push it to the core. > Now, the questions: > > 1) Does everyone agree with me that we have a problem here? I agree. > 2) Would it make sense to make ListLike, or something like it, > part of the Haskell core? Somehow yes. However since the 'base' package is constantly split into smaller parts, there is maybe no need to merge it somewhere, but introduce simply new package dependencies. > 3) Would it make sense to base as much code as possible in the Haskell > core areound ListLike definitions? Here I think of functions such > as lines and words, which make sense both on [Char] as well as > ByteStrings. > > 4) We are missing one final useful type: a Word32-based ByteString. > When working in the Unicode character set, a 32-bit character > can indeed be useful, and I could see situations in which the > performance benefit of a ByteString-like implementation could > be useful combared to [Char]. StorableVector should fill this gap. http://code.haskell.org/~sjanssen/storablevector/ From judah.jacobson at gmail.com Wed Feb 20 20:31:06 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Wed Feb 20 20:29:18 2008 Subject: Readline read_history and write_history addition In-Reply-To: <2608b8a80802061309h4c85c9dai4add6870d779496c@mail.gmail.com> References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> <2608b8a80801230519v72388283xf35f1de120571ca2@mail.gmail.com> <57526e770802021035u170e47cey77edea12eaa5c340@mail.gmail.com> <2608b8a80802021130i2b4486c3m74bc6ef7fdd2c425@mail.gmail.com> <6d74b0d20802021203x7ae35e0fjaee1a1c961731856@mail.gmail.com> <2608b8a80802021314k7bcbc643n22d4ee53e6506d73@mail.gmail.com> <47A6FCBE.4090101@gmail.com> <2608b8a80802040606mdb73f20n6090d1b437d5202@mail.gmail.com> <6d74b0d20802041349v1597c25cq4fdd55f4c9a9b904@mail.gmail.com> <2608b8a80802061309h4c85c9dai4add6870d779496c@mail.gmail.com> Message-ID: <6d74b0d20802201731l48441e77kf9f122c088492e49@mail.gmail.com> Hi all, Discussion over this issue has died down. Yitzchak and others have made good arguments for the type signatures readHistory :: String -> IO Bool writeHistory :: String -> IO Bool which reflect the non-exceptional nature of failure of those functions. Does anyone have any problems with implementing the following patch from Alex (along with the above change)? http://www.haskell.org/pipermail/libraries/2008-January/009007.html For reference, this is in relation to the following proposal: http://hackage.haskell.org/trac/ghc/ticket/2053 If no objections are raised by next week (say, Feb. 27), we should make the above changes to readline, which will let us implement #2050 (persistent history file in ghci). Thanks, -Judah On Wed, Feb 6, 2008 at 1:09 PM, Yitzchak Gale wrote: > Judah Jacobson wrote: > > - readFile... writeFile... > > > I think of readHistory and writeHistory as analogues to the above > > functions. > > I don't think so. I don't really care about the file itself - that > just happens to be the way readline implements its persistence. > Non-existence of the file is the normal way that readline > represents the fact that there isn't any history yet. > The semantics of the API call are: load history, if any exists yet, > and report the result. Nothing exceptional about that. > > > > All that being said, this is a relatively minor issue > > Agreed. All the more so with the MonadIO problem now factored > out. > > Regards, > Yitz > From lemming at henning-thielemann.de Wed Feb 20 23:39:27 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Feb 20 23:37:37 2008 Subject: FunctorM.fmapM vs. Traversable with GHC-6.4 and GHC-6.8 Message-ID: What is the intended way to make a library using FunctorM/fmapM compatible to both GHC-6.4 and GHC-6.8 ? From john at repetae.net Wed Feb 20 23:44:33 2008 From: john at repetae.net (John Meacham) Date: Wed Feb 20 23:42:43 2008 Subject: FunctorM.fmapM vs. Traversable with GHC-6.4 and GHC-6.8 In-Reply-To: References: Message-ID: <20080221044433.GB26731@sliver.repetae.net> On Thu, Feb 21, 2008 at 05:39:27AM +0100, Henning Thielemann wrote: > What is the intended way to make a library using FunctorM/fmapM compatible > to both GHC-6.4 and GHC-6.8 ? Just a note, DrIFT 2.2.3 or later (http://repetae.net/computer/haskell/DrIFT/) supports deriving both the Foldable and Traversable classes for arbitrary types, this should alleviate the migration issues somewhat. John -- John Meacham - ?repetae.net?john? From lemming at henning-thielemann.de Wed Feb 20 23:51:20 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Feb 20 23:49:31 2008 Subject: FunctorM.fmapM vs. Traversable with GHC-6.4 and GHC-6.8 In-Reply-To: <20080221044433.GB26731@sliver.repetae.net> References: <20080221044433.GB26731@sliver.repetae.net> Message-ID: On Wed, 20 Feb 2008, John Meacham wrote: > On Thu, Feb 21, 2008 at 05:39:27AM +0100, Henning Thielemann wrote: > > What is the intended way to make a library using FunctorM/fmapM compatible > > to both GHC-6.4 and GHC-6.8 ? > > Just a note, DrIFT 2.2.3 or later > (http://repetae.net/computer/haskell/DrIFT/) supports deriving both the > Foldable and Traversable classes for arbitrary types, this should > alleviate the migration issues somewhat. I like a solution like Traversable for GHC-6.4 or FunctorM for GHC-6.8 (as packages on Hackage). From lemming at henning-thielemann.de Thu Feb 21 02:12:19 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Feb 21 02:11:08 2008 Subject: upgrading GHC Message-ID: I did now spend some days(!) on making only some of my packages compatible to both GHC-6.4.1 and GHC-6.8.2. The amount of adaption work increased with every GHC update for me, also because the number of installed packages constantly grew. I'm hardly able to manage this work for GHC-6.10, many packages will then go 'outdated', maybe only weeks after their release. Some people wonder, why not simply upgrade. There are many reasons: This way you can easily fall into a gap between dependent packages that are still not updated to GHC-6.8.2 and others that are already updated, but not backwards compatible. Compiler versions are different in usability, bugs and annoyances. Namely, GHC-6.4.1 introduced wrong warnings on apparently superfluous imports and a bug that let one of my modules become uncompileable because of the compiler running out of memory, GHC-6.6 replaced working filename completion by only partially working identifier completion (it was certainly not a good idea, to remove the old behaviour completely, before the new one worked reliably, but it happened and we have to cope with), GHC-6.8.1 had a bug in compilation. So after investing much time in upgrading you might encounter that your programs don't work anymore or usability decreased considerably and you have the choice to wait for the next compiler release, try to compile the HEAD version from repository yourself (good luck!) or turn everything back to the old version. Even if the compiler does only get better with respect to features, you might decide not to upgrade, because the newer version consumes more memory or is slower due to more features that the compiler must handle. Every GHC update so far forced me to recompile my packages, broke some code, either by new class instances, modules being replaced by newer ones, shifting modules between packages. Sometimes the update helped improving the code, either when the compiler emitted new warnings or when internal functions were changed, and I became aware, that I was using internal functions. But it is very hard to get a library compiled on different compiler versions, not to mention different compilers. This is especially nasty if you are working in an institute (like the universities I worked at in the past) with different machines with very different software installations. We have some Solaris machines here with GHC-5, which I do not administer, Linux machines with GHC-6.4.1, GHC-6.6.1 and so on. I cannot simply push around patches with darcs because every machine needs separate package adaption. It was said, that Cabal would work also with GHC-6.2. I didn't get it running and then switched to GHC-6.4. It was said, that multiple versions of GHC can be installed on the same machine. That's somehow true, but e.g. runhaskell cannot be told which actual GHC binary to use, and thus it is not possible to run Cabal with a compiler or a compiler version different from the compiler to be used for the package. I decided to upgrade to Cabal-1.2, which also needed installation of filepath. I know that installation could be simplified with cabal-install, which has even more dependencies, and thus I canceled this installation project. Then I have equipped my Cabal files with a switch on splitBase, which merely duplicates the globally known information that former base-1.0 package is now split into base-2.0 or base-3.0 and satellites. It doesn't give the user any new value, but costs a lot of time for the package maintainer. I wonder if it would have been simpler to ship GHC-6.8 with a base-1.0 package or provide it on Hackage that just re-exports the old modules in the known way. This would allow the usage of packages that are in different state of adaption and it will reduce the amount of work for package maintainers considerably. I also predict that the switch on different package arrangements in the Cabal file will grow in future, eventually becoming error-prone and unmaintainable. How many GHC versions do you have installed simultaneously in order to test them all? Don't misunderstand me. I embrace tidying the libraries but I urge to do it in a more compatible manner. Deprecated packages do not need to be banned from the internet. It is not necessary to enforce programmers to adapt to changes immediately, it is better provide ways for doing the changes later, when time has come, in a smooth manner. I thought it was a good idea to adapt to FunctorM in GHC-6.4 quickly instead of rolling my own class. Then, two GHC releases later this module disappeared, was replaced by Traversable. I thought it was good style to rewrite code from List.lookup to FiniteMap in GHC-6.0, in GHC-6.4 it already disappeared, replaced by Data.Map. Why is it necessary to make working libraries obsolete so quickly? I thought using standard modules is more reliable (because of more testers, more possible maintainers) than using custom modules. If libraries change so quickly this forces programmers to fork to their own modules. From trevion at gmail.com Thu Feb 21 03:32:41 2008 From: trevion at gmail.com (J. Garrett Morris) Date: Thu Feb 21 03:30:51 2008 Subject: cpuTimePrecision wrong on Windows? In-Reply-To: <47BC0506.5010201@iee.org> References: <47BAF6AE.2070800@iee.org> <47BC0506.5010201@iee.org> Message-ID: <6cf91caa0802210032n472b9488x72e3b6234503ae3f@mail.gmail.com> Both numbers seem odd to me. As far as I can tell, GHC uses GetProcessTimes to implement getCPUTime. GetProcessTimes returns counts of 100s of nanoseconds, which isn't the number GHC uses for cpuTimePrecision, but I can't find anyplace in the API documentation that Microsoft actually guarantees any non-hardware dependent timing precision. /g On Wed, Feb 20, 2008 at 2:46 AM, Adrian Hey wrote: > Adrian Hey wrote: > > At least getCPUTime always seems to > > return a multiple of 125000000 (1/8 of cpuTimePrecision). > > Actually, that's wrong. A little more intelligent experimentation > reveals that (on my system at least) getCPUTime always returns > a multiple of 15625000000 (cpuTimePrecision = 15.625 mS IOW). > > It's still not the same as the figure exported by System.CPUTime > though :-( > > > > Regards > -- > Adrian Hey > > > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -- The man who'd introduced them didn't much like either of them, though he acted as if he did, anxious as he was to preserve good relations at all times. One never knew, after all, now did one now did one now did one. From duncan.coutts at worc.ox.ac.uk Thu Feb 21 05:34:31 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Feb 21 05:34:08 2008 Subject: upgrading GHC In-Reply-To: References: Message-ID: <1203590071.3076.41.camel@localhost> On Thu, 2008-02-21 at 08:12 +0100, Henning Thielemann wrote: > It was said, that Cabal would work also with GHC-6.2. I didn't get it > running and then switched to GHC-6.4. It was said, that multiple versions > of GHC can be installed on the same machine. That's somehow true, but e.g. > runhaskell cannot be told which actual GHC binary to use, and thus it is > not possible to run Cabal with a compiler or a compiler version different > from the compiler to be used for the package. It's always possible to: ghc-6.4.1 --make Setup.hs -o setup ./setup configure ...etc rather than using whatever ghc runghc/runhaskell finds on the $PATH. I keep 3 versions of ghc installed this way to test Cabal and other stuff. > I decided to upgrade to Cabal-1.2, which also needed installation of > filepath. I know that installation could be simplified with cabal-install, > which has even more dependencies, and thus I canceled this installation > project. Then I have equipped my Cabal files with a switch on splitBase, > which merely duplicates the globally known information that former > base-1.0 package is now split into base-2.0 or base-3.0 and satellites. It > doesn't give the user any new value, but costs a lot of time for the > package maintainer. I wonder if it would have been simpler to ship GHC-6.8 > with a base-1.0 package or provide it on Hackage that just re-exports the > old modules in the known way. We know this issue is a mess. We've discussed it at length. http://hackage.haskell.org/trac/ghc/wiki/PackageCompatibility Sadly at the moment it is impossible to supply a base-1.0 with ghc-6.8 because packages cannot re-export modules and even if they could, ghc and cabal would have no way to figure out if a particular program was intended to use one or the other. > This would allow the usage of packages that > are in different state of adaption and it will reduce the amount of work > for package maintainers considerably. I also predict that the switch on > different package arrangements in the Cabal file will grow in future, > eventually becoming error-prone and unmaintainable. How many GHC versions > do you have installed simultaneously in order to test them all? Personally, I have 3. :-) > Don't misunderstand me. I embrace tidying the libraries but I urge to do > it in a more compatible manner. So do I. Tell is what you think about the suggestions on the PackageCompatibility page above. > Deprecated packages do not need to be > banned from the internet. It is not necessary to enforce programmers to > adapt to changes immediately, it is better provide ways for doing the > changes later, when time has come, in a smooth manner. I thought it was a > good idea to adapt to FunctorM in GHC-6.4 quickly instead of rolling my > own class. Then, two GHC releases later this module disappeared, was > replaced by Traversable. I thought it was good style to rewrite code from > List.lookup to FiniteMap in GHC-6.0, in GHC-6.4 it already disappeared, > replaced by Data.Map. Why is it necessary to make working libraries > obsolete so quickly? Though the advantage of more packages is that we can have (and there is) a compatibility package for the old FiniteMap. > I thought using standard modules is more reliable > (because of more testers, more possible maintainers) than using custom > modules. If libraries change so quickly this forces programmers to fork to > their own modules. Duncan From bulat.ziganshin at gmail.com Thu Feb 21 05:12:59 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Feb 21 07:31:15 2008 Subject: FunctorM.fmapM vs. Traversable with GHC-6.4 and GHC-6.8 In-Reply-To: References: Message-ID: <17710591647.20080221131259@gmail.com> Hello Henning, Thursday, February 21, 2008, 7:39:27 AM, you wrote: > What is the intended way to make a library using FunctorM/fmapM compatible > to both GHC-6.4 and GHC-6.8 ? either 1) support two different cabal files and propose users to manually rename one they need to .cabal 2) suggest 6.4 users to switch to newest cabal version which supports config sections and use them 3) install library via makefile, custom haskell script or smth like this you also can combine these ideas :) the more interesting question "how to provide compatibility with 7.0, 7.2 and other future ghc versions" :D -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From lemming at henning-thielemann.de Thu Feb 21 07:39:16 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Feb 21 07:37:30 2008 Subject: FunctorM.fmapM vs. Traversable with GHC-6.4 and GHC-6.8 In-Reply-To: <17710591647.20080221131259@gmail.com> References: <17710591647.20080221131259@gmail.com> Message-ID: On Thu, 21 Feb 2008, Bulat Ziganshin wrote: > Hello Henning, > > Thursday, February 21, 2008, 7:39:27 AM, you wrote: > > > What is the intended way to make a library using FunctorM/fmapM compatible > > to both GHC-6.4 and GHC-6.8 ? > > either > 1) support two different cabal files and propose users to manually > rename one they need to .cabal > 2) suggest 6.4 users to switch to newest cabal version which supports > config sections and use them > 3) install library via makefile, custom haskell script or smth like > this Whereever possible I tried to achieve compatibility between GHC-6.4 and GHC-6.8 by fetching the modules from the right packages using 'flag' in Cabal. However this problem is more delicate because the two related modules, classes (FunctorM/Traversable) and methods (fmapM/traverse) have different names. > the more interesting question "how to provide compatibility with 7.0, > 7.2 and other future ghc versions" :D This would have been my next question. From simonmarhaskell at gmail.com Thu Feb 21 08:03:44 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Feb 21 08:01:57 2008 Subject: darcs patch: [PROOF OF CONCEPT] build readline package with libedit In-Reply-To: <6d74b0d20802191359s1ff7cd36h477deaa61319ddcb@mail.gmail.com> References: <6d74b0d20801080838p5763ea07uf1bc8a16e21b6e08@mail.gmail.com> <1203420662.2102.55.camel@localhost> <47BAE62A.7090202@dfki.de> <200802191252.09847.robdockins@fastmail.fm> <47BB2187.9070106@dfki.de> <6d74b0d20802191359s1ff7cd36h477deaa61319ddcb@mail.gmail.com> Message-ID: <47BD76B0.3010002@gmail.com> Judah Jacobson wrote: > I've actually put together a readline-compat package like you described: > > http://code.haskell.org/readline-compat This is not the way to go, IMO. As Manuel said, we don't want packages with licenses that depend on the way the package is built. The readline-compat package above has this problem, and the only way to fix it is to make its license GPL. But presumably that's exactly what you don't want to do, because the purpose of using editline is to avoid the GPL. Packages which want to use either editline or readline should say so in their .cabal files, we cannot abstract this choice into a package of its own. Cheers, Simon From Christian.Maeder at dfki.de Thu Feb 21 09:07:01 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Feb 21 09:05:12 2008 Subject: darcs patch: [PROOF OF CONCEPT] build readline package with libedit In-Reply-To: <47BD76B0.3010002@gmail.com> References: <6d74b0d20801080838p5763ea07uf1bc8a16e21b6e08@mail.gmail.com> <1203420662.2102.55.camel@localhost> <47BAE62A.7090202@dfki.de> <200802191252.09847.robdockins@fastmail.fm> <47BB2187.9070106@dfki.de> <6d74b0d20802191359s1ff7cd36h477deaa61319ddcb@mail.gmail.com> <47BD76B0.3010002@gmail.com> Message-ID: <47BD8585.4070206@dfki.de> Simon Marlow wrote: > Judah Jacobson wrote: >> I've actually put together a readline-compat package like you described: >> >> http://code.haskell.org/readline-compat > > This is not the way to go, IMO. As Manuel said, we don't want packages > with licenses that depend on the way the package is built. The > readline-compat package above has this problem, and the only way to fix > it is to make its license GPL. But presumably that's exactly what you > don't want to do, because the purpose of using editline is to avoid the > GPL. My major aim was to avoid that users of our software need to install the GNUReadline.framework (or libreadline) on their macs (although we could probably also link libreadline and libncurses statically.) > Packages which want to use either editline or readline should say so in > their .cabal files, we cannot abstract this choice into a package of its > own. You also abstract the choice between windows and unix. Doesn't that have license implications, too? Cheers Christian From simonmarhaskell at gmail.com Thu Feb 21 09:43:00 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Feb 21 09:41:15 2008 Subject: upgrading GHC In-Reply-To: <1203590071.3076.41.camel@localhost> References: <1203590071.3076.41.camel@localhost> Message-ID: <47BD8DF4.3090106@gmail.com> Duncan Coutts wrote: > On Thu, 2008-02-21 at 08:12 +0100, Henning Thielemann wrote: > >> It was said, that Cabal would work also with GHC-6.2. I didn't get it >> running and then switched to GHC-6.4. It was said, that multiple versions >> of GHC can be installed on the same machine. That's somehow true, but e.g. >> runhaskell cannot be told which actual GHC binary to use, and thus it is >> not possible to run Cabal with a compiler or a compiler version different >> from the compiler to be used for the package. > > It's always possible to: > ghc-6.4.1 --make Setup.hs -o setup > ./setup configure > ...etc > > rather than using whatever ghc runghc/runhaskell finds on the $PATH. I > keep 3 versions of ghc installed this way to test Cabal and other stuff. > >> I decided to upgrade to Cabal-1.2, which also needed installation of >> filepath. I know that installation could be simplified with cabal-install, >> which has even more dependencies, and thus I canceled this installation >> project. Then I have equipped my Cabal files with a switch on splitBase, >> which merely duplicates the globally known information that former >> base-1.0 package is now split into base-2.0 or base-3.0 and satellites. It >> doesn't give the user any new value, but costs a lot of time for the >> package maintainer. I wonder if it would have been simpler to ship GHC-6.8 >> with a base-1.0 package or provide it on Hackage that just re-exports the >> old modules in the known way. > > We know this issue is a mess. We've discussed it at length. > http://hackage.haskell.org/trac/ghc/wiki/PackageCompatibility > > Sadly at the moment it is impossible to supply a base-1.0 with ghc-6.8 > because packages cannot re-export modules and even if they could, ghc > and cabal would have no way to figure out if a particular program was > intended to use one or the other. Duncan's right, and we do plan to tackle this problem in 6.10. But there's something practical that the community could do *right now* to make everyone's life easier. We've talked about this before at various times, but I thought I'd mention it again in case it inspires anyone to stand up and volunteer to spearhead the effort. The idea is to have a group of people who manage "distributions" of Haskell software. The idea would be similar to how GNOME works, where they have a collection of software components bundled together, tested and released as a coherent unit. Each individual component is maintained separately and has its own release cycle, but the distribution managers bundle up a set of mutually-compatible components and call it "GNOME version x.xx", releasing new distributions on a time-based cycle. So the advantage of doing this would be that someone can easily get a version of a package that is compatible with the other packages they already have. Cabal/Hackage would know which distribution your installation is based on, and it would automatically grab the right version of the package you need. When upgrading a distribution you do it all-at-once. No problems with upgrading packages piecemeal and getting into a mess with multiple versions of dependencies. I think doing this would deliver a system that "just works" for the majority of users most of the time. But it needs people to drive it and make it happen. Cheers, Simon From lemming at henning-thielemann.de Thu Feb 21 10:19:06 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Feb 21 10:17:15 2008 Subject: upgrading GHC In-Reply-To: <1203590071.3076.41.camel@localhost> References: <1203590071.3076.41.camel@localhost> Message-ID: On Thu, 21 Feb 2008, Duncan Coutts wrote: > On Thu, 2008-02-21 at 08:12 +0100, Henning Thielemann wrote: > > > It was said, that Cabal would work also with GHC-6.2. I didn't get it > > running and then switched to GHC-6.4. It was said, that multiple versions > > of GHC can be installed on the same machine. That's somehow true, but e.g. > > runhaskell cannot be told which actual GHC binary to use, and thus it is > > not possible to run Cabal with a compiler or a compiler version different > > from the compiler to be used for the package. > > It's always possible to: > ghc-6.4.1 --make Setup.hs -o setup > ./setup configure > ...etc > > rather than using whatever ghc runghc/runhaskell finds on the $PATH. I > keep 3 versions of ghc installed this way to test Cabal and other stuff. Nice idea. > > I decided to upgrade to Cabal-1.2, which also needed installation of > > filepath. I know that installation could be simplified with cabal-install, > > which has even more dependencies, and thus I canceled this installation > > project. Then I have equipped my Cabal files with a switch on splitBase, > > which merely duplicates the globally known information that former > > base-1.0 package is now split into base-2.0 or base-3.0 and satellites. It > > doesn't give the user any new value, but costs a lot of time for the > > package maintainer. I wonder if it would have been simpler to ship GHC-6.8 > > with a base-1.0 package or provide it on Hackage that just re-exports the > > old modules in the known way. > > We know this issue is a mess. We've discussed it at length. > http://hackage.haskell.org/trac/ghc/wiki/PackageCompatibility > > Sadly at the moment it is impossible to supply a base-1.0 with ghc-6.8 > because packages cannot re-export modules and even if they could, ghc > and cabal would have no way to figure out if a particular program was > intended to use one or the other. I can't follow here. I think it must be possible to provide a base-1.1 which exports the same modules as base-1.0 but gets them from other packages. It can be considered the last version of the base-1 series and the transition to base-2.0. > > Don't misunderstand me. I embrace tidying the libraries but I urge to do > > it in a more compatible manner. > > So do I. Tell is what you think about the suggestions on the > PackageCompatibility page above. With respect to "4. Allow packages to re-export modules" Is it a good idea to include the versioning in the language? I see no need for it. I thought it could be done by 'ghc-pkg' to re-export modules. Btw. I had problems with hidden packages in GHC-6.4.1. They still interfer with other package versions, and thus I have to unregister all versions of a package but one, in order to get something compiled. Is this a known issue of GHC-6.4.1 or am I expecting the wrong behaviour of ghc-pkg? I thought the exposed version is visible in GHCi and without -package option, whereas the hidden but registered packages can be imported with -package and thus Cabal. I find the solution "4.3 Don't rename base" the best one. Is this the way for GHC-6.10? > > Deprecated packages do not need to be > > banned from the internet. It is not necessary to enforce programmers to > > adapt to changes immediately, it is better provide ways for doing the > > changes later, when time has come, in a smooth manner. I thought it was a > > good idea to adapt to FunctorM in GHC-6.4 quickly instead of rolling my > > own class. Then, two GHC releases later this module disappeared, was > > replaced by Traversable. I thought it was good style to rewrite code from > > List.lookup to FiniteMap in GHC-6.0, in GHC-6.4 it already disappeared, > > replaced by Data.Map. Why is it necessary to make working libraries > > obsolete so quickly? > > Though the advantage of more packages is that we can have (and there is) > a compatibility package for the old FiniteMap. Now, a package for FunctorM for GHC>=6.6 and Traversable for GHC<6.6 would be great. From bulat.ziganshin at gmail.com Thu Feb 21 10:55:24 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Feb 21 11:51:45 2008 Subject: upgrading GHC In-Reply-To: <47BD8DF4.3090106@gmail.com> References: <1203590071.3076.41.camel@localhost> <47BD8DF4.3090106@gmail.com> Message-ID: <1516830373.20080221185524@gmail.com> Hello Simon, Thursday, February 21, 2008, 5:43:00 PM, you wrote: these are two orthogonal questions > The idea is to have a group of people who manage "distributions" of Haskell > software. i don't think that we need so much programmers in order to add to Cabal just one field "HLP compatibility" :))) HLP-compatible libraries will assemble into gems automagically, are you see it? ;) so it becomes mainly an advertising problem. it will be great if ghc/hugs/nhc will continue to be released each Autumn. this will allow to port most of the libraries till December and then advertise it as Haskell-20xx gem. actually, we may even recommend to tag libraries (starting from base) with year of release as their major version so it will require less thinking - just use GHC-2008 with ByteString-2008, HTTP-2008 and so on (while HTTP-2008 may be also remain compatible with a few last gems, say starting from Haskell-2006) >>> I wonder if it would have been simpler to ship GHC-6.8 >>> with a base-1.0 package or provide it on Hackage that just re-exports the >>> old modules in the known way the problem here is not lack of gems but fluctuation of base lib. don't skip that he needs to use the same code with ghc 6.4...6.8. the only 100% solution of this problem proposed at this moment is freezing of base -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From ahey at iee.org Thu Feb 21 12:25:35 2008 From: ahey at iee.org (Adrian Hey) Date: Thu Feb 21 12:23:46 2008 Subject: cpuTimePrecision wrong on Windows? In-Reply-To: <6cf91caa0802210032n472b9488x72e3b6234503ae3f@mail.gmail.com> References: <47BAF6AE.2070800@iee.org> <47BC0506.5010201@iee.org> <6cf91caa0802210032n472b9488x72e3b6234503ae3f@mail.gmail.com> Message-ID: <47BDB40F.3060906@iee.org> Hello, I wonder (if there's no set reliable figure for all platforms) if it should be done empirically. Here's a naive way.. cpuTimePrecision = unsafePerformIO getCpuTimePrecision getCpuTimePrecision = do t0 <- getCPUTime let wait = do t1 <- getCPUTime if t1>t0 then return (t1-t0) else wait wait But I guess you could do better than that with some more care and effort. Regards -- Adrian Hey From roconnor at theorem.ca Thu Feb 21 15:28:55 2008 From: roconnor at theorem.ca (roconnor@theorem.ca) Date: Thu Feb 21 15:27:04 2008 Subject: [GHC] #974: Add unzipEithers, lefts, rights to Data.Either In-Reply-To: References: <044.771c90fc72736a1914b3f63a62b98bc6@localhost> <053.59bba6fc96d56b1d4eb049045eb70a87@localhost> Message-ID: On Fri, 15 Feb 2008, roconnor@theorem.ca wrote: > partitionEithers - This is (I believe) the most popular (or least > controversial) name. The output of our function has similar properties to > the output of partition. The only objection possible objection is that > partitionEithers perhaps should have type (a -> Either b c) -> [a] -> > ([b],[c]), ie. partitonEithers should take a function as a parameter. The > response to this objection by saying that the extra `Eithers' in the name > fills the place of the predicate/function. Also the function of type (a -> > Either b c) -> [a] -> ([b],[c]) is less widely used that the function we are > trying to name in this trac. If there are no further comments before March 7th, We shall declare that parititonEithers, lefts, and rights, shall be added to Data.Eithers. :) -- Russell O'Connor ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.'' From duncan.coutts at worc.ox.ac.uk Thu Feb 21 17:52:38 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Feb 21 17:50:48 2008 Subject: upgrading GHC In-Reply-To: References: <1203590071.3076.41.camel@localhost> Message-ID: <1203634358.3076.84.camel@localhost> On Thu, 2008-02-21 at 16:19 +0100, Henning Thielemann wrote: > > Sadly at the moment it is impossible to supply a base-1.0 with ghc-6.8 > > because packages cannot re-export modules and even if they could, ghc > > and cabal would have no way to figure out if a particular program was > > intended to use one or the other. > > I can't follow here. I think it must be possible to provide a base-1.1 > which exports the same modules as base-1.0 but gets them from other > packages. It can be considered the last version of the base-1 series and > the transition to base-2.0. Ok it would be possible to have two distinct base packages (though there is a restriction in ghc that would need to be lifted first). It would not be a very helpful situation however since base-1.0:Prelude.Int /= base-2.0:Prelude.Int so you'd have to have completely separate stacks of packages for each version of base. Our package infrastructure is just not up to dealing with that at the moment. We have enough problems when we upgrade bytestring and then have packages depending on packages that were built against different versions of that package. For example see: http://hpaste.org/5803 > Btw. I had problems with hidden packages in GHC-6.4.1. They still interfer > with other package versions, and thus I have to unregister all versions of > a package but one, in order to get something compiled. Is this a known > issue of GHC-6.4.1 or am I expecting the wrong behaviour of ghc-pkg? It's a known issue in GHC-6.4.1, it's fixed in 6.4.2. I would recommend you upgrade but you've already told us the long list of reasons why that is impractical. > I thought the exposed version is visible in GHCi and without -package > option, whereas the hidden but registered packages can be imported with > -package and thus Cabal. Yes, in 6.4.2 and later. Duncan From duncan.coutts at worc.ox.ac.uk Thu Feb 21 18:28:15 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Feb 21 18:26:25 2008 Subject: upgrading GHC In-Reply-To: <47BD8DF4.3090106@gmail.com> References: <1203590071.3076.41.camel@localhost> <47BD8DF4.3090106@gmail.com> Message-ID: <1203636496.3076.108.camel@localhost> On Thu, 2008-02-21 at 14:43 +0000, Simon Marlow wrote: > I think doing this would deliver a system that "just works" for the > majority of users most of the time. But it needs people to drive it and > make it happen. In particular I think we need the infrastructure to keep the time required by distro/platform maintainers to a minimum, otherwise it can easily turn into a full time job. I'd like to see an infrastructure where we can define subsets of hackage packages using fully automatic quality tests. Then further subsets defined by human review standards and consistent sets of packages that are tested together. All this testing etc is based on the idea that we have clients like cabal-install (and other special-purpose clients) doing tests and analyses and reporting back to the hackage server. The hackage server should not be doing any heavy processing, just managing the information. Here's a number of ideas for properties used to define hackage subsets: * can satisfy all of its dependencies from within hackage (there are a couple packages that depend on later versions of packages than exist within hackage) * package can actually build on at least some platform * package 'distcheck's ok, meaning can generate a tarball that builds * haddock docs build These are all pretty basic. For a platform release we want this property * all packages within the subset can satisfy all their dependencies consistently and can build against them This is different from the first property, that a solution exists to build each package individually, this requires that there is a solution to build all the packages in the set using only a single version of each package. Then further that this solution does indeed build. Then for higher quality we also want: * builds on windows, linux, macos * builds with -Wall without too high a volume of warnings * follows the package versioning policy * uses bounded range deps for dependencies that follows the PVP * has sufficient haddock documentation * certain % test coverage and tests work All of these can be checked automatically using suitable clients (mostly extensions of cabal+cabal-install) and hackage reporting. Some properties obviously require human review, like api quality, test quality (as opposed to quantity). But if more packages can be filtered down using these automated tests then putting together a platform release becomes much more manageable. Duncan From simonmarhaskell at gmail.com Fri Feb 22 04:41:46 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri Feb 22 04:39:57 2008 Subject: Proposal: add new forms of unsafePerformIO and unsafeInterleaveIO In-Reply-To: <20080214221809.GA4080@localhost.localdomain> References: <1202986477.21103.223.camel@localhost> <20080214221809.GA4080@localhost.localdomain> Message-ID: <47BE98DA.4050400@gmail.com> Stefan O'Rear wrote: > On Thu, Feb 14, 2008 at 10:54:37AM +0000, Duncan Coutts wrote: >> This version of 'unsafePerformIO' is slightly more efficient, because it >> omits the check that the IO is only being performed by a single thread. >> Hence, when you write 'unsafeDupablePerformIO', there is a possibility >> that the IO action may be performed multiple times (on a >> multiprocessor), and you should therefore ensure that it gives the same >> results each time. >> >> unsafeDupablePerformIO :: IO a -> a >> >> TODO: Actually, unsafeDupableInterleaveIO is not yet documented, >> that will have to be fixed. >> >> unsafeDupableInterleaveIO :: IO a -> IO a > > I propose that unsafeDupablePerformIO be renamed to unsafePerformIO, > since it satisfies all of the properties guaranteed of unsafePerformIO. > GHC's unsafePerformIO guarantees more, and should be called > unsafePerformIOAtMostOnce or something. That's certainly a defensible position, but I'll present a counter-argument. If you've managed to use unsafePerformIO in a way that works on a single processor, then you will probably be tempted to assume that it will work on a multiprocessor too. Currently unsafePerformIO tries to make that true (although it's not foolproof, and it's quite expensive). Look at all that stuff in the docs for unsafePeformIO about -fno-cse and let-floating (I think it goes too far, in fact - if your use of unsafePerformIO is that fragile then you're doing something wrong). If unsafePerformIO was the dupable version by default, then all that goes out of the window if you happen to be running with two threads on an SMP. And if you're writing a library, you have to assume the worst and go for the AtMOstOnce version - who would remember to do that? Better for the default version to be safe in this respect, IMO. The bugs we'd get from this would be really hard to track down. Cheers, Simon From Christian.Maeder at dfki.de Fri Feb 22 05:41:59 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Feb 22 05:40:11 2008 Subject: HTTP haskell package Message-ID: <47BEA6F7.40608@dfki.de> Why are the version numbers that big? 3000.0.0 3001.0.0 ... 3001.0.4 One (general) problem about different package versions on hackage for me is: the missing documentation of what has actually changed. Cheers Christian From duncan.coutts at worc.ox.ac.uk Fri Feb 22 05:46:40 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Feb 22 05:46:25 2008 Subject: Proposal: add new forms of unsafePerformIO and unsafeInterleaveIO In-Reply-To: <2608b8a80802140311i5db1ab01l72a9f03c95a7e2c6@mail.gmail.com> References: <1202986477.21103.223.camel@localhost> <2608b8a80802140311i5db1ab01l72a9f03c95a7e2c6@mail.gmail.com> Message-ID: <1203677201.3076.163.camel@localhost> On Thu, 2008-02-14 at 13:11 +0200, Yitzchak Gale wrote: > Duncan Coutts wrote: > > The additions are documented and portable to non-ghc. > > This sounds like a worthy addition to the library. > > The documentation for unsafeInlinePerformIO is a > description of how it behaves in GHC. Can you > describe the semantics in a compiler-independent > way? Actually that's pretty difficult. So in addition to the dangers of unsafeDupablePerformIO (that the action may be run more than once and may be executed in parallel) we have the possibility that the action is not necessarily run as a whole and in-order. We loose the guarantee on >>= providing ordering of effects and not all effects are necessarily run. Only those depending on the inputs will necessarily run. How's that? I'm not absolutely sure that's correct. Perhaps Don and Simon M can think about it for a moment. Duncan From bjorn at bringert.net Fri Feb 22 05:48:35 2008 From: bjorn at bringert.net (Bjorn Bringert) Date: Fri Feb 22 05:46:41 2008 Subject: HTTP haskell package In-Reply-To: <47BEA6F7.40608@dfki.de> References: <47BEA6F7.40608@dfki.de> Message-ID: On Fri, Feb 22, 2008 at 11:41 AM, Christian Maeder wrote: > Why are the version numbers that big? > > 3000.0.0 > 3001.0.0 > ... > 3001.0.4 > > One (general) problem about different package versions on hackage for me > is: the missing documentation of what has actually changed. > > Cheers Christian For historical reasons. The HTTP version numbers used to be date-based, e.g. 2006.11.15. To preserve ordering when we switched to major.minor versions, the numbering started at 3000.0.0. Perhaps we could show darcs change logs on hackage. For this we need a repository field in the .cabal file. /Bjorn From duncan.coutts at worc.ox.ac.uk Fri Feb 22 05:51:12 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Feb 22 05:51:49 2008 Subject: Proposal: add new forms of unsafePerformIO and unsafeInterleaveIO In-Reply-To: <20080214200055.GB11884@sliver.repetae.net> References: <1202986477.21103.223.camel@localhost> <20080214200055.GB11884@sliver.repetae.net> Message-ID: <1203677472.3076.168.camel@localhost> On Thu, 2008-02-14 at 12:00 -0800, John Meacham wrote: > I mildly prefer 'Idempotent' to 'Dupable'. feels more descriptive to me. > This is even useful in jhc without threading, as expressions can be > marked 'idempotent and cheap' giving the compiler freedom to duplicate > them when it makes sense. It's a fair point. I don't really mind, if other people prefer that name then fine. > However, I am worried about the 'Inline' in the other one, in jhc, > unsafePerformIO is always inlined, it uses a different trick (my > 'dependingOn' primitive) to ensure the world is not unified with another > one. > > Can we come up with a term that describes the difference other than > 'inline' as that is a ghc specific quirk. Mm, you're right, it is ghc specific. The semantics are less to do with inlining (though that's the perf advantage) and more about doing dangerous things with the world token. Can anyone suggest a better name? > incidentally, jhc has another form of unsafePerformIO that does not wrap > its argument in a new exception handler. It can be used when you know > the argument won't raise an ioError or if it does, it handles them > itself. (normal calls to things like error and pattern match failures > are fine. it is just haskell98 io errors that metter for this one) Right, GHC misses this once because it doesn't wrap any in an exception handler since its exception mechanism for IO errors is the same as for 'error'. If you have a good name and documentation then propose it now. Duncan From duncan.coutts at worc.ox.ac.uk Fri Feb 22 06:07:13 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Feb 22 06:07:11 2008 Subject: HTTP haskell package In-Reply-To: References: <47BEA6F7.40608@dfki.de> Message-ID: <1203678433.3076.180.camel@localhost> On Fri, 2008-02-22 at 11:48 +0100, Bjorn Bringert wrote: > Perhaps we could show darcs change logs on hackage. For this we need a > repository field in the .cabal file. Yes, darcs changelog is a start, but it doesn't provide the kind of summary people usually want. Some people write summary changelogs though not many. One fully automatic thing would be a package differ, that looks at all api changes between versions of a package, or if they're only code changes then notes which functions changed. It's not full detail but it'd give package users an indication of whether it's a big api change or only a tweak in one data file. We'll need a package api diff program to help enforce the package versioning policy. Duncan From johan.tibell at gmail.com Fri Feb 22 07:03:41 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri Feb 22 07:01:49 2008 Subject: HTTP haskell package In-Reply-To: <1203678433.3076.180.camel@localhost> References: <47BEA6F7.40608@dfki.de> <1203678433.3076.180.camel@localhost> Message-ID: <90889fe70802220403v3c7ed83ka81a8ddcfc14ec39@mail.gmail.com> On Fri, Feb 22, 2008 at 12:07 PM, Duncan Coutts wrote: > > On Fri, 2008-02-22 at 11:48 +0100, Bjorn Bringert wrote: > > > Perhaps we could show darcs change logs on hackage. For this we need a > > repository field in the .cabal file. > > Yes, darcs changelog is a start, but it doesn't provide the kind of > summary people usually want. It would be nice if you could provided some kind of CHANGES file with a package upload for that summary. -- Johan From john at repetae.net Fri Feb 22 07:19:36 2008 From: john at repetae.net (John Meacham) Date: Fri Feb 22 07:17:42 2008 Subject: Proposal: add new forms of unsafePerformIO and unsafeInterleaveIO In-Reply-To: <47BE98DA.4050400@gmail.com> References: <1202986477.21103.223.camel@localhost> <20080214221809.GA4080@localhost.localdomain> <47BE98DA.4050400@gmail.com> Message-ID: <20080222121936.GA18207@sliver.repetae.net> On Fri, Feb 22, 2008 at 09:41:46AM +0000, Simon Marlow wrote: >> I propose that unsafeDupablePerformIO be renamed to unsafePerformIO, >> since it satisfies all of the properties guaranteed of unsafePerformIO. >> GHC's unsafePerformIO guarantees more, and should be called >> unsafePerformIOAtMostOnce or something. > > That's certainly a defensible position, but I'll present a counter-argument. > > If you've managed to use unsafePerformIO in a way that works on a single > processor, then you will probably be tempted to assume that it will work on > a multiprocessor too. Currently unsafePerformIO tries to make that true > (although it's not foolproof, and it's quite expensive). > > Look at all that stuff in the docs for unsafePeformIO about -fno-cse and > let-floating (I think it goes too far, in fact - if your use of > unsafePerformIO is that fragile then you're doing something wrong). If > unsafePerformIO was the dupable version by default, then all that goes out > of the window if you happen to be running with two threads on an SMP. And > if you're writing a library, you have to assume the worst and go for the > AtMOstOnce version - who would remember to do that? > > Better for the default version to be safe in this respect, IMO. The bugs > we'd get from this would be really hard to track down. Also, unsafePerformIO is in the FFI specification, even though it isn't fully specified with respect to multi-processing I think there was some expectations of what 'unsafePerformIO' meant, for better or worse. John -- John Meacham - ?repetae.net?john? From bulat.ziganshin at gmail.com Fri Feb 22 09:00:48 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Feb 22 09:03:19 2008 Subject: upgrading GHC In-Reply-To: <1203636496.3076.108.camel@localhost> References: <1203590071.3076.41.camel@localhost> <47BD8DF4.3090106@gmail.com> <1203636496.3076.108.camel@localhost> Message-ID: <693385584.20080222170048@gmail.com> Hello Duncan, Friday, February 22, 2008, 2:28:15 AM, you wrote: > In particular I think we need the infrastructure to keep the time > required by distro/platform maintainers to a minimum, otherwise it can > easily turn into a full time job. > I'd like to see an infrastructure where we can define subsets of hackage > packages using fully automatic quality tests. Then further subsets > defined by human review standards and consistent sets of packages that > are tested together. Duncan, i like your concrete and detailed plan, but let's see again on WHAT we want to reach. i think that our goal is two-sided: 1) assemble the GEMS of packages that are guaranteed to work together 2) have some set of "good packages" that meet some quality standards and therefore recommended for usage let's consider practical situation. at Oct2007 ghc 6.8 arrives with LibX 1.0 bundled. authors of other libs started to rewrite their libs to work with LibX 1.0. then, at Dec2007 LibX 2.0 arrives and then some libs was upgraded to take advantage of LibX 2.0. they become incompatible with libs using LibX 1.0 and we got a problem package versioning policy (i prefer to call it HLP) allows us to watch over this problem. as far as every library installed define exact version ranges for its dependencies, it should be easy to determine that LibY 1.0 and LibZ 1.0 cannot be used together because they relies on different (and incompatible) versions of LibX but next goal we want to reach is to PREVENT such situations as much as possible. and this is social problem. in order to solve it we should limit freedom of using new library versions by other libraries which want to be a "good citizens". when ghc 6.8 arrives, all the libraries bundled with it - with their concrete VERSIONS becomes a base for this year's HSL (haskell std libs) set. i.e., LibX 1.0 becomes a part of HSL-2008. LibX 2.0 may arrive next month but this cannot change a situation - once LibX 1.0 was included in HSL-2008, it stays there currently, October GHC version is more a testbed and December version is practical vehicle, so i may propose the following scheme: from Oct to Dec developers port their libs to new GHC (and HSL!) version, and in December we "officially" present HSL-2008 as platform for the practical haskell development of the next year. It's important that main libs that make up a foundation for application programming are updated in limited time. say, GUI developers can't upgrade to ghc 6.8 before GUI lib will be ported. so, in Dec2007 we can advertise HSL-2008 which includes, aside core libs, GUI+DB+Web libs with their concrete versions/features and this becomes std set of libs for application developers in 2008 and we can say not "once we had Streams/Binary/FRP lib but it's lost in times", but "for 2008, we offer GUI, serialization, DB libs which are really work with current GHC version" while it will be great to upgrade main libs before December, it doesn't mean that HSL-2008 is frozen at this moment. it continues to grow by accepting new libs and bug-fixed versions of included libs (keeping the same API). the only thing prohibited is incompatible versions of the same libs (say, LibX 2.0 if LibX 1.0 is already there) and here we go to the second goal mentioned at the beginning - distinguish between high-quality and so-so libs. here we can establish some set of requirements and check them. we can provide 1-5 stars system or anything else BUT even if some library completely lacks docs, doesn't work on windows or even fails unit tests, it still belongs to the HSL-2008 gem if it works with HSL-2008 libs and there is no previous incompatible version of this library already included in HSL-2008. moreover, these conditions may be checked automatically when uploading package to the Hackage, so library may be nominated AUTOMATICALLY to a part of HSL-2008 standard (!), although for practical purposes i think it's better that Hackage just OFFER this and package author AGREE with it when his package becomes ready to this honor This rule doesn't prohibit quick development of libraries and changing their interfaces every next month. these new versions just will be considered as "research" ones, with a user's responsibility to coordinate their versions. i recall Don's phrase "it's easy to use newer ByteString version, just recompile the base lib" :) So, hackage should be able to 1) test that uploaded library MAY be included in HSL-20xx gem 2) provide a checkbox to make this decision 3) show for each library to which HSLs it belongs 4) allow to filter libraries list to show libs in specified HSL 5) -.- that are compatible to specified HSL (including libs whose checkbox(2) was not checked) using list(5) is good if you just need to see all libs compatible with your setup and list(4) provides list of libs which are guaranteed to compatible with any FUTURE version of given HSL next, all core libs should obey HLP and have versions >=1.0. 0.xxx version numbers should be left for experiments without any compatibility guarantees. the same applies to libs on Hackage. i propose to consider any lib uploaded there which has version >=1.0 and uses ranges for its dependencies (i.e. have finite lower and higher bounds) as library obeying HLP overall, i propose to consider library version as technical field designed for computers. if any library developer has his own, non-HLP library versioning policy, he can write these "human versions" into "description" field. this restriction will allow us to automatically track version dependencies without adding new bureaucracy of Cabal fields two more notes: first, Hackage may check each uploaded library that it doesn't use the same module names as existing libs and propose to include it in HSL-xxx only if it doesn't reuse module names of libs that are already in given HSL second, HLP doesn't specify whether new library versions may add *new* modules. if we will allow this, then library functionality may be extended without losing any bit of compatibility with existing software -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From fox at ucw.cz Fri Feb 22 09:05:18 2008 From: fox at ucw.cz (Milan Straka) Date: Fri Feb 22 09:03:24 2008 Subject: Haddock 2.1.0 does not generate inter-module references Message-ID: <20080222140518.GA30160@atrey.karlin.mff.cuni.cz> Hello, I uploaded package lazyarray-0.1.2 into hackageDB. The haddock-generated documentation uses Haddock 2.1.0 [that's written at the bottom of the page]. The inter-module references are broken, including my own [reference to my other modules 'Data.LazyArray.lArray'] and references to array modules ['Data.Array.MArray.unsafeFreeze']. By broken I mean that the whole text Data.LazyArray.lArray is visible and it is not a reference. Whats more, for "Array" type, no references are generated in the type declarations [for class Ix, they are]. Moreover, I referenced "Data.IntMap" and "Data.Map" in the documentation. Some references are generated, but they point to the void [inside mine own package]. Is this because I do not have containers package in base-depends? But I do not depend on that package, I just want to reference it. Have a nice day, Milan Straka PS: I write because you asked for it on the "Upload" page in the Hackage. If you know all this, sorry for bothering :) From duncan.coutts at worc.ox.ac.uk Fri Feb 22 19:50:59 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Feb 22 19:49:07 2008 Subject: HTTP haskell package In-Reply-To: <90889fe70802220403v3c7ed83ka81a8ddcfc14ec39@mail.gmail.com> References: <47BEA6F7.40608@dfki.de> <1203678433.3076.180.camel@localhost> <90889fe70802220403v3c7ed83ka81a8ddcfc14ec39@mail.gmail.com> Message-ID: <1203727859.3076.190.camel@localhost> On Fri, 2008-02-22 at 13:03 +0100, Johan Tibell wrote: > On Fri, Feb 22, 2008 at 12:07 PM, Duncan Coutts > wrote: > > > > On Fri, 2008-02-22 at 11:48 +0100, Bjorn Bringert wrote: > > > > > Perhaps we could show darcs change logs on hackage. For this we need a > > > repository field in the .cabal file. > > > > Yes, darcs changelog is a start, but it doesn't provide the kind of > > summary people usually want. > > It would be nice if you could provided some kind of CHANGES file with > a package upload for that summary. Sure, though realistically we'd not expect many maintainers to take advantage of such a feature unless there were some technical and social mechanism to encourage it. We have to make a tool to enforce the package version policy anyway (for those packages that opt-in) and one would expect that generating change summaries is not much harder. Duncan From ross at soi.city.ac.uk Sun Feb 24 19:35:58 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sun Feb 24 19:34:08 2008 Subject: non-maintainer uploads to hackageDB Message-ID: <20080225003558.GA4579@soi.city.ac.uk> I think we need, perhaps not a policy, but some agreed etiquette regarding uploads to hackageDB. (Please hold off on the technical suggestions until we've decided what behaviour we want.) Personally, I'd rather have all maintainers doing their own uploads. As I user, I'd like to know that someone takes responsibility for the whole of a package I download, including the packaging, and will be available for bug fixes and enhancements (such as making it work with the next GHC release). As this is free software, there's nothing to stop someone forking a package and maintaining their own version. Then as a user I'll need to choose between the two, but I'll still be looking for a maintainer of the whole package. It might be fair to ask that someone creating a fork change the name of the package in some way, to avoid confusion (and eating up the original maintainer's version numbers). This is a different situation from Linux or BSD distributions, where primary releases are repackaged to conform with native conventions. HackageDB is an upstream site, where people can make their own releases, using a common package format (Cabal). (Similarly I don't think we need the pristine+patches setup used by those distributions: maintainers should just take care of the pristine.) From duncan.coutts at worc.ox.ac.uk Mon Feb 25 03:38:30 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Feb 25 03:37:27 2008 Subject: upgrading GHC In-Reply-To: <693385584.20080222170048@gmail.com> References: <1203590071.3076.41.camel@localhost> <47BD8DF4.3090106@gmail.com> <1203636496.3076.108.camel@localhost> <693385584.20080222170048@gmail.com> Message-ID: <1203928711.3076.282.camel@localhost> Bulat, You mention the problem of having a new version of a library with an incompatible change appear where a previous version of that library was included in a platform release. I think a good model to follow here is GNOME's release model. They do major releases on a 6-month schedule. Major releases can introduce new features. For example GNOME 2.20.0 then after each major release they have a number of minor releases eg 2.20.1, 2.20.2, 2.20.3. These are exclusively bug fix releases including updated versions of the packages that were in the original 2.20.0. Those updates are only allowed to fix bugs, not change any APIs. The corresponding concept with a Haskell platform release is that every package is following the package versioning policy and minor/bug-fix platform releases are only allowed to include updates that are api compatible. This is the same way that libraries included with GHC work, that the library apis should be the same between GHC 6.8.0 and 6.8.2. We have only very rarely deviated from that policy. Duncan On Fri, 2008-02-22 at 17:00 +0300, Bulat Ziganshin wrote: > Hello Duncan, > > Friday, February 22, 2008, 2:28:15 AM, you wrote: > > > In particular I think we need the infrastructure to keep the time > > required by distro/platform maintainers to a minimum, otherwise it can > > easily turn into a full time job. > > > I'd like to see an infrastructure where we can define subsets of hackage > > packages using fully automatic quality tests. Then further subsets > > defined by human review standards and consistent sets of packages that > > are tested together. > > Duncan, i like your concrete and detailed plan, but let's see again on > WHAT we want to reach. i think that our goal is two-sided: > > 1) assemble the GEMS of packages that are guaranteed to work together > 2) have some set of "good packages" that meet some quality standards > and therefore recommended for usage > > let's consider practical situation. at Oct2007 ghc 6.8 arrives with > LibX 1.0 bundled. authors of other libs started to rewrite their libs > to work with LibX 1.0. then, at Dec2007 LibX 2.0 arrives and then some > libs was upgraded to take advantage of LibX 2.0. they become > incompatible with libs using LibX 1.0 and we got a problem > > package versioning policy (i prefer to call it HLP) allows us to watch > over this problem. as far as every library installed define exact > version ranges for its dependencies, it should be easy to determine > that LibY 1.0 and LibZ 1.0 cannot be used together because they relies > on different (and incompatible) versions of LibX > > > but next goal we want to reach is to PREVENT such situations as much as > possible. and this is social problem. in order to solve it we should > limit freedom of using new library versions by other libraries which > want to be a "good citizens". when ghc 6.8 arrives, all the libraries > bundled with it - with their concrete VERSIONS becomes a base for this > year's HSL (haskell std libs) set. i.e., LibX 1.0 becomes a part of > HSL-2008. LibX 2.0 may arrive next month but this cannot change a > situation - once LibX 1.0 was included in HSL-2008, it stays there > > currently, October GHC version is more a testbed and December version is > practical vehicle, so i may propose the following scheme: from Oct to > Dec developers port their libs to new GHC (and HSL!) version, and in > December we "officially" present HSL-2008 as platform for the > practical haskell development of the next year. It's important that > main libs that make up a foundation for application programming are > updated in limited time. say, GUI developers can't upgrade to ghc 6.8 > before GUI lib will be ported. so, in Dec2007 we can advertise > HSL-2008 which includes, aside core libs, GUI+DB+Web libs with their > concrete versions/features and this becomes std set of libs for > application developers in 2008 and we can say not "once we had > Streams/Binary/FRP lib but it's lost in times", but "for 2008, we > offer GUI, serialization, DB libs which are really work with current > GHC version" > > while it will be great to upgrade main libs before December, it > doesn't mean that HSL-2008 is frozen at this moment. it continues to > grow by accepting new libs and bug-fixed versions of included libs > (keeping the same API). the only thing prohibited is incompatible > versions of the same libs (say, LibX 2.0 if LibX 1.0 is already there) > > > and here we go to the second goal mentioned at the beginning - > distinguish between high-quality and so-so libs. here we can establish > some set of requirements and check them. we can provide 1-5 stars > system or anything else BUT even if some library completely lacks > docs, doesn't work on windows or even fails unit tests, it still > belongs to the HSL-2008 gem if it works with HSL-2008 libs and there is > no previous incompatible version of this library already included in > HSL-2008. moreover, these conditions may be checked automatically when > uploading package to the Hackage, so library may be nominated > AUTOMATICALLY to a part of HSL-2008 standard (!), although for > practical purposes i think it's better that Hackage just OFFER this > and package author AGREE with it when his package becomes ready to > this honor > > This rule doesn't prohibit quick development of libraries and changing > their interfaces every next month. these new versions just will be > considered as "research" ones, with a user's responsibility to > coordinate their versions. i recall Don's phrase "it's easy to use > newer ByteString version, just recompile the base lib" :) > > > So, hackage should be able to > > 1) test that uploaded library MAY be included in HSL-20xx gem > 2) provide a checkbox to make this decision > 3) show for each library to which HSLs it belongs > 4) allow to filter libraries list to show libs in specified HSL > 5) -.- that are compatible to specified HSL (including libs whose > checkbox(2) was not checked) > > using list(5) is good if you just need to see all libs compatible > with your setup and list(4) provides list of libs which are guaranteed > to compatible with any FUTURE version of given HSL > > > next, all core libs should obey HLP and have versions >=1.0. > 0.xxx version numbers should be left for experiments without any > compatibility guarantees. the same applies to libs on Hackage. i > propose to consider any lib uploaded there which has version >=1.0 and > uses ranges for its dependencies (i.e. have finite lower and > higher bounds) as library obeying HLP > > overall, i propose to consider library version as technical field > designed for computers. if any library developer has his own, > non-HLP library versioning policy, he can write these "human versions" > into "description" field. this restriction will allow us to > automatically track version dependencies without adding new > bureaucracy of Cabal fields > > > two more notes: first, Hackage may check each uploaded library that it > doesn't use the same module names as existing libs and propose to > include it in HSL-xxx only if it doesn't reuse module names of libs > that are already in given HSL > > second, HLP doesn't specify whether new library versions may add *new* > modules. if we will allow this, then library functionality may be > extended without losing any bit of compatibility with existing > software > From lemming at henning-thielemann.de Mon Feb 25 04:33:41 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Feb 25 04:31:39 2008 Subject: Regenerate uploaded package at HackageDB Message-ID: I have uploaded http://hackage.haskell.org/cgi-bin/hackage-scripts/package/probability-0.2.1 and then found that Haddock-2.0 emitted an error, that I did not encounter since I have not upgraded to Haddock-2.0 so far. Now I have uploaded the package again, which shall fix the Haddock problem. However this seems not to trigger the build process again. How to do that? From nominolo at googlemail.com Mon Feb 25 05:21:45 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Mon Feb 25 05:19:48 2008 Subject: Regenerate uploaded package at HackageDB In-Reply-To: References: Message-ID: <9BEECB0A-381E-473A-A1D0-759E02FDB821@googlemail.com> On 25 feb 2008, at 10.33, Henning Thielemann wrote: > > I have uploaded > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ > probability-0.2.1 > and then found that Haddock-2.0 emitted an error, that I did not > encounter since I have not upgraded to Haddock-2.0 so far. Now I have > uploaded the package again, which shall fix the Haddock problem. > However > this seems not to trigger the build process again. How to do that? > Be patient. One server building all the uploads can become a little too much. A distributed architecture for generating those things is being planned. Then we might even get more feedback from other platforms. / Thomas From ben.franksen at online.de Mon Feb 25 15:39:55 2008 From: ben.franksen at online.de (ben.franksen@online.de) Date: Mon Feb 25 15:41:29 2008 Subject: darcs patch: moved docs for old fringeList to new parBuffer Message-ID: <0MKwtQ-1JTkAa1fuC-0005kS@mrelayeu.kundenserver.de> Warning: please review for correctness, as my understanding of this function is rather limited Mon Feb 25 21:36:36 CET 2008 ben.franksen@online.de * moved docs for old fringeList to new parBuffer -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 58159 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/libraries/attachments/20080225/9ac13f86/attachment-0001.bin From ben.franksen at online.de Mon Feb 25 16:03:39 2008 From: ben.franksen at online.de (Ben Franksen) Date: Mon Feb 25 16:05:22 2008 Subject: upgrading GHC References: <1203590071.3076.41.camel@localhost> <47BD8DF4.3090106@gmail.com> <1203636496.3076.108.camel@localhost> <693385584.20080222170048@gmail.com> Message-ID: Bulat Ziganshin wrote: [...excellent proposal snipped...] I think this is a very good idea. Cheers Ben From dons at galois.com Mon Feb 25 16:33:51 2008 From: dons at galois.com (Don Stewart) Date: Mon Feb 25 16:31:53 2008 Subject: darcs patch: moved docs for old fringeList to new parBuffer In-Reply-To: <0MKwtQ-1JTkAa1fuC-0005kS@mrelayeu.kundenserver.de> References: <0MKwtQ-1JTkAa1fuC-0005kS@mrelayeu.kundenserver.de> Message-ID: <20080225213351.GB26115@scytale.galois.com> ben.franksen: > Warning: please review for correctness, as my understanding of > this function is rather limited > > Mon Feb 25 21:36:36 CET 2008 ben.franksen@online.de > * moved docs for old fringeList to new parBuffer Applied, thanks! -- Don From john at repetae.net Tue Feb 26 00:30:13 2008 From: john at repetae.net (John Meacham) Date: Tue Feb 26 00:28:12 2008 Subject: Proposal: add new forms of unsafePerformIO and unsafeInterleaveIO In-Reply-To: <1203677472.3076.168.camel@localhost> References: <1202986477.21103.223.camel@localhost> <20080214200055.GB11884@sliver.repetae.net> <1203677472.3076.168.camel@localhost> Message-ID: <20080226053012.GB5260@sliver.repetae.net> On Fri, Feb 22, 2008 at 10:51:12AM +0000, Duncan Coutts wrote: > > However, I am worried about the 'Inline' in the other one, in jhc, > > unsafePerformIO is always inlined, it uses a different trick (my > > 'dependingOn' primitive) to ensure the world is not unified with another > > one. > > > > Can we come up with a term that describes the difference other than > > 'inline' as that is a ghc specific quirk. > > Mm, you're right, it is ghc specific. The semantics are less to do with > inlining (though that's the perf advantage) and more about doing > dangerous things with the world token. > > Can anyone suggest a better name? hmm.. well the issue is that the world token may be unified with any other use of the world token... this is different than the issue of whole unsafePerformIO actions being unified via CSE. basically in jhc, it is solved by having newworld be of type newWorld__ :: a -> World__ which conjures up a world that depends on its arbitrary first argument, since the world can be made to depend on the argument to unsafePerformIO, it can't be accidentally unified with other occurances of new epheremel worlds. so.. what does it mean when we don't have this? I am not sure.. it sort of depends on what exact IO primitives we call... what it comes down to is "this computation is safe to apply to the same world as any other computation." meaning, it can't change the world in any way (including things like allocating memory). perhaps unsafeImmutableIO, unsafeUnworldlyIO, unsafePristineIO, unsafeInspectIO, unsafeImpotentIO (sort of similar to Idempotent..)? hmm... I dunno. > > > incidentally, jhc has another form of unsafePerformIO that does not wrap > > its argument in a new exception handler. It can be used when you know > > the argument won't raise an ioError or if it does, it handles them > > itself. (normal calls to things like error and pattern match failures > > are fine. it is just haskell98 io errors that metter for this one) > > Right, GHC misses this once because it doesn't wrap any in an exception > handler since its exception mechanism for IO errors is the same as for > 'error'. If you have a good name and documentation then propose it now. It probably isn't worth making portable at the moment as it is rather jhc specific. -- John Meacham - ?repetae.net?john? From rl at cse.unsw.edu.au Tue Feb 26 03:38:36 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Tue Feb 26 03:36:36 2008 Subject: Cabal vs. C++ Message-ID: <47C3D00C.9070109@cse.unsw.edu.au> What is the simplest way to build a Haskell project that uses a C++ library? It needs at least the following from Cabal. - It must know how to compile C++ files. This kind of works by accident if I list those under c-sources since gcc knows what to do with them but this is (a) ugly and (b) doesn't allow me to pass C++-specific options to gcc. - The project must be linked with g++. However, I don't understand how to tell Cabal which linker to use. I got as far as main = defaultMainWithHooks $ defaultUserHooks { hookedPrograms = [Program "ld" (findProgramOnPath "g++") (\_ _ -> return Nothing)] but this doesn't seem to work. configure --with-ld=g++ does, but it's not nice. Is there any simple way of making this work or do I have to use makefiles? Also, is it intentional that Cabal ignores standard environment variables such as CC, CFLAGS etc.? Roman From nominolo at googlemail.com Tue Feb 26 05:58:57 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Tue Feb 26 05:56:56 2008 Subject: Cabal vs. C++ In-Reply-To: <47C3D00C.9070109@cse.unsw.edu.au> References: <47C3D00C.9070109@cse.unsw.edu.au> Message-ID: <6B5E1695-636A-4388-AF5A-CD2EA0CE8796@googlemail.com> On 26 feb 2008, at 09.38, Roman Leshchinskiy wrote: > What is the simplest way to build a Haskell project that uses a C++ > library? It needs at least the following from Cabal. > > - It must know how to compile C++ files. This kind of works by > accident if I list those under c-sources since gcc knows what > to do > with them but this is (a) ugly and (b) doesn't allow me to pass > C++-specific options to gcc. > > - The project must be linked with g++. However, I don't > understand how > to tell Cabal which linker to use. I got as far as > > main = defaultMainWithHooks > $ defaultUserHooks > { hookedPrograms = [Program "ld" (findProgramOnPath "g > ++") > (\_ _ -> return > Nothing)] > > but this doesn't seem to work. configure --with-ld=g++ does, but > it's not nice. > I don't think you need to link with g++. I successfully linked to a C ++ library by adding -fexceptions to the linker options. I used a makefile, but this should work with Cabal as well. > Is there any simple way of making this work or do I have to use > makefiles? Also, is it intentional that Cabal ignores standard > environment variables such as CC, CFLAGS etc.? > > Roman > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries From rl at cse.unsw.edu.au Tue Feb 26 06:09:47 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Tue Feb 26 06:07:47 2008 Subject: Cabal vs. C++ In-Reply-To: <6B5E1695-636A-4388-AF5A-CD2EA0CE8796@googlemail.com> References: <47C3D00C.9070109@cse.unsw.edu.au> <6B5E1695-636A-4388-AF5A-CD2EA0CE8796@googlemail.com> Message-ID: <47C3F37B.7020305@cse.unsw.edu.au> Thomas Schilling wrote: > > On 26 feb 2008, at 09.38, Roman Leshchinskiy wrote: > >> What is the simplest way to build a Haskell project that uses a C++ >> library? It needs at least the following from Cabal. >> >> - It must know how to compile C++ files. This kind of works by >> accident if I list those under c-sources since gcc knows what to do >> with them but this is (a) ugly and (b) doesn't allow me to pass >> C++-specific options to gcc. >> >> - The project must be linked with g++. However, I don't understand how >> to tell Cabal which linker to use. I got as far as >> >> main = defaultMainWithHooks >> $ defaultUserHooks >> { hookedPrograms = [Program "ld" (findProgramOnPath "g++") >> (\_ _ -> return Nothing)] >> >> but this doesn't seem to work. configure --with-ld=g++ does, but >> it's not nice. >> > > I don't think you need to link with g++. I successfully linked to a C++ > library by adding -fexceptions to the linker options. I used a > makefile, but this should work with Cabal as well. Constructors for static objects won't get run unless you link with g++ (which, IIRC, uses collect2 for linking). Just adding -fexceptions isn't enough. As a matter of fact, what I'd really want is to use the standard C++ compiler for linking, whatever that is. Roman From bulat.ziganshin at gmail.com Tue Feb 26 05:04:48 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Feb 26 06:11:07 2008 Subject: Cabal vs. C++ In-Reply-To: <47C3D00C.9070109@cse.unsw.edu.au> References: <47C3D00C.9070109@cse.unsw.edu.au> Message-ID: <557361040.20080226130448@gmail.com> Hello Roman, Tuesday, February 26, 2008, 11:38:36 AM, you wrote: > What is the simplest way to build a Haskell project that uses a C++ > library? i use the following: ghc.exe --make -lstdc++ main.hs lib.o where lib.cpp is compiled by g++ (of course it's not exactly what you've asked for) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From ashley at semantic.org Tue Feb 26 06:25:03 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Tue Feb 26 06:23:26 2008 Subject: [GHC] #974: Add unzipEithers, lefts, rights to Data.Either In-Reply-To: References: <044.771c90fc72736a1914b3f63a62b98bc6@localhost> <053.59bba6fc96d56b1d4eb049045eb70a87@localhost> Message-ID: <47C3F70F.7010504@semantic.org> roconnor@theorem.ca wrote: > If there are no further comments before March 7th, We shall declare that > parititonEithers, lefts, and rights, shall be added to Data.Eithers. Would prefer "partitionEithers". -- Ashley Yakeley From simonmarhaskell at gmail.com Tue Feb 26 06:30:24 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Feb 26 06:28:25 2008 Subject: Storable instance for Complex In-Reply-To: References: <87ve4qxkbw.fsf@59A2.org> <87k5l3ty29.fsf@59A2.org> Message-ID: <47C3F850.2030906@gmail.com> Henning Thielemann wrote: > On Sun, 17 Feb 2008, Jed Brown wrote: > >> On 15 Feb 2008, lemming@henning-thielemann.de wrote: >>> On Fri, 15 Feb 2008, Jed Brown wrote: >>>> I propose that the following instance be added to base: >>>> >>>> instance (RealFloat a, Storable a) => Storable (Complex a) where >>>> sizeOf z = 2 * sizeOf (realPart z) >>>> alignment z = sizeOf (realPart z) >>>> peek p = do >>>> [r,i] <- peekArray 2 (castPtr p) >>>> return (r :+ i) >>>> poke p (r :+ i) = pokeArray (castPtr p) [r,i] >>>> >>>> This instance is binary compatible with C99, C++ and Fortran complex types. >>>> >>>> It is currently needed by at least two independent packages: hmatrix and >>>> fft. Since it is natural for user code to use both of these packages, we >>>> need to move the instance to a common location. >>>> >>>> http://hackage.haskell.org/trac/ghc/ticket/2099 >>> I also need it for signal processing. >> In light of the fact that several packages need this instance, I created >> a package storable-complex (on Hackage) which has the instance in >> Foreign.Storable.Complex. In the interest of enabling our packages to >> play nicely *now*, I would like to encourage everyone needing this >> instance to get it from this common source. When it (hopefully) makes >> it into base, we can use a flag in the .cabal file to get it from base >> instead of this package. > > an instance for pairs would also be nice ... :-) I see the smiley, but just in case you're serious: that's pretty hard to get right. Presumably you want it to match the C struct layout rules according to the C ABI of the current platform, which means implementing the layout rules correctly. Cheers, Simon From duncan.coutts at worc.ox.ac.uk Tue Feb 26 06:47:49 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Feb 26 07:03:41 2008 Subject: H98 Text IO Message-ID: <1204026469.3076.381.camel@localhost> >From the H98 report: All I/O functions defined here are character oriented. [...] These functions cannot be used portably for binary I/O. In the following, recall that String is a synonym for [Char] (Section 6.1.2). So ordinary text Handles are for text, not binary. Char is of course a Unicode code point. The crucial question of course is what encoding of text to use. For the H98 IO functions we cannot set it as a parameter, we have to pick a sensible default. Currently different implementations disagree on that default. Hugs has for some time used the current locale on posix systems (and I'm guessing the current code page on windows). GHC has always used the Latin-1 encoding. These days, most operating systems use a locale/codepage encoding that covers full the Unicode range. So on hugs we get the benefit of that but on GHC we do not. This is endlessly surprising for beginners. They do putStrLn "???????????" and it comes out on their terminal as junk. It also causes problems for serious programs, see for example the recent hand-wringing on cabal-devel. So here is a concrete proposal: * Haskell98 file IO should always use UTF-8. * Haskell98 IO to terminals should use the current locale encoding. The main controversial point I think is whether to always use UTF-8 or always use the current locale or some split as I've suggested. C chose to always go with the current locale. Some people think that was a mistake because the interpretation changes from user to user. For terminals it is more clear cut that the locale is the right choice because that is what the terminal is capable of displaying. Using anything else will produce junk. We can detect if a handle is a terminal when we open it using hIsTerminalDevice. This should be done automatically (and ghc would ghc get it for free because it already does that check to determine default buffering modes). Sockets and pipes would be treated the same as files when opened in the default text mode. The only special case is terminals. The major problem is with code that assumes GHC's Handles are essentially Word8 and layer their own UTF8 or other decoding over the top. The utf8-string package has this problem for example. Such code should be using openBinaryFile because they are reading/writing binary data, not String text. Note that many programs that really need to work with binary file already use openBinaryFile, those that do not are already broken on Windows which does cr/lf conversion on text files which breaks many binary formats (though not utf8). So we have decide which is more painful, keeping a limited text IO system in GHC or breaking some existing programs which assume GHC's current behaviour. Opinions? Please can we keep this discussion to the interpretation of the H98 IO functions and not get into the separate discussion of how we could extend or redesign the whole IO system. This is a questions of what are the right defaults. Duncan From john at repetae.net Tue Feb 26 07:41:49 2008 From: john at repetae.net (John Meacham) Date: Tue Feb 26 07:39:44 2008 Subject: H98 Text IO In-Reply-To: <1204026469.3076.381.camel@localhost> References: <1204026469.3076.381.camel@localhost> Message-ID: <20080226124148.GC5260@sliver.repetae.net> I came to the same conclusions. I think using either the current encoding or utf8 are perfectly reasonable interpretations of the standard. Jhc used to use the current locale always, but now it uses utf8 always as that was easier to make portable to other operating systems. (though current locale support will likely be added back at some point) I think this is a-okay as far as haskell 98 goes. Assuming latin1 without doing an 'openBinaryFile' is certainly not okay in my book. John -- John Meacham - ?repetae.net?john? From ross at soi.city.ac.uk Tue Feb 26 07:44:53 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Feb 26 07:43:02 2008 Subject: H98 Text IO In-Reply-To: <1204026469.3076.381.camel@localhost> References: <1204026469.3076.381.camel@localhost> Message-ID: <20080226124453.GA3140@soi.city.ac.uk> On Tue, Feb 26, 2008 at 11:47:49AM +0000, Duncan Coutts wrote: > The major problem is with code that assumes GHC's Handles are > essentially Word8 and layer their own UTF8 or other decoding over the > top. The utf8-string package has this problem for example. Such code > should be using openBinaryFile because they are reading/writing binary > data, not String text. As I was saying on cabal-devel, I think this distinction ought to be in the types, i.e. we need, in base, a type distinct from Handle that offers a Word8 interface to binary I/O, as a foundation for various experiments with encodings (which need not all be in base). From jules at jellybean.co.uk Tue Feb 26 07:59:21 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Tue Feb 26 07:57:15 2008 Subject: H98 Text IO In-Reply-To: <20080226124453.GA3140@soi.city.ac.uk> References: <1204026469.3076.381.camel@localhost> <20080226124453.GA3140@soi.city.ac.uk> Message-ID: <47C40D29.7040609@jellybean.co.uk> Ross Paterson wrote: > On Tue, Feb 26, 2008 at 11:47:49AM +0000, Duncan Coutts wrote: >> The major problem is with code that assumes GHC's Handles are >> essentially Word8 and layer their own UTF8 or other decoding over the >> top. The utf8-string package has this problem for example. Such code >> should be using openBinaryFile because they are reading/writing binary >> data, not String text. > > As I was saying on cabal-devel, I think this distinction ought to be in > the types, i.e. we need, in base, a type distinct from Handle that offers > a Word8 interface to binary I/O, as a foundation for various experiments > with encodings (which need not all be in base). I agree with a separate handle type, but Duncan's proposal is all about "fixing" the fact that the H98 library doesn't implement the H98 spec. I think that proposal should pass independently. I then think that a System.IO.Binary library, which provides a newtyped Handle for Word8 IO would be an excellent thing to propose next! Jules From duncan.coutts at worc.ox.ac.uk Tue Feb 26 08:07:50 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Feb 26 08:19:13 2008 Subject: H98 Text IO In-Reply-To: <20080226124453.GA3140@soi.city.ac.uk> References: <1204026469.3076.381.camel@localhost> <20080226124453.GA3140@soi.city.ac.uk> Message-ID: <1204031271.3076.388.camel@localhost> On Tue, 2008-02-26 at 12:44 +0000, Ross Paterson wrote: > On Tue, Feb 26, 2008 at 11:47:49AM +0000, Duncan Coutts wrote: > > The major problem is with code that assumes GHC's Handles are > > essentially Word8 and layer their own UTF8 or other decoding over the > > top. The utf8-string package has this problem for example. Such code > > should be using openBinaryFile because they are reading/writing binary > > data, not String text. > > As I was saying on cabal-devel, I think this distinction ought to be in > the types, i.e. we need, in base, a type distinct from Handle that offers > a Word8 interface to binary I/O, as a foundation for various experiments > with encodings (which need not all be in base). I agree. If we can come to a consensus on the interpretation of the H98 text Handles then the next step is to start a discussion on a standard binary IO system (and I'd certainly support using a different type of Handle so we never mix up binary data and [Char]). The main point of difference so far seems to be whether we pick a fixed utf8 encoding or the the current locale encoding or some mixture depending on the kind of IO object. I think that's where we should focus the discussion initially. It'd be nice if there was agreement between the different implementations. It seems we're not far from agreement between at least hugs, ghc and jhc. Ross, perhaps you can put the argument for what hugs currently does - always using the locale for all terminal an text file IO rather than picking a fixed encoding. Duncan From simonmarhaskell at gmail.com Tue Feb 26 08:22:07 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Feb 26 08:20:05 2008 Subject: H98 Text IO In-Reply-To: <1204026469.3076.381.camel@localhost> References: <1204026469.3076.381.camel@localhost> Message-ID: <47C4127F.2020204@gmail.com> Duncan Coutts wrote: >>From the H98 report: > > All I/O functions defined here are character oriented. [...] > These functions cannot be used portably for binary I/O. > > In the following, recall that String is a synonym for [Char] > (Section 6.1.2). > > So ordinary text Handles are for text, not binary. Char is of course a > Unicode code point. > > The crucial question of course is what encoding of text to use. For the > H98 IO functions we cannot set it as a parameter, we have to pick a > sensible default. Currently different implementations disagree on that > default. Hugs has for some time used the current locale on posix systems > (and I'm guessing the current code page on windows). GHC has always used > the Latin-1 encoding. > > These days, most operating systems use a locale/codepage encoding that > covers full the Unicode range. So on hugs we get the benefit of that but > on GHC we do not. > > This is endlessly surprising for beginners. They do > putStrLn "???????????" > and it comes out on their terminal as junk. > > It also causes problems for serious programs, see for example the recent > hand-wringing on cabal-devel. > > So here is a concrete proposal: > > * Haskell98 file IO should always use UTF-8. > * Haskell98 IO to terminals should use the current locale > encoding. While I support Duncan's proposal (we discussed it on IRC), I thought I should point out some of the ramifications of this, and the alternatives. If everything that is not a terminal uses UTF-8 by default, then shell commands may behave in an unexpected way, e.g. for a Haskell program "prog", prog | cat will output in UTF-8, and if your locale encoding is something other than UTF-8 you'll see junk. Similarly, prog >file; cat file will give the same (wrong) result. So some alternatives that fix this are 1. all text I/O is in the locale encoding (what C and Hugs do) 2. stdin/stdout/stderr and terminals are always in the locale encoding, everything else is UTF-8 3. everything is UTF-8 (1) has the advantage of being easy to understand, but causes problems when you want to move a file created on one system to another system, or share files between users. The programmer in this case has to anticipate the problem and set an encoding (and we're not proposing to provide a way to specify encodings, yet, so openBinaryFile and a separate UTF-8 step would be required). (2) has a sort of "do what I want" feel, and will almost certanly cause confusion in some cases, simply because it's an aribtrary choice. (3) is easy to understand, but does the wrong thing for people who have a locale encoding other than UTF-8. Duncan's proposal occupies a useful point: text that we know to be ephemeral, because it is being sent to a terminal, is definitely sent in the user's default encoding. Text that might be persistent or might be crossing a locale-boundary is always written in UTF-8, which is good for interchange and portability, the catch is that sometimes we identify a Handle as persistent when it is really ephemeral. Note that sensible people who set their locale to UTF-8 are not affected by any of this - and that includes most new installations of Linux these days, I believe. Cheers, Simon From rl at cse.unsw.edu.au Tue Feb 26 08:31:43 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Tue Feb 26 08:29:45 2008 Subject: H98 Text IO In-Reply-To: <1204026469.3076.381.camel@localhost> References: <1204026469.3076.381.camel@localhost> Message-ID: <47C414BF.3000302@cse.unsw.edu.au> Duncan Coutts wrote: > > So here is a concrete proposal: > > * Haskell98 file IO should always use UTF-8. > * Haskell98 IO to terminals should use the current locale > encoding. Personally, I'd find this deeply surprising. I don't care that much what locale gets used for I/O (if it matters, you have to deal with it explicitly anyway) as long as it is consistent. I'm probably mistaken, but doesn't this proposal mean that I can't implement cat in H98 using text I/O? That would be a bit disturbing. Also, would this affect the encoding used for file names? If so, how? Roman From ross at soi.city.ac.uk Tue Feb 26 08:33:56 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Feb 26 08:31:52 2008 Subject: H98 Text IO In-Reply-To: <1204031271.3076.388.camel@localhost> References: <1204026469.3076.381.camel@localhost> <20080226124453.GA3140@soi.city.ac.uk> <1204031271.3076.388.camel@localhost> Message-ID: <20080226133356.GB3140@soi.city.ac.uk> On Tue, Feb 26, 2008 at 01:07:50PM +0000, Duncan Coutts wrote: > It'd be nice if there was agreement between the different > implementations. It seems we're not far from agreement between at least > hugs, ghc and jhc. > > Ross, perhaps you can put the argument for what hugs currently does - > always using the locale for all terminal an text file IO rather than > picking a fixed encoding. I'm not going claim it's ideal, but the situation created by Haskell 98 is that Handles are supposed to deal in Chars, but their relationship to external encodings is undefined. Given that, implementations have to make a somewhat arbitrary choice. I suppose the argument for the locale is the UTF-8 has not yet taken over the world. I agree that it's weaker for files and sockets, since they are shared between different systems. I'm not worried about breaking broken programs. I'll just note in passing that similar issues arise with system calls, notably file operations, program arguments and the environment. But I/O is probably sufficient trouble for today. From ross at soi.city.ac.uk Tue Feb 26 08:36:36 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Feb 26 08:34:32 2008 Subject: H98 Text IO In-Reply-To: <47C414BF.3000302@cse.unsw.edu.au> References: <1204026469.3076.381.camel@localhost> <47C414BF.3000302@cse.unsw.edu.au> Message-ID: <20080226133636.GC3140@soi.city.ac.uk> On Wed, Feb 27, 2008 at 12:31:43AM +1100, Roman Leshchinskiy wrote: > I'm probably mistaken, but doesn't this proposal mean that I can't > implement cat in H98 using text I/O? That would be a bit disturbing. That is already the case, at least for binary files. From duncan.coutts at worc.ox.ac.uk Tue Feb 26 08:34:54 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Feb 26 08:41:41 2008 Subject: H98 Text IO In-Reply-To: <47C4127F.2020204@gmail.com> References: <1204026469.3076.381.camel@localhost> <47C4127F.2020204@gmail.com> Message-ID: <1204032894.3076.393.camel@localhost> On Tue, 2008-02-26 at 13:22 +0000, Simon Marlow wrote: > So some alternatives that fix this are > > 1. all text I/O is in the locale encoding (what C and Hugs do) > > 2. stdin/stdout/stderr and terminals are always in the locale > encoding, everything else is UTF-8 I was initially confused about how this one was different from what I first proposed. The difference is that I was suggesting stdin/stdout/stderr be in the locale *only* if thet're connected to a terminal, rather than always. > 3. everything is UTF-8 Personally I'm not really fussed about which compromise we pick. I think the more important point is that all the Haskell implementations pick the same compromise so that we can effectively standardise the behaviour. Duncan From rl at cse.unsw.edu.au Tue Feb 26 08:50:12 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Tue Feb 26 08:48:10 2008 Subject: H98 Text IO In-Reply-To: <20080226133636.GC3140@soi.city.ac.uk> References: <1204026469.3076.381.camel@localhost> <47C414BF.3000302@cse.unsw.edu.au> <20080226133636.GC3140@soi.city.ac.uk> Message-ID: <47C41914.6060205@cse.unsw.edu.au> Ross Paterson wrote: > On Wed, Feb 27, 2008 at 12:31:43AM +1100, Roman Leshchinskiy wrote: >> I'm probably mistaken, but doesn't this proposal mean that I can't >> implement cat in H98 using text I/O? That would be a bit disturbing. > > That is already the case, at least for binary files. Ok, cat is a bad example. Any kind of simple text processing, really, that assumes that reading a character from stdin and writing it to stdout is really just copying. Roman From duncan.coutts at worc.ox.ac.uk Tue Feb 26 08:46:44 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Feb 26 08:49:30 2008 Subject: H98 Text IO In-Reply-To: <47C414BF.3000302@cse.unsw.edu.au> References: <1204026469.3076.381.camel@localhost> <47C414BF.3000302@cse.unsw.edu.au> Message-ID: <1204033604.3076.398.camel@localhost> On Wed, 2008-02-27 at 00:31 +1100, Roman Leshchinskiy wrote: > Duncan Coutts wrote: > > > > So here is a concrete proposal: > > > > * Haskell98 file IO should always use UTF-8. > > * Haskell98 IO to terminals should use the current locale > > encoding. > > Personally, I'd find this deeply surprising. I don't care that much what > locale gets used for I/O (if it matters, you have to deal with it > explicitly anyway) as long as it is consistent. I'm probably mistaken, > but doesn't this proposal mean that I can't implement cat in H98 using > text I/O? That would be a bit disturbing. You've never been able to do that with the guarantees provided by H98. The current base lib provides System.IO.openBinaryFile which does make it possible to implement cat on binary files. > Also, would this affect the encoding used for file names? If so, how? No, that's a separate issue. Duncan From rl at cse.unsw.edu.au Tue Feb 26 09:14:41 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Tue Feb 26 09:12:46 2008 Subject: H98 Text IO In-Reply-To: <1204033604.3076.398.camel@localhost> References: <1204026469.3076.381.camel@localhost> <47C414BF.3000302@cse.unsw.edu.au> <1204033604.3076.398.camel@localhost> Message-ID: <47C41ED1.8020704@cse.unsw.edu.au> Duncan Coutts wrote: > On Wed, 2008-02-27 at 00:31 +1100, Roman Leshchinskiy wrote: >> Duncan Coutts wrote: >>> So here is a concrete proposal: >>> >>> * Haskell98 file IO should always use UTF-8. >>> * Haskell98 IO to terminals should use the current locale >>> encoding. >> Personally, I'd find this deeply surprising. I don't care that much what >> locale gets used for I/O (if it matters, you have to deal with it >> explicitly anyway) as long as it is consistent. I'm probably mistaken, >> but doesn't this proposal mean that I can't implement cat in H98 using >> text I/O? That would be a bit disturbing. > > You've never been able to do that with the guarantees provided by H98. As a matter of fact, 21.10.2 from the Haskell Report suggests that at least copying text files should be possible. Unless I'm mistaken, your proposal would invalidate that example somewhat. This begs another question. What exactly does "current locale" mean, given that we have lazy I/O and the locale can be changed on the fly? >> Also, would this affect the encoding used for file names? If so, how? > > No, that's a separate issue. Hmm, so how do I reliably read a list of file names from a file? Roman From simonmarhaskell at gmail.com Tue Feb 26 09:18:17 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Feb 26 09:16:22 2008 Subject: H98 Text IO In-Reply-To: <47C4127F.2020204@gmail.com> References: <1204026469.3076.381.camel@localhost> <47C4127F.2020204@gmail.com> Message-ID: <47C41FA9.7020104@gmail.com> Simon Marlow wrote: > Duncan Coutts wrote: Let's call this one proposal 0: >> * Haskell98 file IO should always use UTF-8. >> * Haskell98 IO to terminals should use the current locale >> encoding. and the others: > 1. all text I/O is in the locale encoding (what C and Hugs do) > > 2. stdin/stdout/stderr and terminals are always in the locale > encoding, everything else is UTF-8 > > 3. everything is UTF-8 Some other points that came up on IRC: - there's a long precedent for behaving differently when connected to a terminal. For example, 'ls' formats output in columns when connected to a terminal, or displays output in colour. This is a point in favour of (0). - we might expect that "prog file" behaves the same as "prog References: <1204026469.3076.381.camel@localhost> <47C414BF.3000302@cse.unsw.edu.au> <1204033604.3076.398.camel@localhost> <47C41ED1.8020704@cse.unsw.edu.au> Message-ID: <47C42F8A.8010602@gmail.com> Roman Leshchinskiy wrote: > Duncan Coutts wrote: >> On Wed, 2008-02-27 at 00:31 +1100, Roman Leshchinskiy wrote: >>> Also, would this affect the encoding used for file names? If so, how? >> >> No, that's a separate issue. > > Hmm, so how do I reliably read a list of file names from a file? You didn't say what format the file takes, so there are a couple of options. If you get to choose the format, then using read/show is easiest. If you're stuck with a predefined format, say one filename per line, then it depends what system you're on: - on Windows, filenames are Unicode, so the file must be in some encoding: decode it appropriately. - on Unix, filenames are binary, so use openBinaryFile and hGetLine. Yes, this is all broken (in particular FilePath == [Char] is wrong), but at least it's possible to do what you want, and it's not getting any worse with the proposed change. Filenames are something else that need an overhaul, but one thing at a time. Cheers, Simon From john at repetae.net Tue Feb 26 10:28:07 2008 From: john at repetae.net (John Meacham) Date: Tue Feb 26 10:26:02 2008 Subject: H98 Text IO In-Reply-To: <1204032894.3076.393.camel@localhost> References: <1204026469.3076.381.camel@localhost> <47C4127F.2020204@gmail.com> <1204032894.3076.393.camel@localhost> Message-ID: <20080226152807.GD5260@sliver.repetae.net> On Tue, Feb 26, 2008 at 01:34:54PM +0000, Duncan Coutts wrote: > Personally I'm not really fussed about which compromise we pick. I think > the more important point is that all the Haskell implementations pick > the same compromise so that we can effectively standardise the > behaviour. Wait, are you talking about changing what ghc does or trying to change the haskell standard? I always thought ghc should do something more sane with character IO, non unicode aware programs are a blight. I don't think choosing something arbitrary to standardize on is a good idea. It is not always clear what the best choice is. like, for instance until recently, jhc used locale encoding on linux, due to glibc's strong charset support and guarenteed use of unicode wchar_t's, but utf8 always on bsd-varients, where the wchar_t situation was less clear cut. On embedded systems, only supporting ASCII IO is certainly a valid choice. For a .NET backend, we will want to use .NET's native character IO routines. The important thing is standardizing how _binary_ handles work across compilers. As long as everyone has a compatible openBinaryHandle then we can layer whatever we want on it with compatible libraries. I think the current behavior of GHC is poor and should be fixed, I believe the intent of the haskell 98 standard is that character IO be performed in a suitable system specific way, which always truncating to 8bits does not meet IMHO. But no need to prescribe something arbitrary language-wide for a particular issue with ghc. John -- John Meacham - ?repetae.net?john? From bulat.ziganshin at gmail.com Tue Feb 26 10:57:11 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Feb 26 11:16:32 2008 Subject: H98 Text IO In-Reply-To: <47C41FA9.7020104@gmail.com> References: <1204026469.3076.381.camel@localhost> <47C4127F.2020204@gmail.com> <47C41FA9.7020104@gmail.com> Message-ID: <562619263.20080226185711@gmail.com> Hello Simon, Tuesday, February 26, 2008, 5:18:17 PM, you wrote: > Let's call this one proposal 0: > and the others: my program now uses 4 different encodings with a manual reeencoding between them. it seems that any proposal will break it - now it assumes that getChar function just reads 8-bit value and dress it into Char i don't care about other Haskell implementations, but if they need to be unified, it may be better to count code base written with GHC and all other implementations in mind and force all other *hc to use the same (broken) semantics as ghc really, i wonder. afaiu, the phrase "avoid success at any cost" has the same double meaning in English as in Russian and now, when Haskell got real chances to become widely adopted by industry, it seems that we try to avoid it... at any cost -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From simonmarhaskell at gmail.com Tue Feb 26 11:34:50 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Feb 26 11:32:50 2008 Subject: H98 Text IO In-Reply-To: <562619263.20080226185711@gmail.com> References: <1204026469.3076.381.camel@localhost> <47C4127F.2020204@gmail.com> <47C41FA9.7020104@gmail.com> <562619263.20080226185711@gmail.com> Message-ID: <47C43FAA.8020107@gmail.com> Bulat Ziganshin wrote: > Hello Simon, > > Tuesday, February 26, 2008, 5:18:17 PM, you wrote: > >> Let's call this one proposal 0: >> and the others: > > my program now uses 4 different encodings with a manual reeencoding > between them. it seems that any proposal will break it - now it > assumes that getChar function just reads 8-bit value and dress it into > Char Use openBinaryFile (or hSetBinaryMode) and your program will work with all compilers, both before and after this change. > really, i wonder. afaiu, the phrase "avoid success at any cost" > has the same double meaning in English as in Russian and now, > when Haskell got real chances to become widely adopted by industry, it > seems that we try to avoid it... at any cost I don't get it - aren't we improving things by providing support for non-Latin-1 encodings and unifying the compilers? Cheers, Simon From igloo at earth.li Tue Feb 26 12:16:57 2008 From: igloo at earth.li (Ian Lynagh) Date: Tue Feb 26 12:14:51 2008 Subject: H98 Text IO In-Reply-To: <47C41FA9.7020104@gmail.com> References: <1204026469.3076.381.camel@localhost> <47C4127F.2020204@gmail.com> <47C41FA9.7020104@gmail.com> Message-ID: <20080226171657.GA21147@matrix.chaos.earth.li> [dropped g-h-u as this is really a libraries discussion, and cross-posted threads are a pain] On Tue, Feb 26, 2008 at 02:18:17PM +0000, Simon Marlow wrote: > Simon Marlow wrote: > >Duncan Coutts wrote: > > Let's call this one proposal 0: > > >> * Haskell98 file IO should always use UTF-8. > >> * Haskell98 IO to terminals should use the current locale > >> encoding. > > > 1. all text I/O is in the locale encoding (what C and Hugs do) > > > > 2. stdin/stdout/stderr and terminals are always in the locale > > encoding, everything else is UTF-8 > > > > 3. everything is UTF-8 3 is my favourite. It means that if I run ./foo and I want to see exactly what the output was, I can run ./foo | hexdump -C and get something consistent with the first run. 0 breaks the above. 1 means that if you and I both generate a file we don't necessarily get the same file. 2 I don't like for your "prog in" vs "prog < in" reason, and likewise "prog -o out" vs "prog > out". I think it's important that we have some way of sending/getting binary stuff to/from std*, though (and we need to make sure it plays nicely with buffering). Thanks Ian From haskell at list.mightyreason.com Tue Feb 26 12:42:25 2008 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Tue Feb 26 12:40:27 2008 Subject: H98 Text IO In-Reply-To: <1204026469.3076.381.camel@localhost> References: <1204026469.3076.381.camel@localhost> Message-ID: <47C44F81.8070907@list.mightyreason.com> The H98 spec has the inside half of story nailed down: Char is Unicode, and Handles are text I/O that deal in [Char]. The outside half of the story is the binary encoding of the [Char], which was unspecified, and left to the implementation. The implementation dependence allows GHC to create a "setHandleEncoding" (or "withHandleEncoding") operation. [I do not want to get bogged down in syntax]. This is something that, like all details of encoding, is not the H98 spec. In addition, there may be some command line parameters to GHC. Imagine that GHC 6.10.1 is released with encoding support. If the user runs ghc with no options or setup changes, then the new defaults will apply. The goal is that more complicated situations are reflected in more complicated "ghc" or "main" invocations. The least complicated usage defaults to being identical cross-platform and regardless of terminal I/O. I think the best default would be UTF8 for all text handles. This can be easily documented, it can be easily understood, and will produce the fewest suprises. I imagine that in this proposed ghc-6.10.1: * GHC's handles now carry an encoding parameter. ** There is a way to create a new handle from an old one that differs only in the encoding. (perhaps 'hNew <- cloneHandleWithEncoding "Latin1" hOld') * GHC's has mutable global variables that control the encoding parameter of new handles. ** Unless influenced by command-line switches, these default to UTF8. ** There are IO commands to read & write these global variables. ** There are different defaults for new terminal I/O handles and other I/O handles, so they could be given different encodings. If you want to use the "local" or native encoding, then compile with "ghc --local-encoding" or start the program with something like "main = handlesUseLocalEncoding >> do ..." If you want to use "Latin1" then use either "ghc --encoding Latin1" or "main = handlesUseEncoding "Latin1" >> do ..." To compile older programs one could use "ghc --compat 6.8" or "ghc --encoding Latin1" to access the old defaults. One might even add "+RTS --encoding Latin1 -RTS" runtime options to set the initial encoding. Though I think this is unlikely to be useful in practice. I think that having terminal I/O be special is great for command line applications. But the nice behavior of such applications like "ls" must not determine what the GHC runtime does by default. From bulat.ziganshin at gmail.com Tue Feb 26 12:51:04 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Feb 26 14:33:02 2008 Subject: H98 Text IO In-Reply-To: <47C43FAA.8020107@gmail.com> References: <1204026469.3076.381.camel@localhost> <47C4127F.2020204@gmail.com> <47C41FA9.7020104@gmail.com> <562619263.20080226185711@gmail.com> <47C43FAA.8020107@gmail.com> Message-ID: <1957364505.20080226205104@gmail.com> Hello Simon, Tuesday, February 26, 2008, 7:34:50 PM, you wrote: > Use openBinaryFile (or hSetBinaryMode) and your program will work with all > compilers, both before and after this change. it is what i mean - we just have found one more way to break compatibility with existing haskell code. it is important part of our efforts to keep haskell community as small as possible, ideally it should include just authors of haskell tools itself >> really, i wonder. afaiu, the phrase "avoid success at any cost" >> has the same double meaning in English as in Russian and now, >> when Haskell got real chances to become widely adopted by industry, it >> seems that we try to avoid it... at any cost > I don't get it - aren't we improving things by providing support for > non-Latin-1 encodings and unifying the compilers? this will improve things only for haskell novices. real men (including yourself) are already adopted various ways to live with it i again highlight that if we want to put ghc into industrial use, it should keep compatibility with old versions -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Tue Feb 26 12:41:13 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Feb 26 14:39:14 2008 Subject: H98 Text IO In-Reply-To: <20080226171657.GA21147@matrix.chaos.earth.li> References: <1204026469.3076.381.camel@localhost> <47C4127F.2020204@gmail.com> <47C41FA9.7020104@gmail.com> <20080226171657.GA21147@matrix.chaos.earth.li> Message-ID: <1710342328.20080226204113@gmail.com> Hello Ian, Tuesday, February 26, 2008, 8:16:57 PM, you wrote: >> > 3. everything is UTF-8 > 3 is my favourite. It means that if I run just to let you know - default encoding for Windows console windows is OEM. to make things funnier, getArgs returns strings in ANSI and openFile uses ANSI strings too -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From johan.tibell at gmail.com Tue Feb 26 14:55:53 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue Feb 26 14:53:49 2008 Subject: H98 Text IO In-Reply-To: <1957364505.20080226205104@gmail.com> References: <1204026469.3076.381.camel@localhost> <47C4127F.2020204@gmail.com> <47C41FA9.7020104@gmail.com> <562619263.20080226185711@gmail.com> <47C43FAA.8020107@gmail.com> <1957364505.20080226205104@gmail.com> Message-ID: <90889fe70802261155i5b2be148qefe43a93baf1e5c@mail.gmail.com> On Tue, Feb 26, 2008 at 6:51 PM, Bulat Ziganshin wrote: > Hello Simon, > > > Tuesday, February 26, 2008, 7:34:50 PM, you wrote: > > > Use openBinaryFile (or hSetBinaryMode) and your program will work with all > > compilers, both before and after this change. > > it is what i mean - we just have found one more way to break > compatibility with existing haskell code. it is important part of our > efforts to keep haskell community as small as possible, ideally it > should include just authors of haskell tools itself Python 3000 is backwards incompatible with many current Python programs. I don't expect lots of Pythonistas to jump ship because of it. In the process of thinking about what should go into Python 3000 they recognized that breaking backwards compatibility was necessary to fix some problems (e.g. the same Unicode problems as we have in the Haskell community.) Agreed, you don't want to continuously break people's programs but I think it's OK to sometimes do it if it's really needed for the long-term usefulness of the language. We should look at the Python community and try to provide an as smooth upgrade path as possible. One possibility is to keep old compilers around for a time. -- Johan From duncan.coutts at worc.ox.ac.uk Tue Feb 26 16:15:49 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Feb 26 16:15:27 2008 Subject: H98 Text IO In-Reply-To: <20080226152807.GD5260@sliver.repetae.net> References: <1204026469.3076.381.camel@localhost> <47C4127F.2020204@gmail.com> <1204032894.3076.393.camel@localhost> <20080226152807.GD5260@sliver.repetae.net> Message-ID: <1204060549.3076.408.camel@localhost> On Tue, 2008-02-26 at 07:28 -0800, John Meacham wrote: > On Tue, Feb 26, 2008 at 01:34:54PM +0000, Duncan Coutts wrote: > > Personally I'm not really fussed about which compromise we pick. I think > > the more important point is that all the Haskell implementations pick > > the same compromise so that we can effectively standardise the > > behaviour. > > Wait, are you talking about changing what ghc does or trying to change > the haskell standard? I always thought ghc should do something more sane > with character IO, non unicode aware programs are a blight. > > I don't think choosing something arbitrary to standardize on is a good > idea. It is not always clear what the best choice is. like, for instance > until recently, jhc used locale encoding on linux, due to glibc's strong > charset support and guarenteed use of unicode wchar_t's, but utf8 always > on bsd-varients, where the wchar_t situation was less clear cut. On > embedded systems, only supporting ASCII IO is certainly a valid choice. > For a .NET backend, we will want to use .NET's native character IO > routines. Oh I wasn't trying to pin it down that much. If you want to use ebdic on some embedded platform by default I don't care. I really mean that it'd be nice if hugs, ghc, jhcm nhc98 etc could agree for each of the major platforms, Linux/Unix, OS X and Windows. And I don't mean necessarily that they should do the same thing across platforms (eg as I understand it OS X would always use UTF8 not a variable locale) just that they should do the same on the same platform. So not a change of the H98 spec, just a common consensus on the major platforms. Duncan From duncan.coutts at worc.ox.ac.uk Tue Feb 26 16:24:55 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Feb 26 16:22:54 2008 Subject: H98 Text IO In-Reply-To: <47C41ED1.8020704@cse.unsw.edu.au> References: <1204026469.3076.381.camel@localhost> <47C414BF.3000302@cse.unsw.edu.au> <1204033604.3076.398.camel@localhost> <47C41ED1.8020704@cse.unsw.edu.au> Message-ID: <1204061095.3076.418.camel@localhost> On Wed, 2008-02-27 at 01:14 +1100, Roman Leshchinskiy wrote: > Duncan Coutts wrote: > > On Wed, 2008-02-27 at 00:31 +1100, Roman Leshchinskiy wrote: > >> I'm probably mistaken, > >> but doesn't this proposal mean that I can't implement cat in H98 using > >> text I/O? That would be a bit disturbing. > > > > You've never been able to do that with the guarantees provided by H98. > > As a matter of fact, 21.10.2 from the Haskell Report suggests that at > least copying text files should be possible. Unless I'm mistaken, your > proposal would invalidate that example somewhat. > This begs another question. What exactly does "current locale" mean, > given that we have lazy I/O and the locale can be changed on the fly? The current locale is a Posix concept. There are posix functions for changing it. I'd suggest that a Handle inherits the current locale as its encoding at the point of creation of the Handle. Further changes to the posix locale would not change any existing open Handles. If we were to provide an action to change the encoding of an open Handle then it is clear that it cannot act on semi-closed handles. That'd make lazy IO ok. From duncan.coutts at worc.ox.ac.uk Tue Feb 26 16:28:43 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Feb 26 16:27:59 2008 Subject: H98 Text IO In-Reply-To: <47C41914.6060205@cse.unsw.edu.au> References: <1204026469.3076.381.camel@localhost> <47C414BF.3000302@cse.unsw.edu.au> <20080226133636.GC3140@soi.city.ac.uk> <47C41914.6060205@cse.unsw.edu.au> Message-ID: <1204061323.3076.422.camel@localhost> On Wed, 2008-02-27 at 00:50 +1100, Roman Leshchinskiy wrote: > Ross Paterson wrote: > > On Wed, Feb 27, 2008 at 12:31:43AM +1100, Roman Leshchinskiy wrote: > >> I'm probably mistaken, but doesn't this proposal mean that I can't > >> implement cat in H98 using text I/O? That would be a bit disturbing. > > > > That is already the case, at least for binary files. > > Ok, cat is a bad example. Any kind of simple text processing, really, > that assumes that reading a character from stdin and writing it to > stdout is really just copying. Well it would copy valid text files, possibly with some normalisation in encoding. Duncan From david at loisch.de Tue Feb 26 17:40:28 2008 From: david at loisch.de (David Leuschner) Date: Tue Feb 26 17:38:31 2008 Subject: H98 Text IO In-Reply-To: <1204060549.3076.408.camel@localhost> References: <1204026469.3076.381.camel@localhost> <47C4127F.2020204@gmail.com> <1204032894.3076.393.camel@localhost> <20080226152807.GD5260@sliver.repetae.net> <1204060549.3076.408.camel@localhost> Message-ID: <20080226224028.GA6371@holst> > I really mean that it'd > be nice if hugs, ghc, jhcm nhc98 etc could agree for each of the major > platforms, Linux/Unix, OS X and Windows. And I don't mean necessarily > that they should do the same thing across platforms (eg as I understand > it OS X would always use UTF8 not a variable locale) just that they > should do the same on the same platform. That's exactly what I (an employee developing commercially used Haskell applications) would like to see. Java does the same thing and it always works as expected and that's always best. Java has a platform default encoding which is not fixed (on Linux it's dependent on the current locale as set by the LC_CTYPE, LC_ALL or LANG environment variables) but is determined in a way consistent with the platform. The platform default encoding is only used if no other encoding is explicitly given. In general when considering industrial adoption it's probably always a good idea to have a look at Java. We've never had (real) problems with Java programs, but lots of problems with Python, Haskell and Ocaml. If I write simple program just printing a non-ASCII string to the terminal or to a file I'd expect that I can read it on the screen or using my favorite text editor without having change anything -- neither in my terminal nor in my program. When I run the program on my platform don't mind if somebody else might get differently encoded output from the same program as long as I get what I expect. If I as a programmer really want to make sure that everybody gets the same output I can make sure a specific encoding is used. Cheers, David -- David Leuschner Meisenweg 7 79211 Denzlingen Tel. 07666/912466 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/libraries/attachments/20080226/32d8911f/attachment.bin From duncan.coutts at worc.ox.ac.uk Tue Feb 26 19:06:59 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Feb 26 19:04:52 2008 Subject: H98 Text IO In-Reply-To: <47C41FA9.7020104@gmail.com> References: <1204026469.3076.381.camel@localhost> <47C4127F.2020204@gmail.com> <47C41FA9.7020104@gmail.com> Message-ID: <1204070819.3076.490.camel@localhost> On Tue, 2008-02-26 at 14:18 +0000, Simon Marlow wrote: > Simon Marlow wrote: > > Duncan Coutts wrote: > > Let's call this one proposal 0: > > >> * Haskell98 file IO should always use UTF-8. > >> * Haskell98 IO to terminals should use the current locale > >> encoding. > > and the others: > > > 1. all text I/O is in the locale encoding (what C and Hugs do) > > > > 2. stdin/stdout/stderr and terminals are always in the locale > > encoding, everything else is UTF-8 > > > > 3. everything is UTF-8 So it's clear that all these solutions have some downsides. We have to decide what is more important. Let me try and summarise: basically we can be consistent with the OS environment or consistent with other Haskell systems in other environments or try to get some mixture of the two. It is pretty clear however that trying to get a mixture still leads to some inconsistency with the OS environment. * "status quo" (what ghc/hugs do now) This gives consistency with the OS environment with hugs and jhc but not ghc, nhc or yhc. It gives consistency between haskell programs (using the same haskell implementation) on different platforms for ghc and nhc but not for hugs or jhc. There is no consistency between haskell implementations. * "always locale" (solution 1 above) This gives us consistency with the OS environment. All of the shell snippets people have posted work with this. The main disadvantage is that files moved between systems may be interpreted differently. * "always utf8" (solution 3 above) This gives consistency between Haskell programs across platforms. The main disadvantage is that it is very unhelpful if the locale is not UTF8. It fails the "putStr" test of printing string literals to the terminal. * "mixture A" (solution 0 above) The input/output format changes depending on the device. prog | cat prints junk in non-UTF8 locales. * "mixture B" (solution 2 above) The output format changes depending on the device. prog in behaves differently to prog < in. And some example people have noted: * putStr "???????????" That is just printing a string literal to the console/terminal. Now that major implementations support Unicode .hs source files it's kind of nice if this works. This works with "always locale" and "mixture A" and "mixture B" above. This fails for "status quo" with ghc (but works for hugs) and fails for "always utf8" unless the locale happens to be utf8. * ./prog vs ./prog | cat That is, piping the output of a haskell program through cat and printing the result to a terminal produces the same output as displaying the program output directly. This works with "always locale" and "mixture B" and fails with "mixture A". With "always utf8" and with "status quo" it has the property that it consistently produces the same junk on the terminal which some people see as a bonus (when not in a utf8 or latin1 locale respectively). * ./prog vs ./prog >file; cat file This is another variation on the above and it has the same failures. * ./prog in vs ./prog < in That is reading a file given as a command line arg via readFile gives the same result as reading stdin that has been redirected from a the same file. This works with "always locale" and "mixture A" and fails with "mixture B". This is the dual of the previous two examples. This fails with "always utf8" and with "status quo" when the file was produced by another text processing program from the same environment (eg a generic text editor). * ./foo vs ./foo | hexdump -C The output bytes we get sent to the terminal is exactly the same as what we see piped to a program to examine those bytes. This fails for "mixture A" and works for all the others. Works in the strict sense that the bytes are the same, not in the sense that the text output is readable. So the problem with the mixture approaches is that the terminal and files and pipes are all really interchangeable so we can find surprising inconsistencies within the same OS environment. The problem with the "always utf8" is that it's never right unless the locale is set to utf8. As a data point, Java and python use "always locale" as default if you don't specify an encoding when opening a text stream. I think personally I'm coming round to the "always locale" point of view. We already have no cross-platform consistency for text files because of the lf vs cr/lf issue and we have no cross-implementation consistency. Duncan From droundy at darcs.net Tue Feb 26 19:30:08 2008 From: droundy at darcs.net (David Roundy) Date: Tue Feb 26 19:28:02 2008 Subject: H98 Text IO In-Reply-To: <1204070819.3076.490.camel@localhost> References: <1204026469.3076.381.camel@localhost> <47C4127F.2020204@gmail.com> <47C41FA9.7020104@gmail.com> <1204070819.3076.490.camel@localhost> Message-ID: <20080227003007.GF17316@darcs.net> On Wed, Feb 27, 2008 at 12:06:59AM +0000, Duncan Coutts wrote: > I think personally I'm coming round to the "always locale" point of > view. We already have no cross-platform consistency for text files > because of the lf vs cr/lf issue and we have no cross-implementation > consistency. I'm leaning in the same direction. -- David Roundy Department of Physics Oregon State University From duncan.coutts at worc.ox.ac.uk Tue Feb 26 19:31:48 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Feb 26 19:29:41 2008 Subject: Cabal vs. C++ In-Reply-To: <47C3D00C.9070109@cse.unsw.edu.au> References: <47C3D00C.9070109@cse.unsw.edu.au> Message-ID: <1204072308.3076.514.camel@localhost> On Tue, 2008-02-26 at 19:38 +1100, Roman Leshchinskiy wrote: > What is the simplest way to build a Haskell project that uses a C++ > library? It needs at least the following from Cabal. > > - It must know how to compile C++ files. This kind of works by > accident if I list those under c-sources since gcc knows what to do > with them but this is (a) ugly and (b) doesn't allow me to pass > C++-specific options to gcc. That's doable. To do it properly we'd have to add c++-sources and c ++-options fields. There's the question of how many languages we want to add support for in this style. > - The project must be linked with g++. However, I don't understand how > to tell Cabal which linker to use. That's a real pain. This kind of thing is never going to scale. When we want to link in objective C code do we have to link using that compiler? What if we're making a Haskell library rather than a program that needs a C++ lib, do we have to remember that every program that uses that Haskell package has to be linked using g++ rather than gcc? Then it's really easy to get into the situation that different linkers are needed if some program directly or indirectly depends on two packages that want different linkers. It's a big ugly mess. A hack that should work for an executable is: ghc-options: -pgml g++ > Also, is it intentional that Cabal ignores standard > environment variables such as CC, CFLAGS etc.? CC yes. CFLAGS not exactly. See: http://hackage.haskell.org/trac/hackage/ticket/221 The reason for ignoring CC is that we use ghc as the C compiler and linker. In future we may switch to using the system C compiler to compile C code in which case we may want to pick up CC. http://hackage.haskell.org/trac/hackage/ticket/229 however we'd still use ghc as the linker. Duncan From rl at cse.unsw.edu.au Tue Feb 26 19:50:54 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Tue Feb 26 19:48:52 2008 Subject: Cabal vs. C++ In-Reply-To: <1204072308.3076.514.camel@localhost> References: <47C3D00C.9070109@cse.unsw.edu.au> <1204072308.3076.514.camel@localhost> Message-ID: <47C4B3EE.6020805@cse.unsw.edu.au> Duncan Coutts wrote: > On Tue, 2008-02-26 at 19:38 +1100, Roman Leshchinskiy wrote: >> What is the simplest way to build a Haskell project that uses a C++ >> library? It needs at least the following from Cabal. >> >> - It must know how to compile C++ files. This kind of works by >> accident if I list those under c-sources since gcc knows what to do >> with them but this is (a) ugly and (b) doesn't allow me to pass >> C++-specific options to gcc. > > That's doable. To do it properly we'd have to add c++-sources and c > ++-options fields. There's the question of how many languages we want to > add support for in this style. I'd vote for none (not even C). Something extensible would be vastly preferable. >> - The project must be linked with g++. However, I don't understand how >> to tell Cabal which linker to use. > > That's a real pain. This kind of thing is never going to scale. When we > want to link in objective C code do we have to link using that compiler? > What if we're making a Haskell library rather than a program that needs > a C++ lib, do we have to remember that every program that uses that > Haskell package has to be linked using g++ rather than gcc? Then it's > really easy to get into the situation that different linkers are needed > if some program directly or indirectly depends on two packages that want > different linkers. It's a big ugly mess. I agree wholeheartedly, but it's a mess we have to live with. > A hack that should work for an executable is: > ghc-options: -pgml g++ Ok, thanks. Roman From david at loisch.de Wed Feb 27 02:33:58 2008 From: david at loisch.de (David Leuschner) Date: Wed Feb 27 02:32:01 2008 Subject: H98 Text IO In-Reply-To: <1204070819.3076.490.camel@localhost> References: <1204026469.3076.381.camel@localhost> <47C4127F.2020204@gmail.com> <47C41FA9.7020104@gmail.com> <1204070819.3076.490.camel@localhost> Message-ID: <20080227073358.GB6257@holst> > Let me try and summarise: Thanks for the great summary! And thanks to Emacs' table mode here're the results displayed as a table: +--------------------------------+-----+--------+------+-------+-------+ | | now | locale | utf8 | mix-A | mix-B | +--------------------------------+-----+--------+------+-------+-------+ | putStrLn "..." | - | ok | - | ok | ok | +--------------------------------+-----+--------+------+-------+-------+ | ./prog vs ./prog | cat | ok | ok | ok | - | ok | +--------------------------------+-----+--------+------+-------+-------+ | ./prog in vs ./prog < in | - | ok | - | ok | - | +--------------------------------+-----+--------+------+-------+-------+ | ./prog vs ./prog | hexdump -C | ok | ok | ok | - | ok | +--------------------------------+-----+--------+------+-------+-------+ The mixtures are good ideas but can give inconsistent and suriprising results (especially when debugging encoding issues). And if our CEO would have known that ... putStrLn ... doesn't work he'd have probably ruled out Haskell right from the start. Even "utf8" gives surprising results: I'd be very surprised if my Mac-written Haskell program outputs junk on Windows or Linux even if the byte sequence is exactly the same UTF-8 text. Personally I think consistency on a single platform is more important than trying to achieve cross-platform consistency which involves a lot more than just encoding. If you've reached that point with your program you're probably anyway using "advanced functions" to exactly specify what will be output. Following "the principle of least surprise" is also a good idea. Cheers, David -- David Leuschner Meisenweg 7 79211 Denzlingen Tel. 07666/912466 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/libraries/attachments/20080227/d6be80e9/attachment.bin From haskell at list.mightyreason.com Wed Feb 27 03:54:17 2008 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Wed Feb 27 03:52:13 2008 Subject: H98 Text IO In-Reply-To: <20080227073358.GB6257@holst> References: <1204026469.3076.381.camel@localhost> <47C4127F.2020204@gmail.com> <47C41FA9.7020104@gmail.com> <1204070819.3076.490.camel@localhost> <20080227073358.GB6257@holst> Message-ID: <47C52539.2060307@list.mightyreason.com> Small correction: I think "./prog in vs ./prog < in " and "utf8" should be "ok". (and I thought this was switched to Glasgow-haskell-users@haskell.org) David Leuschner wrote: >> Let me try and summarise: > > Thanks for the great summary! And thanks to Emacs' table mode here're the > results displayed as a table: > > +--------------------------------+-----+--------+------+-------+-------+ > | | now | locale | utf8 | mix-A | mix-B | > +--------------------------------+-----+--------+------+-------+-------+ > | putStrLn "..." | - | ok | - | ok | ok | > +--------------------------------+-----+--------+------+-------+-------+ > | ./prog vs ./prog | cat | ok | ok | ok | - | ok | > +--------------------------------+-----+--------+------+-------+-------+ > | ./prog in vs ./prog < in | - | ok | - | ok | - | > +--------------------------------+-----+--------+------+-------+-------+ > | ./prog vs ./prog | hexdump -C | ok | ok | ok | - | ok | > +--------------------------------+-----+--------+------+-------+-------+ > > > The mixtures are good ideas but can give inconsistent and suriprising > results (especially when debugging encoding issues). And if our CEO would > have known that ... putStrLn ... doesn't work he'd have > probably ruled out Haskell right from the start. Even "utf8" gives > surprising results: I'd be very surprised if my Mac-written Haskell > program outputs junk on Windows or Linux even if the byte sequence is > exactly the same UTF-8 text. > > Personally I think consistency on a single platform is more important than > trying to achieve cross-platform consistency which involves a lot more > than just encoding. If you've reached that point with your program you're > probably anyway using "advanced functions" to exactly specify what will be > output. Following "the principle of least surprise" is also a good idea. > > Cheers, > > David > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries From simonmarhaskell at gmail.com Wed Feb 27 04:10:19 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Feb 27 04:08:15 2008 Subject: darcs patch: [PROOF OF CONCEPT] build readline package with libedit In-Reply-To: <47BD8585.4070206@dfki.de> References: <6d74b0d20801080838p5763ea07uf1bc8a16e21b6e08@mail.gmail.com> <1203420662.2102.55.camel@localhost> <47BAE62A.7090202@dfki.de> <200802191252.09847.robdockins@fastmail.fm> <47BB2187.9070106@dfki.de> <6d74b0d20802191359s1ff7cd36h477deaa61319ddcb@mail.gmail.com> <47BD76B0.3010002@gmail.com> <47BD8585.4070206@dfki.de> Message-ID: <47C528FB.9060706@gmail.com> Christian Maeder wrote: > Simon Marlow wrote: >> Judah Jacobson wrote: >>> I've actually put together a readline-compat package like you described: >>> >>> http://code.haskell.org/readline-compat >> This is not the way to go, IMO. As Manuel said, we don't want packages >> with licenses that depend on the way the package is built. The >> readline-compat package above has this problem, and the only way to fix >> it is to make its license GPL. But presumably that's exactly what you >> don't want to do, because the purpose of using editline is to avoid the >> GPL. > > My major aim was to avoid that users of our software need to install the > GNUReadline.framework (or libreadline) on their macs (although we could > probably also link libreadline and libncurses statically.) As far as I can see, you don't need a package with a variant license in order to do what you want. The package in question just has an option to use editline instead of readline at build-time. If you want to make life even easier, do as was suggested before and add a module with a single compatible API to both editline and readline, so clients can use the same API regardless of which package they link against. >> Packages which want to use either editline or readline should say so in >> their .cabal files, we cannot abstract this choice into a package of its >> own. > > You also abstract the choice between windows and unix. Doesn't that have > license implications, too? I'm not aware of any license implications - what problem specifically are you referring to? Cheers, Simon From johan.tibell at gmail.com Wed Feb 27 04:25:39 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed Feb 27 04:23:32 2008 Subject: H98 Text IO In-Reply-To: <1204070819.3076.490.camel@localhost> References: <1204026469.3076.381.camel@localhost> <47C4127F.2020204@gmail.com> <47C41FA9.7020104@gmail.com> <1204070819.3076.490.camel@localhost> Message-ID: <90889fe70802270125l11b765b9pb936412df7687f73@mail.gmail.com> On Wed, Feb 27, 2008 at 1:06 AM, Duncan Coutts wrote: > As a data point, Java and python use "always locale" as default if you > don't specify an encoding when opening a text stream. > > I think personally I'm coming round to the "always locale" point of > view. We already have no cross-platform consistency for text files > because of the lf vs cr/lf issue and we have no cross-implementation > consistency. I think following Java and Python in this matter is a good idea and leads to fewer surprises for developers. If you want files created on one machine to work on another you have to be explicit about encoding. -- Johan From Christian.Maeder at dfki.de Wed Feb 27 04:49:51 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Feb 27 04:47:43 2008 Subject: darcs patch: [PROOF OF CONCEPT] build readline package with libedit In-Reply-To: <47C528FB.9060706@gmail.com> References: <6d74b0d20801080838p5763ea07uf1bc8a16e21b6e08@mail.gmail.com> <1203420662.2102.55.camel@localhost> <47BAE62A.7090202@dfki.de> <200802191252.09847.robdockins@fastmail.fm> <47BB2187.9070106@dfki.de> <6d74b0d20802191359s1ff7cd36h477deaa61319ddcb@mail.gmail.com> <47BD76B0.3010002@gmail.com> <47BD8585.4070206@dfki.de> <47C528FB.9060706@gmail.com> Message-ID: <47C5323F.7000601@dfki.de> Simon Marlow wrote: > As far as I can see, you don't need a package with a variant license in > order to do what you want. The package in question just has an option > to use editline instead of readline at build-time. I'm not the license expert. I did not invent a "variant license". GPL seems to be fine for me in all cases. > If you want to make life even easier, do as was suggested before and add > a module with a single compatible API to both editline and readline, so > clients can use the same API regardless of which package they link against. Currently, I'm happy with Rob Dockins's Shellac-compatline. >> You also abstract the choice between windows and unix. Doesn't that have >> license implications, too? > > I'm not aware of any license implications - what problem specifically > are you referring to? No specific problem. Can I freely link against all the window dlls regarding file access (and thus for the Prelude) of package win32? Cheers Christian From aljee at hyper.cx Wed Feb 27 06:22:40 2008 From: aljee at hyper.cx (Takano Akio) Date: Wed Feb 27 06:20:34 2008 Subject: H98 Text IO In-Reply-To: <1204070819.3076.490.camel@localhost> References: <1204026469.3076.381.camel@localhost> <47C4127F.2020204@gmail.com> <47C41FA9.7020104@gmail.com> <1204070819.3076.490.camel@localhost> Message-ID: <20080227202240.51e8e904.aljee@hyper.cx> Duncan Coutts wrote: > Let me try and summarise: > > basically we can be consistent with the OS environment or consistent > with other Haskell systems in other environments or try to get some > mixture of the two. It is pretty clear however that trying to get a > mixture still leads to some inconsistency with the OS environment. I would vote for "always locale". If one starts up an editor, types some text and saves it, it is probably in the locale's encoding. A user will be surprised if a Haskell program fails to read the resulting file. Also, being consistent with C and Java means both users and developers are likely to be familiar with the behavior. Regards, Takano Akio From duncan.coutts at worc.ox.ac.uk Wed Feb 27 06:51:24 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Feb 27 06:49:36 2008 Subject: H98 Text IO In-Reply-To: <47C52539.2060307@list.mightyreason.com> References: <1204026469.3076.381.camel@localhost> <47C4127F.2020204@gmail.com> <47C41FA9.7020104@gmail.com> <1204070819.3076.490.camel@localhost> <20080227073358.GB6257@holst> <47C52539.2060307@list.mightyreason.com> Message-ID: <1204113085.3076.531.camel@localhost> On Wed, 2008-02-27 at 08:54 +0000, Chris Kuklewicz wrote: > Small correction: > > I think "./prog in vs ./prog < in " and "utf8" should be "ok". Ah yes, quite right. Similarly ./prog -o out vs ./prog > out because neither involve printing to the terminal. Duncan From jules at jellybean.co.uk Wed Feb 27 10:52:16 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Wed Feb 27 10:50:12 2008 Subject: H98 Text IO In-Reply-To: <196452.41270.qm@web51603.mail.re2.yahoo.com> References: <196452.41270.qm@web51603.mail.re2.yahoo.com> Message-ID: <47C58730.2020508@jellybean.co.uk> Matthew Bentham wrote: > "It?s not unreasonable to have a program that wants to encode its outputin a particular encoding. The example I gave earlier still seemsreasonable to be, a program that takes input in one encoding andrecodes to a different encoding on its output, with both the input andoutput encoding specified on the command line. Clearly such a programshould be able to use stdin and stdout so that it can form part of apipe. So how in Python do I change sys.stdout to use a particular encoding? It?s a right pain." > Which is an excellent point. But there are two (different) areas here. (1) how we make the over-simplistic H98 interface do something 'mostly right' or 'least worst' (2) how we design a better (but necessarily non-H98) interface for more sophisticated programs. And we need to solve (1) independently of all the possible nice design spaces for (2). Jules From igloo at earth.li Wed Feb 27 11:30:29 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Feb 27 11:28:18 2008 Subject: H98 Text IO In-Reply-To: <20080227003007.GF17316@darcs.net> References: <1204026469.3076.381.camel@localhost> <47C4127F.2020204@gmail.com> <47C41FA9.7020104@gmail.com> <1204070819.3076.490.camel@localhost> <20080227003007.GF17316@darcs.net> Message-ID: <20080227163029.GA5164@matrix.chaos.earth.li> On Tue, Feb 26, 2008 at 07:30:08PM -0500, David Roundy wrote: > On Wed, Feb 27, 2008 at 12:06:59AM +0000, Duncan Coutts wrote: > > I think personally I'm coming round to the "always locale" point of > > view. We already have no cross-platform consistency for text files > > because of the lf vs cr/lf issue and we have no cross-implementation > > consistency. > > I'm leaning in the same direction. This has swung me too. Thanks Ian From naur at post11.tele.dk Wed Feb 27 12:05:46 2008 From: naur at post11.tele.dk (Thorkil Naur) Date: Wed Feb 27 12:03:54 2008 Subject: H98 Text IO In-Reply-To: <20080227163036.LNEV1374.fep29.mail.dk@www.haskell.org> References: <1204026469.3076.381.camel@localhost> <20080227003007.GF17316@darcs.net> <20080227163036.LNEV1374.fep29.mail.dk@www.haskell.org> Message-ID: <200802271805.47009.naur@post11.tele.dk> Hello, On Wednesday 27 February 2008 17:30, Ian Lynagh wrote: > On Tue, Feb 26, 2008 at 07:30:08PM -0500, David Roundy wrote: > > On Wed, Feb 27, 2008 at 12:06:59AM +0000, Duncan Coutts wrote: > > > I think personally I'm coming round to the "always locale" point of > > > view. We already have no cross-platform consistency for text files > > > because of the lf vs cr/lf issue and we have no cross-implementation > > > consistency. > > > > I'm leaning in the same direction. > > This has swung me too. > Let me be contrary, then: The "always locale" idea depends, as I understand it, on some relatively global setting. And, especially in the context of functional programming, global things dont strike me as particularly appropriate. This particular global thing also has the wonderful property of being modifiable. So it is actually a global variable.Some years ago, I had a hard time because some program that I hadn't written, but had to call from my program, occasionally changed the locale setting when called. The problem turned out, after much and exasperating work, to be that this changed the behaviour of sprintf: In Denmark we use commas for decimal points. I know that we are not supposed to discuss a new and marvellous IO library on this thread, but let me mention what I would consider a very valuable property of this new library that I believe may affect what we do now to clean up the present affair: I would very much like to be able to specify the desired encoding myself, as others have mentioned, at some level of using this new library. So that the present library in principle could be implemented on top of this by specifying any desirable encoding used, including using the current locale setting or utf-8 or letting the encoding depend on the device or whatever one prefers. So although my favorite choice at this moment is "always utf-8", I am much more concerned that the choice that we make does not exclude the possibility of creating this new and wonderful IO library that can be used easily to support the behaviour of the existing library (in whatever form it is changed into as a result of the present discussion). > ... Best regards Thorkil From judah.jacobson at gmail.com Wed Feb 27 13:00:38 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Wed Feb 27 12:58:29 2008 Subject: darcs patch: #2053: add additional history functions (+1 more) Message-ID: <6d74b0d20802271000p5dc5788by869928f77a021ecf@mail.gmail.com> The following patches reflect the discussion and consensus on #2053. The discussion period has passed; can someone please apply them to the readline repo? Thanks, -Judah Mon Jan 21 21:05:36 PST 2008 alexander.dunlap@gmail.com * #2053: add additional history functions The following functions were added: readHistory, writeHistory, appendHistory, historyTruncateFile, clearHistory, stifleHistory, unstifleHistory, historyIsStifled, historyMaxEntries M ./System/Console/Readline.hsc +85 Tue Feb 26 15:39:29 PST 2008 judah.jacobson@gmail.com * #2053: Make readHistory/writeHistory return a Bool instead of throwing an exception on failure. M ./System/Console/Readline.hsc -9 +10 -------------- next part -------------- A non-text attachment was scrubbed... Name: history.patch Type: application/octet-stream Size: 10661 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20080227/1bd5e865/history.obj From droundy at darcs.net Wed Feb 27 15:19:18 2008 From: droundy at darcs.net (David Roundy) Date: Wed Feb 27 15:17:09 2008 Subject: H98 Text IO In-Reply-To: <200802271805.47009.naur@post11.tele.dk> References: <1204026469.3076.381.camel@localhost> <20080227003007.GF17316@darcs.net> <20080227163036.LNEV1374.fep29.mail.dk@www.haskell.org> <200802271805.47009.naur@post11.tele.dk> Message-ID: <20080227201917.GK17316@darcs.net> On Wed, Feb 27, 2008 at 06:05:46PM +0100, Thorkil Naur wrote: > Hello, > > On Wednesday 27 February 2008 17:30, Ian Lynagh wrote: > > On Tue, Feb 26, 2008 at 07:30:08PM -0500, David Roundy wrote: > > > On Wed, Feb 27, 2008 at 12:06:59AM +0000, Duncan Coutts wrote: > > > > I think personally I'm coming round to the "always locale" point of > > > > view. We already have no cross-platform consistency for text files > > > > because of the lf vs cr/lf issue and we have no cross-implementation > > > > consistency. > > > > > > I'm leaning in the same direction. > > > > This has swung me too. > > Let me be contrary, then: The "always locale" idea depends, as I understand > it, on some relatively global setting. And, especially in the context of > functional programming, global things dont strike me as particularly > appropriate. > > This particular global thing also has the wonderful property of being > modifiable. So it is actually a global variable.Some years ago, I had a hard > time because some program that I hadn't written, but had to call from my > program, occasionally changed the locale setting when called. The problem > turned out, after much and exasperating work, to be that this changed the > behaviour of sprintf: In Denmark we use commas for decimal points. Of course, something like sprintf would be a pure function (and thus safe, but also perhaps incorrect) in Haskell... It'd be up to the implementors whether to indeed allow the locale setting to be modified during the course of a program running, there's certainly no requirement that it be mutable, and certainly it need not be externally mutable. If we only check the locale once, we're safe from all "locale rotating with the phase of the moon" bugs. Certainly stdin/out/err would be safe, because they'd only be opened when the program starts. -- David Roundy Department of Physics Oregon State University From iavor.diatchki at gmail.com Wed Feb 27 16:20:35 2008 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed Feb 27 16:18:27 2008 Subject: H98 Text IO In-Reply-To: <20080227201917.GK17316@darcs.net> References: <1204026469.3076.381.camel@localhost> <20080227003007.GF17316@darcs.net> <20080227163036.LNEV1374.fep29.mail.dk@www.haskell.org> <200802271805.47009.naur@post11.tele.dk> <20080227201917.GK17316@darcs.net> Message-ID: <5ab17e790802271320n4a9459dahe6f6fdf963e54fd9@mail.gmail.com> Hi, My preference would be for handles to have a "mode" that specifies the encoding to use when reading and writing characters. By default, the mode should be set to the encoding specified in the locale but we should also provide an explicit "setEncoding" method so that programmers can specify the encoding to be used explicitly. -Iavor On Wed, Feb 27, 2008 at 12:19 PM, David Roundy wrote: > On Wed, Feb 27, 2008 at 06:05:46PM +0100, Thorkil Naur wrote: > > Hello, > > > > On Wednesday 27 February 2008 17:30, Ian Lynagh wrote: > > > On Tue, Feb 26, 2008 at 07:30:08PM -0500, David Roundy wrote: > > > > On Wed, Feb 27, 2008 at 12:06:59AM +0000, Duncan Coutts wrote: > > > > > I think personally I'm coming round to the "always locale" point of > > > > > view. We already have no cross-platform consistency for text files > > > > > because of the lf vs cr/lf issue and we have no cross-implementation > > > > > consistency. > > > > > > > > I'm leaning in the same direction. > > > > > > This has swung me too. > > > > Let me be contrary, then: The "always locale" idea depends, as I understand > > it, on some relatively global setting. And, especially in the context of > > functional programming, global things dont strike me as particularly > > appropriate. > > > > This particular global thing also has the wonderful property of being > > modifiable. So it is actually a global variable.Some years ago, I had a hard > > time because some program that I hadn't written, but had to call from my > > program, occasionally changed the locale setting when called. The problem > > turned out, after much and exasperating work, to be that this changed the > > behaviour of sprintf: In Denmark we use commas for decimal points. > > Of course, something like sprintf would be a pure function (and thus safe, > but also perhaps incorrect) in Haskell... > > It'd be up to the implementors whether to indeed allow the locale setting > to be modified during the course of a program running, there's certainly no > requirement that it be mutable, and certainly it need not be externally > mutable. If we only check the locale once, we're safe from all "locale > rotating with the phase of the moon" bugs. Certainly stdin/out/err would > be safe, because they'd only be opened when the program starts. > > -- > David Roundy > Department of Physics > Oregon State University > _______________________________________________ > > > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From simonpj at microsoft.com Thu Feb 28 05:53:22 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Feb 28 05:51:10 2008 Subject: Exports of STM constructors. In-Reply-To: References: Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C31F9714FBE0@EA-EXMSG-C334.europe.corp.microsoft.com> [Redirecting to libraries] Your suggestion seems plausible to me: - export everything from GHC.Conc; import this only if you know what you are doing - export STM, TVar only abstractly from Control.Concurrent.STM; this is the interface for ordinary users This sounds like a candidate for the standard library modification process, if someone wants to put it into action. http://haskell.org/haskellwiki/Library_submissions Simon From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Sterling Clover Sent: 27 February 2008 20:15 To: glasgow-haskell-users@haskell.org Subject: Exports of STM constructors. I was recently bitten by the urge to hack around with STM, and discovered to my dismay that there's no way to get at the primitive constructors for TVar and STM, both of which are defined in GHC.Conc. Given that, when we so desire, we can get at the primitives to break IO into pieces, manually unbox integers and such, and that the primitives for working with MVars are similarly exposed through appropriate imports, it would be really nice (or, well, at least fun) to be able to do the same for STM. --S -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20080228/726ba756/attachment.htm From simonmarhaskell at gmail.com Thu Feb 28 06:32:45 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Feb 28 06:30:39 2008 Subject: Exports of STM constructors. In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C31F9714FBE0@EA-EXMSG-C334.europe.corp.microsoft.com> References: <638ABD0A29C8884A91BC5FB5C349B1C31F9714FBE0@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <47C69BDD.2060903@gmail.com> Simon Peyton-Jones wrote: > Your suggestion seems plausible to me: > > - export *everything* from GHC.Conc; import this only if you > know what you are doing > > - export STM, TVar only *abstractly* from > Control.Concurrent.STM; this is the interface for ordinary users > > > > This sounds like a candidate for the standard library modification > process, if someone wants to put it into action. > > http://haskell.org/haskellwiki/Library_submissions I think GHC.Conc is private to GHC, not an official API, and therefore not subject to the library submission process. I'll go ahead make this change. Cheers, Simon From simonmarhaskell at gmail.com Thu Feb 28 07:30:17 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Feb 28 07:28:07 2008 Subject: darcs patch: #2053: add additional history functions (+1 more) In-Reply-To: <6d74b0d20802271000p5dc5788by869928f77a021ecf@mail.gmail.com> References: <6d74b0d20802271000p5dc5788by869928f77a021ecf@mail.gmail.com> Message-ID: <47C6A959.6090200@gmail.com> Judah Jacobson wrote: > The following patches reflect the discussion and consensus on #2053. > The discussion period has passed; can someone please apply them to the > readline repo? I'll apply, thanks. Simon > Thanks, > -Judah > > > Mon Jan 21 21:05:36 PST 2008 alexander.dunlap@gmail.com > * #2053: add additional history functions > The following functions were added: readHistory, writeHistory, > appendHistory, historyTruncateFile, clearHistory, stifleHistory, > unstifleHistory, historyIsStifled, historyMaxEntries > > M ./System/Console/Readline.hsc +85 > > Tue Feb 26 15:39:29 PST 2008 judah.jacobson@gmail.com > * #2053: Make readHistory/writeHistory return a Bool instead of > throwing an exception on failure. > > M ./System/Console/Readline.hsc -9 +10 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries From ben.franksen at online.de Thu Feb 28 17:53:50 2008 From: ben.franksen at online.de (Ben Franksen) Date: Thu Feb 28 17:55:48 2008 Subject: H98 Text IO References: <1204026469.3076.381.camel@localhost> <47C4127F.2020204@gmail.com> <1204032894.3076.393.camel@localhost> <20080226152807.GD5260@sliver.repetae.net> <1204060549.3076.408.camel@localhost> <20080226224028.GA6371@holst> Message-ID: David Leuschner wrote: > If I write simple program just printing a non-ASCII string to the terminal > or to a file I'd expect that I can read it on the screen or using my > favorite text editor without having change anything -- neither in my > terminal nor in my program. When I run the program on my platform don't > mind if somebody else might get differently encoded output from the same > program as long as I get what I expect. I think this is sensible advice. Furthermore I want to be able to chose an encoding (e.g. by setting my environment), even for file/socket IO, instead of being locked into utf-8. Thus, for Linux, I'd say always use the environment encoding. More advanced stuff like sending in a certain encoding e.g. over network or to a foreign file system should not use H98 IO but newer libraries that allow to set the encoding programmatically, or encode yourself and read/write Word8. Cheers Ben From duncan.coutts at worc.ox.ac.uk Fri Feb 29 17:11:18 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Feb 29 17:09:04 2008 Subject: every use of BSD4 on hackage is incorrect Message-ID: <1204323078.11558.76.camel@localhost> The following hackage packages specify in their .cabal file: license: BSD4 Which is the 4-clause BSD license, ie the one with the advertising clause. cabal-upload-0.3 Chart-0.5 FiniteMap-0.1 haxr-3000.0.1 haxr-th-1.0 hbeat-0.1 htar-0.1 pcap-0.4.2 tar-0.1.1.1 unix-compat-0.1.2.1 Inspecting the LICENSE files for every one of these packages reveals that they actually use the 3-clause BSD license. Not a single hackage package really uses the 4-clause BSD license. In every case that it has been used it was just a confusion. We therefore propose to deprecate BSD4 as a valid license in .cabal files: http://hackage.haskell.org/trac/hackage/ticket/205 In the unlikely case that anyone really wants to use the 4-clause BSD license they can still specify "license: OtherLicense" and put the text in the accompanying LICENSE file. Additionally, I propose to add the MIT license since there are a couple packages that really use that and allow optional versions on the licenses that are versioned, which includes the GPL and LGPL. Looking at OtherLicense we find common ones are MIT, variations on BSD3 (2 clause and fewer, other informal variations), disjunctions of BSD3 / GPL (ie dual licensing), conjunctions of BSD3 / GPL (ie some bits user BSD some under GPL). Duncan From apa3a at yahoo.com Fri Feb 29 22:36:36 2008 From: apa3a at yahoo.com (Andriy Palamarchuk) Date: Fri Feb 29 22:34:19 2008 Subject: Data.Map, Data.IntMap documentation (1611) In-Reply-To: <216132.29104.qm@web56414.mail.re3.yahoo.com> Message-ID: <777240.31684.qm@web56405.mail.re3.yahoo.com> Could somebody please commit the patch attached to this ticket? Sorry about a long delay before I finalized the patch. Thanks, Andriy --- Andriy Palamarchuk wrote: > Thanks everybody for the corrections and > suggestions. > Finally I got back to this work. > Sorry it took this long to respond. > > Log comment: > Improved, fixed documentation for Data.Map, > Data.IntMap. Added examples. > > Changes since the first submission: > * Moved time complexity Big-O values back to the > beginning of function descriptions. > * Converted examples from interpreter session-like > format to more compact equation-like format. > * As per > http://www.haskell.org/pipermail/libraries/2007-March/007304.html > added following information to the description of > updateLookupWithKey: > > The function returns changed value, if it is > updated. > Returns the original key value if the map entry > is > deleted. > > Ticket: > http://hackage.haskell.org/trac/ghc/ticket/1611 > > Haddock output: > http://hackage.haskell.org/trac/ghc/attachment/ticket/1611/Data-Map.html?format=raw > > Comments, suggestions, critique? > Did I miss anything? > I'll update IntMap for the final review. > Andriy > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam > protection around > http://mail.yahoo.com > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping