From conal at conal.net Tue Jan 2 15:26:19 2007 From: conal at conal.net (Conal Elliott) Date: Tue Jan 2 15:22:47 2007 Subject: mtl vs monads Message-ID: Are the mtl and monads (monadLib) packages both in active use? Is one being phased out? - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20070102/2912ae85/attachment.htm From iavor.diatchki at gmail.com Tue Jan 2 17:51:38 2007 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue Jan 2 17:48:06 2007 Subject: mtl vs monads In-Reply-To: References: Message-ID: <5ab17e790701021451y4eade138rafb6fdfe93ea2a7e@mail.gmail.com> Hi Conal, At some point 'monads' was supposed to replace 'mt'l but I am not sure that this is happening. At the moment I think that most people use 'mtl'. As far as I know, I am the only person actively using 'monads'. If you want to try out 'monads' drop me a mail because the version that is on the web site is rather old, and I have been using a more up to date (and smaller, just 1 file) version. I guess I should put it on the web site at some point but I'd like to test it some more. Hope this helps -Iavor On 1/2/07, Conal Elliott wrote: > Are the mtl and monads (monadLib) packages both in active use? Is one being > phased out? - Conal > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > > From ajb at spamcop.net Tue Jan 2 23:53:15 2007 From: ajb at spamcop.net (ajb@spamcop.net) Date: Tue Jan 2 23:49:42 2007 Subject: mtl vs monads In-Reply-To: <5ab17e790701021451y4eade138rafb6fdfe93ea2a7e@mail.gmail.com> References: <5ab17e790701021451y4eade138rafb6fdfe93ea2a7e@mail.gmail.com> Message-ID: <20070102235315.6o000ccw88w08swo@webmail.spamcop.net> G'day all. Quoting Iavor Diatchki : > At the moment I think that most people use > 'mtl'. As far as I know, I am the only person actively using > 'monads'. Last I saw (which was a VERY long time ago), monads wasn't cabalised. Has that been done yet? Cheers, Andrew Bromage From iavor.diatchki at gmail.com Wed Jan 3 00:29:36 2007 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed Jan 3 00:26:04 2007 Subject: mtl vs monads In-Reply-To: <20070102235315.6o000ccw88w08swo@webmail.spamcop.net> References: <5ab17e790701021451y4eade138rafb6fdfe93ea2a7e@mail.gmail.com> <20070102235315.6o000ccw88w08swo@webmail.spamcop.net> Message-ID: <5ab17e790701022129k72159529pc07852eb61ed6656@mail.gmail.com> Hi, 'monads' (or 'monadLib', as I call it) supports Cabal as of Version 1.2.2. The current version (which I just put on the website) is 3.0.0. -Iavor On 1/2/07, ajb@spamcop.net wrote: > G'day all. > > Quoting Iavor Diatchki : > > > At the moment I think that most people use > > 'mtl'. As far as I know, I am the only person actively using > > 'monads'. > > Last I saw (which was a VERY long time ago), monads wasn't cabalised. > Has that been done yet? > > Cheers, > Andrew Bromage > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From ross at soi.city.ac.uk Wed Jan 3 05:48:39 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Jan 3 05:45:08 2007 Subject: Hackage interface Message-ID: <20070103104839.GA8509@soi.city.ac.uk> I've put up (temporarily) a crude first cut at an interface to the Hackage package database at http://ross-paterson.dyndns.org/~ross/hackage/ Obviously it could be a lot prettier. Also package upload uses the same logins as the GHC Wiki, but we'd want to change that. From dons at cse.unsw.edu.au Wed Jan 3 06:33:40 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Wed Jan 3 06:30:08 2007 Subject: Hackage interface In-Reply-To: <20070103104839.GA8509@soi.city.ac.uk> References: <20070103104839.GA8509@soi.city.ac.uk> Message-ID: <20070103113340.GA1716@cse.unsw.EDU.AU> ross: > I've put up (temporarily) a crude first cut at an interface to the > Hackage package database at > > http://ross-paterson.dyndns.org/~ross/hackage/ > > Obviously it could be a lot prettier. Also package upload uses the > same logins as the GHC Wiki, but we'd want to change that. Great work Ross! -- Don From iavor.diatchki at gmail.com Wed Jan 3 12:40:45 2007 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed Jan 3 12:37:11 2007 Subject: ANN: monadLib 3.0.0 Message-ID: <5ab17e790701030940ua8afef0pd4327edbf70a3721@mail.gmail.com> Hello, I have placed a new version of 'monadLib' on its web-page: http://www.csee.ogi.edu/~diatchki/monadLib Some of the changes compared to the previous version: * The whole library is in a single module MonadLib.hs (~500 lines) * Simpler and more symmetric API * Removed the (generic) monadic combinators * Removed the search transformer (may add another version of it at some point) * Rewrote some transformers in the "traditional" way (e.g., exceptions and output) * There is an optional module that defines base monads corresponding to each transformer. Comments are very welcome. -Iavor From ross at soi.city.ac.uk Wed Jan 3 13:03:03 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Jan 3 12:59:30 2007 Subject: authentication for hackage uploads Message-ID: <20070103180303.GA19349@soi.city.ac.uk> We need some security on uploads to hackage, because Cabal packages can run arbitrary code during the build process (and when in use). I think that Apache authentication (as used in Trac, for example) would be sufficient, but that the initial registration of submitters needs to be done manually by a small group of people. We need to know who we're dealing with, and we need at least an email address to contact them. Personally, I'd prefer that user names were real names in camel case, but maybe I'm too old-fashioned. Any views? From bulat.ziganshin at gmail.com Wed Jan 3 16:52:36 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Jan 3 16:49:11 2007 Subject: authentication for hackage uploads In-Reply-To: <20070103180303.GA19349@soi.city.ac.uk> References: <20070103180303.GA19349@soi.city.ac.uk> Message-ID: <1274472392.20070104005236@gmail.com> Hello Ross, Wednesday, January 3, 2007, 9:03:03 PM, you wrote: > We need some security on uploads to hackage, because Cabal packages interesting question, although i think it is more appropriate for cafe maillist i think we can look at it from another side. how your committee van decide who is "good hacker" and who isn't? what is your criteria? for example, how you can decide is me good enough or not? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From ndmitchell at gmail.com Wed Jan 3 17:46:12 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Jan 3 17:42:38 2007 Subject: authentication for hackage uploads In-Reply-To: <20070103180303.GA19349@soi.city.ac.uk> References: <20070103180303.GA19349@soi.city.ac.uk> Message-ID: <404396ef0701031446g71503bb5ldae2a35d00e1c3e1@mail.gmail.com> Hi > We need some security on uploads to hackage, because Cabal packages > can run arbitrary code during the build process I think this should be strongly discouraged by Cabal, almost to the point where Setup files with custom code are disallowed by Hackage. Doing an attack on an in-use module is a lot more work than putting it in the configure script. > I think that Apache authentication (as used in Trac, for example) would > be sufficient, but that the initial registration of submitters needs to > be done manually by a small group of people. We need to know who we're > dealing with, and we need at least an email address to contact them. > Personally, I'd prefer that user names were real names in camel case, > but maybe I'm too old-fashioned. There is also a list of people with access to the darcs repo's on Haskell.org - these things probably want managing in much the same way. Currently the policy is that Yhc hackers get their key added to my authorised_keys file, and just log in using my username - I'm not terribly comfortable with that. I would demand at the very least a real name, email address - but really, in an online world those things are nearly useless. I guess the only thing to do is to trust that people who have learnt enough about monads and IO to hijack Haskell things probably realise how cool Haskell is... Thanks Neil From ashley at semantic.org Wed Jan 3 18:37:37 2007 From: ashley at semantic.org (Ashley Yakeley) Date: Wed Jan 3 18:34:24 2007 Subject: ANN: monadLib 3.0.0 In-Reply-To: <5ab17e790701030940ua8afef0pd4327edbf70a3721@mail.gmail.com> References: <5ab17e790701030940ua8afef0pd4327edbf70a3721@mail.gmail.com> Message-ID: Iavor Diatchki wrote: > Hello, > > I have placed a new version of 'monadLib' on its web-page: > http://www.csee.ogi.edu/~diatchki/monadLib There seem to be some overlaps with the standard libraries? Monad.Id.Id vs. Control.Monad.Identity.Identity Monad.ForEach.ForEach vs. Data.Traversable.Traversable ...as well as much of package mtl. Is monadLib a replacement for mtl? -- Ashley Yakeley From ashley at semantic.org Wed Jan 3 18:43:18 2007 From: ashley at semantic.org (Ashley Yakeley) Date: Wed Jan 3 18:40:13 2007 Subject: ANN: monadLib 3.0.0 In-Reply-To: References: <5ab17e790701030940ua8afef0pd4327edbf70a3721@mail.gmail.com> Message-ID: I wrote: > Is monadLib a replacement for mtl? Oh, Conal just asked that. Never mind... -- Ashley Yakeley From dmhouse at gmail.com Thu Jan 4 05:37:35 2007 From: dmhouse at gmail.com (David House) Date: Thu Jan 4 05:33:59 2007 Subject: authentication for hackage uploads In-Reply-To: <20070103180303.GA19349@soi.city.ac.uk> References: <20070103180303.GA19349@soi.city.ac.uk> Message-ID: On 03/01/07, Ross Paterson wrote: > I think that Apache authentication (as used in Trac, for example) ... Just to point out that Trac's authentication is probably the most annoying I've ever used. It would never remember that I was logged in and every time I wanted to make a change to the Trac I'd have to hunt for the 'Log in' button and enter my username and password. If this is tied to HTTP auth, consider this a strong vote _against_ the proposed system from someone who's had experience working with the system in practise. -- -David House, dmhouse@gmail.com From ross at soi.city.ac.uk Thu Jan 4 07:55:25 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Jan 4 07:51:57 2007 Subject: authentication for hackage uploads In-Reply-To: References: <20070103180303.GA19349@soi.city.ac.uk> Message-ID: <20070104125525.GA12962@soi.city.ac.uk> On Thu, Jan 04, 2007 at 10:37:35AM +0000, David House wrote: > On 03/01/07, Ross Paterson wrote: > >I think that Apache authentication (as used in Trac, for example) ... > > Just to point out that Trac's authentication is probably the most > annoying I've ever used. It would never remember that I was logged in > and every time I wanted to make a change to the Trac I'd have to hunt > for the 'Log in' button and enter my username and password. If this is > tied to HTTP auth, consider this a strong vote _against_ the proposed > system from someone who's had experience working with the system in > practise. Authentication would only happen when you upload a package. Do you have an alternative suggestion? From ross at soi.city.ac.uk Thu Jan 4 11:06:32 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Jan 4 11:02:58 2007 Subject: package pages in Hackage Message-ID: <20070104160632.GA17115@soi.city.ac.uk> Bj?rn Bringert has a number of ideas for things that could be added to package web pages offered by a Hackage interface, some of which are implemented in his proof-of-concept hask-home: http://www.cs.chalmers.se/~bringert/darcs/hask-home/doc/ I'd like to see things like who uploaded the package and when, and the results of automatic builds of the package. Just knowing whether a package compiles with recent compiler releases would be an excellent bitrot filter. Presumably others will have more ideas, and we'd like them to be able to add things without having to modify the CGI program. So perhaps we could have a directory .parts containing fragments of the package page (in either HTML or Bj?rn's HMarkup) which the CGI program stitches together, with some means of specifying the order. Some of these parts could be generated asynchronously, e.g. by build daemons. From dmhouse at gmail.com Thu Jan 4 15:54:36 2007 From: dmhouse at gmail.com (David House) Date: Thu Jan 4 15:50:58 2007 Subject: authentication for hackage uploads In-Reply-To: <20070104125525.GA12962@soi.city.ac.uk> References: <20070103180303.GA19349@soi.city.ac.uk> <20070104125525.GA12962@soi.city.ac.uk> Message-ID: On 04/01/07, Ross Paterson wrote: > Authentication would only happen when you upload a package. > Do you have an alternative suggestion? The normal authentication methods for web applications. Store a database of (username, password) pairs. A user becomes logged in by setting two cookies, one to indicate their username and one to indicate their password (or often the MD5 hash of their password). To authenticate a user, you check that these cookies are present, that the value of the username cookie appears in the database and that the password cookie matches the corresponding password pulled from the database. I'm not actually that familiar with HTTP Auth itself, just with Trac. But if you want to save frequent contributors tearing their hear out, at least consider this. :) -- -David House, dmhouse@gmail.com From ross at soi.city.ac.uk Thu Jan 4 19:37:18 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Jan 4 19:33:45 2007 Subject: Hackage interface In-Reply-To: <20070103104839.GA8509@soi.city.ac.uk> References: <20070103104839.GA8509@soi.city.ac.uk> Message-ID: <20070105003718.GA24629@soi.city.ac.uk> On Wed, Jan 03, 2007 at 10:48:39AM +0000, Ross Paterson wrote: > I've put up (temporarily) a crude first cut at an interface to the > Hackage package database at > > http://ross-paterson.dyndns.org/~ross/hackage/ > > Obviously it could be a lot prettier. Also package upload uses the > same logins as the GHC Wiki, but we'd want to change that. I've added a form that does a few sanity checks on packages. At some point we need to agree a list of category names (or to just use the top level of the module hierarchy instead). From dons at cse.unsw.edu.au Thu Jan 4 19:43:24 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Thu Jan 4 19:39:46 2007 Subject: Hackage interface In-Reply-To: <20070105003718.GA24629@soi.city.ac.uk> References: <20070103104839.GA8509@soi.city.ac.uk> <20070105003718.GA24629@soi.city.ac.uk> Message-ID: <20070105004323.GA27673@cse.unsw.EDU.AU> ross: > On Wed, Jan 03, 2007 at 10:48:39AM +0000, Ross Paterson wrote: > > I've put up (temporarily) a crude first cut at an interface to the > > Hackage package database at > > > > http://ross-paterson.dyndns.org/~ross/hackage/ > > > > Obviously it could be a lot prettier. Also package upload uses the > > same logins as the GHC Wiki, but we'd want to change that. > > I've added a form that does a few sanity checks on packages. > > At some point we need to agree a list of category names (or to just > use the top level of the module hierarchy instead). Regarding this, we'll make things (a little) easier by reusing (roughly) the categories from existing package systems. Some kind of intersectoin between say, openbsd and debian and gentoo. Here's the openbsd package categories: [DIR] archivers/ [DIR] astro/ [DIR] audio/ [DIR] benchmarks/ [DIR] biology/ [DIR] books/ [DIR] cad/ [DIR] chinese/ [DIR] comms/ [DIR] converters/ [DIR] databases/ [DIR] devel/ [DIR] editors/ [DIR] education/ [DIR] emulators/ [DIR] games/ [DIR] graphics/ [DIR] japanese/ [DIR] korean/ [DIR] lang/ [DIR] math/ [DIR] misc/ [DIR] multimedia/ [DIR] net/ [DIR] productivity/ [DIR] security/ [DIR] shells/ [DIR] sysutils/ [DIR] telephony/ [DIR] textproc/ [DIR] web/ [DIR] x11/ Merge this with say debians categories, and add our own. -- Don From stefanor at cox.net Thu Jan 4 19:50:21 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Thu Jan 4 19:46:43 2007 Subject: Hackage interface In-Reply-To: <20070105004323.GA27673@cse.unsw.EDU.AU> References: <20070103104839.GA8509@soi.city.ac.uk> <20070105003718.GA24629@soi.city.ac.uk> <20070105004323.GA27673@cse.unsw.EDU.AU> Message-ID: <20070105005021.GA3134@localhost.localdomain> On Fri, Jan 05, 2007 at 11:43:24AM +1100, Donald Bruce Stewart wrote: > ross: > > At some point we need to agree a list of category names (or to just > > use the top level of the module hierarchy instead). > > Regarding this, we'll make things (a little) easier by reusing > (roughly) the categories from existing package systems. Some kind of > intersectoin between say, openbsd and debian and gentoo. Here's the > openbsd package categories: > ... > > Merge this with say debians categories, and add our own. Debian *has* categories (called sections), but is trying to get rid of them. They are currently working on (it's in unstable and mostly working) a replacement system, debtags. debtags differs from the section system in that packages can have multiple tags, and queries can include conjunctions and disjunctions; IME this makes it much more useful (speaking as an unstable- tracker). Perhaps we should look into copying debtags's ideas? (we need to support some kind of tagging, for the sake of package generation) The main debtags site: http://debtags.alioth.debian.org/ From clifford.beshers at linspire.com Thu Jan 4 19:53:50 2007 From: clifford.beshers at linspire.com (Clifford Beshers) Date: Thu Jan 4 19:50:19 2007 Subject: Hackage interface In-Reply-To: <20070105004323.GA27673@cse.unsw.EDU.AU> References: <20070103104839.GA8509@soi.city.ac.uk> <20070105003718.GA24629@soi.city.ac.uk> <20070105004323.GA27673@cse.unsw.EDU.AU> Message-ID: <459DA19E.5000707@linspire.com> Donald Bruce Stewart wrote: > ross: > >> At some point we need to agree a list of category names (or to just >> use the top level of the module hierarchy instead). >> >> > > Regarding this, we'll make things (a little) easier by reusing > (roughly) the categories from existing package systems. The list you gave looks suspiciously like the XDG Menu Standard from FreeDesktop.org. I think that would be better to tie into that than invent another. It is extensible. http://standards.freedesktop.org/menu-spec/menu-spec-latest.html#category-registry -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20070104/63d56252/attachment.htm From johan.tibell at gmail.com Fri Jan 5 02:44:21 2007 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri Jan 5 02:40:41 2007 Subject: Hackage interface In-Reply-To: <20070105005021.GA3134@localhost.localdomain> References: <20070103104839.GA8509@soi.city.ac.uk> <20070105003718.GA24629@soi.city.ac.uk> <20070105004323.GA27673@cse.unsw.EDU.AU> <20070105005021.GA3134@localhost.localdomain> Message-ID: <90889fe70701042344y1c05f58bgc3d63a91f29b313e@mail.gmail.com> On 1/5/07, Stefan O'Rear wrote: > Debian *has* categories (called sections), but is trying to get rid of > them. They are currently working on (it's in unstable and mostly working) > a replacement system, debtags. debtags differs from the section system > in that packages can have multiple tags, and queries can include conjunctions > and disjunctions; IME this makes it much more useful (speaking as an unstable- > tracker). Perhaps we should look into copying debtags's ideas? (we need to > support some kind of tagging, for the sake of package generation) > > The main debtags site: http://debtags.alioth.debian.org/ I agree with this. For those who haven't read it "Ontology is Overrated: Categories, Links, and Tags" is a good discussion on categories vs tags: http://www.shirky.com/writings/ontology_overrated.html Cheers, Johan From frederik at a5.repetae.net Fri Jan 5 05:21:21 2007 From: frederik at a5.repetae.net (Frederik Eaton) Date: Fri Jan 5 05:18:37 2007 Subject: RandomGen, mkStdGen Message-ID: <20070105102121.GA29589@a5.repetae.net> Hi all, I'm having trouble using RandomGen with external tools (e.g. libraries written in C). StdGen has a nice function: mkStdGen :: Int -> StdGen Using this, I can write an FFI wrapper ending with type: (StdGen -> (a, StdGen)) by using the StdGen to generate an Int, and then using that to seed a foreign random number generator within C, and then at the end of the C function reading a final random number, passing it back to Haskell, and passing it to mkStdGen. This will always have the right semantics, I believe. However, there are several problems: - It only works for StdGen, not arbitrary instances of RandomGen - It "shrinks" my whole random state into an Int - so I might have 1024 bits of state in my random number generator within C, and within Haskell, but when I move between the two, everything is truncated to 32 bits. This is problematic in some applications, and as computers become faster it will be more of a concern. Thus, I suggest a new member of class RandomGen: mkRandomGen :: [Int] -> g It is similar to mkStdGen, but it takes a list of Int's so that users who want to save more bits of state across conversions can do so. Also, being a member of the RandomGen class, it can be depended on in more situations than mkStdGen. There is a question of backward compatibility with existing RandomGen instances. I think the best thing to do is provide a default definition for mkRandomGen which is an error or 'undefined'. This way, legacy code will still compile, but libraries which define RandomGen instances just won't work with new code which tries to call mkRandomGen. I don't imagine that there are many such libraries, and besides they wouldn't have been useful in any case if the code in question had been restricted to mkStdGen as it is currently. Hope I'm not missing some previous discussion. Best, Frederik Eaton -- http://ofb.net/~frederik/ From sven.panne at aedion.de Fri Jan 5 10:04:17 2007 From: sven.panne at aedion.de (Sven Panne) Date: Fri Jan 5 10:00:33 2007 Subject: authentication for hackage uploads In-Reply-To: <404396ef0701031446g71503bb5ldae2a35d00e1c3e1@mail.gmail.com> References: <20070103180303.GA19349@soi.city.ac.uk> <404396ef0701031446g71503bb5ldae2a35d00e1c3e1@mail.gmail.com> Message-ID: <200701051604.17112.sven.panne@aedion.de> Am Mittwoch, 3. Januar 2007 23:46 schrieb Neil Mitchell: > > We need some security on uploads to hackage, because Cabal packages > > can run arbitrary code during the build process > > I think this should be strongly discouraged by Cabal, almost to the > point where Setup files with custom code are disallowed by Hackage. > Doing an attack on an in-use module is a lot more work than putting it > in the configure script. [...] There are already quite a few open build systems for "normal" (RPM, etc.) packages out there, and the usual technology is to run everything in a chroot cage. Would this be an option here, too? I have to admit that I currently do not fully understand who will run which code when, etc. when we talk about hackage. Cheers, S. From simonmarhaskell at gmail.com Fri Jan 5 11:26:48 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri Jan 5 11:23:10 2007 Subject: Hackage interface In-Reply-To: <20070105005021.GA3134@localhost.localdomain> References: <20070103104839.GA8509@soi.city.ac.uk> <20070105003718.GA24629@soi.city.ac.uk> <20070105004323.GA27673@cse.unsw.EDU.AU> <20070105005021.GA3134@localhost.localdomain> Message-ID: <459E7C48.2010807@microsoft.com> Stefan O'Rear wrote: > On Fri, Jan 05, 2007 at 11:43:24AM +1100, Donald Bruce Stewart wrote: > >>ross: >> >>>At some point we need to agree a list of category names (or to just >>>use the top level of the module hierarchy instead). >> >>Regarding this, we'll make things (a little) easier by reusing >>(roughly) the categories from existing package systems. Some kind of >>intersectoin between say, openbsd and debian and gentoo. Here's the >>openbsd package categories: >> > > ... > >>Merge this with say debians categories, and add our own. > > > Debian *has* categories (called sections), but is trying to get rid of > them. They are currently working on (it's in unstable and mostly working) > a replacement system, debtags. debtags differs from the section system > in that packages can have multiple tags, and queries can include conjunctions > and disjunctions; IME this makes it much more useful (speaking as an unstable- > tracker). Perhaps we should look into copying debtags's ideas? (we need to > support some kind of tagging, for the sake of package generation) > > The main debtags site: http://debtags.alioth.debian.org/ Using a tagging-style categorisation for packages gets my vote. It's just a shame that we're stuck with a hierarchy for module names :-) BTW, Ross - the web interface looks great, nice work. Cheers, Simon From bulat.ziganshin at gmail.com Fri Jan 5 12:42:50 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Jan 5 12:39:36 2007 Subject: Hackage interface In-Reply-To: <459E7C48.2010807@microsoft.com> References: <20070103104839.GA8509@soi.city.ac.uk> <20070105003718.GA24629@soi.city.ac.uk> <20070105004323.GA27673@cse.unsw.EDU.AU> <20070105005021.GA3134@localhost.localdomain> <459E7C48.2010807@microsoft.com> Message-ID: <1003307244.20070105204250@gmail.com> Hello Simon, Friday, January 5, 2007, 7:26:48 PM, you wrote: >>>>At some point we need to agree a list of category names (or to just >>>>use the top level of the module hierarchy instead). there are already two categorizations - in HCAR and "libraries and tools" page -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From conal at conal.net Sun Jan 7 13:42:24 2007 From: conal at conal.net (Conal Elliott) Date: Sun Jan 7 13:38:38 2007 Subject: getting cabal to pass more info to haddock Message-ID: I want Cabal to pass the source-module and source-entity flags to haddock. I can probably figure out how to add these flags into the Cabal source (following the example of --hoogle), but I wonder if there's a better way. Any suggestions? If source mod, is there a process for me to follow? To whom would I send the patch? Thanks, - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20070107/92d0f3e3/attachment.htm From duncan.coutts at worc.ox.ac.uk Sun Jan 7 13:52:27 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Jan 7 13:50:17 2007 Subject: getting cabal to pass more info to haddock In-Reply-To: References: Message-ID: <1168195947.19455.97.camel@localhost> On Sun, 2007-01-07 at 10:42 -0800, Conal Elliott wrote: > I want Cabal to pass the source-module and source-entity flags to > haddock. I can probably figure out how to add these flags into the > Cabal source (following the example of --hoogle), but I wonder if > there's a better way. Any suggestions? runhaskell Setup.hs configure --haddock-args="--source-module=..." > If source mod, is there a process for me to follow? To whom would I > send the patch? If you use 'darcs send' to send in your patch then it should just work, the address has already been set. If darcs send doesn't work for you (eg if you've not got local mail working) then you can email it to the cabal-devel@haskell.org mailing list. Duncan From conal at conal.net Sun Jan 7 15:32:01 2007 From: conal at conal.net (Conal Elliott) Date: Sun Jan 7 15:28:16 2007 Subject: getting cabal to pass more info to haddock In-Reply-To: <1168195947.19455.97.camel@localhost> References: <1168195947.19455.97.camel@localhost> Message-ID: Thanks. Looks simple enough, and I compiled up a version that works this way. I don't know how to get ghc to use it. When I "./setup install", I get Cabal-1.1.7 registered, but my ghc-6.6 wants to use Cabal-1.1.6instead. Worse, I unregistered 1.1.6, and now I can't use cabal at all with ghc. Do you know how get 1.1.6 back short of re-installing ghc? BTW, I noticed in the function "haddock" in Distribution.Simple, the line "++ programArgs confHaddock", which leads me to suspect that there's an approach getting extra Haddock arguments passed by tweaking my Setup.lhs. Is that so? Cheers, - Conal On 1/7/07, Duncan Coutts wrote: > > On Sun, 2007-01-07 at 10:42 -0800, Conal Elliott wrote: > > I want Cabal to pass the source-module and source-entity flags to > > haddock. I can probably figure out how to add these flags into the > > Cabal source (following the example of --hoogle), but I wonder if > > there's a better way. Any suggestions? > > runhaskell Setup.hs configure --haddock-args="--source-module=..." > > > If source mod, is there a process for me to follow? To whom would I > > send the patch? > > If you use 'darcs send' to send in your patch then it should just work, > the address has already been set. If darcs send doesn't work for you (eg > if you've not got local mail working) then you can email it to the > cabal-devel@haskell.org mailing list. > > Duncan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20070107/44e293fd/attachment-0001.htm From duncan.coutts at worc.ox.ac.uk Sun Jan 7 15:43:10 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Jan 7 15:40:23 2007 Subject: getting cabal to pass more info to haddock In-Reply-To: References: <1168195947.19455.97.camel@localhost> Message-ID: <1168202590.19455.106.camel@localhost> On Sun, 2007-01-07 at 12:32 -0800, Conal Elliott wrote: > Thanks. Looks simple enough, and I compiled up a version that works > this way. I don't know how to get ghc to use it. When I "./setup > install", I get Cabal-1.1.7 registered, but my ghc-6.6 wants to use > Cabal-1.1.6 instead. Try cleaning and rebuilding your prog, you've probably got existing .hi files that refer to the older package version. That or perhaps you are using other packages that were built against Cabal-1.1.6, eg the ghc api package. You can force ghc to use a specific version using "ghc -package Cabal-1.1.7" and see what it complains about. > Worse, I unregistered 1.1.6, and now I can't use cabal at all with > ghc. Do you know how get 1.1.6 back short of re-installing ghc? You can re-register the old version, though I'm not sure where you can get the right package.conf file from. If you built from source you can grab the file from the build tree. If you installed from a distro package then re-installing that should be easy. > BTW, I noticed in the function "haddock" in Distribution.Simple , the > line "++ programArgs confHaddock", which leads me to suspect that > there's an approach getting extra Haddock arguments passed by tweaking > my Setup.lhs. Is that so? Ask on the cabal-devel list, I'm not sure without delving into the code. Duncan From conal at conal.net Sun Jan 7 16:10:50 2007 From: conal at conal.net (Conal Elliott) Date: Sun Jan 7 16:07:02 2007 Subject: getting cabal to pass more info to haddock In-Reply-To: <1168202590.19455.106.camel@localhost> References: <1168195947.19455.97.camel@localhost> <1168202590.19455.106.camel@localhost> Message-ID: It was indeed an old .hi file. Thanks! - Conal On 1/7/07, Duncan Coutts wrote: > > On Sun, 2007-01-07 at 12:32 -0800, Conal Elliott wrote: > > Thanks. Looks simple enough, and I compiled up a version that works > > this way. I don't know how to get ghc to use it. When I "./setup > > install", I get Cabal-1.1.7 registered, but my ghc-6.6 wants to use > > Cabal-1.1.6 instead. > > Try cleaning and rebuilding your prog, you've probably got existing .hi > files that refer to the older package version. That or perhaps you are > using other packages that were built against Cabal-1.1.6, eg the ghc api > package. You can force ghc to use a specific version using "ghc -package > Cabal-1.1.7" and see what it complains about. > > > Worse, I unregistered 1.1.6, and now I can't use cabal at all with > > ghc. Do you know how get 1.1.6 back short of re-installing ghc? > > You can re-register the old version, though I'm not sure where you can > get the right package.conf file from. If you built from source you can > grab the file from the build tree. If you installed from a distro > package then re-installing that should be easy. > > > BTW, I noticed in the function "haddock" in Distribution.Simple , the > > line "++ programArgs confHaddock", which leads me to suspect that > > there's an approach getting extra Haddock arguments passed by tweaking > > my Setup.lhs. Is that so? > > Ask on the cabal-devel list, I'm not sure without delving into the code. > > Duncan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20070107/6ad9ea6b/attachment.htm From ashley at semantic.org Mon Jan 8 18:20:29 2007 From: ashley at semantic.org (Ashley Yakeley) Date: Mon Jan 8 18:16:57 2007 Subject: Multiple .cabal Files Message-ID: Is there a way to tell cabal to pick a particular .cabal file when there are several in the current directory? -- Ashley Yakeley From duncan.coutts at worc.ox.ac.uk Mon Jan 8 19:51:30 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Jan 8 19:48:12 2007 Subject: Multiple .cabal Files In-Reply-To: References: Message-ID: <1168303891.19455.220.camel@localhost> On Mon, 2007-01-08 at 15:20 -0800, Ashley Yakeley wrote: > Is there a way to tell cabal to pick a particular .cabal file when there > are several in the current directory? Not at the moment, no. Duncan From conal at conal.net Mon Jan 8 21:19:33 2007 From: conal at conal.net (Conal Elliott) Date: Mon Jan 8 21:15:42 2007 Subject: getting cabal to pass more info to haddock In-Reply-To: <1168195947.19455.97.camel@localhost> References: <1168195947.19455.97.camel@localhost> Message-ID: I gave Cabal a --haddock-arg flag (use one per haddock argument), so now I can have a make rule like: haddock: config ./setup haddock --haddock-arg="--source-base= http://darcs.haskell.org/packages/TV" --haddock-arg='--source-module=src/%{MODULE/.//}.html' --haddock-arg='--source-entity=src/%{MODULE/.//}.html#%{NAME}' Works fine so far. I'd like feedback on the interface before darcs-sending the patch. I started with a --haddock-args flag to hold any number of haddock options, but the arguments then got passed as a single argument to haddock, which then couldn't make sense of them. So instead, you use one --haddock-arg flag per haddock flag. I'd also like some suggestions on the following: For syntax coloring and anchoring, I use this rule, gleaned Malcolm's hscolour page (http://www.cs.york.ac.uk/fp/darcs/hscolour): hscolour: for file in $(sources); \ do HsColour -anchorHTML $$file >$(doc)/`dirname $$file`/`basename $$file .hs`.html; \ done It's a pain, though, as I have to make sure the required directories are all present. For that purpose, I have this rule: # Make the doc directories we need. colorPrep: if [ ! -d $(doc)/src/Graphics/UI/TV ]; then mkdir $(doc)/src{,/Graphics{,/UI{,/TV}}}; fi And I have to remember to do "make colorPrep" before "make hscolour". Not very convenient especially if my package's module hierarchy branches. Comments? - Conal On 1/7/07, Duncan Coutts wrote: > > On Sun, 2007-01-07 at 10:42 -0800, Conal Elliott wrote: > > I want Cabal to pass the source-module and source-entity flags to > > haddock. I can probably figure out how to add these flags into the > > Cabal source (following the example of --hoogle), but I wonder if > > there's a better way. Any suggestions? > > runhaskell Setup.hs configure --haddock-args="--source-module=..." > > > If source mod, is there a process for me to follow? To whom would I > > send the patch? > > If you use 'darcs send' to send in your patch then it should just work, > the address has already been set. If darcs send doesn't work for you (eg > if you've not got local mail working) then you can email it to the > cabal-devel@haskell.org mailing list. > > Duncan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20070108/3ade1839/attachment.htm From conal at conal.net Tue Jan 9 00:52:19 2007 From: conal at conal.net (Conal Elliott) Date: Tue Jan 9 00:48:28 2007 Subject: Idea to allow people to comment on Haskell docs In-Reply-To: <200601181054.06419.benjamin.franksen@bessy.de> References: <036EAC76E7F5EC4996A3B3C3657D4116043847B3@EUR-MSG-21.europe.corp.microsoft.com> <200601181054.06419.benjamin.franksen@bessy.de> Message-ID: I'm developing some libraries and want to set up the haddock docs with comment wiki pages, as in this discussion thread. I see that the haddock flags are there. Is anyone using them? Any ideas on how to get the per-entity sectioning into a wiki page (== myFnName ==). Or would we be better off having a page per entity? I wonder how a library author or other interested person could track the comments when there can be at least one wiki page per module (if not one per entity). Any ideas? Can one "watch" a whole tree of wiki pages (including ones that don't yet exist)? - Conal On 1/18/06, Benjamin Franksen wrote: > > On Wednesday 18 January 2006 10:01, Simon Peyton-Jones wrote: > > Does MediaWiki support anchors in the middle of a page? That's > > essential here -- we want one Wiki page for one Haddock page. > > Yes. See, for example, the EPICS wiki at > http://www.aps.anl.gov/epics/wiki/index.php/Main_Page. > > BTW, one of the most useful features of MediaWiki are the per-section > edit command links at the right margin. If you select the edit link > corresponding to a certain section, you'll get only the text of this > section in the text-edit widget and when previewing your changes you'll > see only the section you edited. (Of course you can also edit the whole > page at once, using the top-most edit link.) > > Ben > _______________________________________________ > 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/20070108/ac9a3ecb/attachment.htm From conal at conal.net Tue Jan 9 01:06:21 2007 From: conal at conal.net (Conal Elliott) Date: Tue Jan 9 01:02:30 2007 Subject: where to put project pages on haskell wiki? Message-ID: Are there any thoughts or even consensus on where to place project/package pages on http://haskell.org/haskellwiki? I don't see any common structure. Haskore & Hoogle have pages right under haskellwiki. Another idea is to put them by Cabal package name under http://haskell.org/haskellwiki/Package. - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20070108/075f6167/attachment-0001.htm From conal at conal.net Tue Jan 9 01:26:37 2007 From: conal at conal.net (Conal Elliott) Date: Tue Jan 9 01:22:45 2007 Subject: haddock suggestion -- %{FILE} Message-ID: I pre-process my source code before handing to haddock. The %{FILE} directive for --source-comments etc uses the actual preprocessed file name rather than the the original, which is not what I want. Is this just an oversight? - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20070108/b3303aa3/attachment.htm From duncan.coutts at worc.ox.ac.uk Tue Jan 9 04:45:32 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Jan 9 04:42:11 2007 Subject: haddock suggestion -- %{FILE} In-Reply-To: References: Message-ID: <1168335932.19455.230.camel@localhost> (oops, I meant to reply to the list as well as to Conal) On Mon, 2007-01-08 at 22:26 -0800, Conal Elliott wrote: > I pre-process my source code before handing to haddock. The %{FILE} > directive for --source-comments etc uses the actual preprocessed file > name rather than the the original, which is not what I want. Is this > just an oversight? If your pre-processor uses the C or Haskell line pragmas then haddock (as of version 0.8) will know the original file name and the links to source will work (I've tested it). So the question is, what pre-processor are you using, and how can we persuade it to emit C or Haskell line pragmas. cpp can do it, as can cpphs, hsc2hs, c2hs, alex, happy etc. It may be that they don't all do it by default at the moment, or that Cabal doesn't instruct them to do it by default. Previous versions of haddock didn't cope with C style line pragmas iirc so I think they used to be disabled for cpp/cpphs. Duncan From ndmitchell at gmail.com Tue Jan 9 05:01:11 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Jan 9 04:57:19 2007 Subject: where to put project pages on haskell wiki? In-Reply-To: References: Message-ID: <404396ef0701090201v71761c42ja63bb74f4e68dc1e@mail.gmail.com> Hi On 1/9/07, Conal Elliott wrote: > Are there any thoughts or even consensus on where to place project/package > pages on http://haskell.org/haskellwiki? I don't see any common structure. > Haskore & Hoogle have pages right under haskellwiki. Another idea is to put > them by Cabal package name under > http://haskell.org/haskellwiki/Package. So does Yhc, GHC etc. The wiki is primarily intended to be "flat", with just separate pages for parts of the same project. Thanks Neil From jeremy.odonoghue at gmail.com Tue Jan 9 05:35:31 2007 From: jeremy.odonoghue at gmail.com (Jeremy O'Donoghue) Date: Tue Jan 9 05:31:38 2007 Subject: Multiple .cabal Files In-Reply-To: <1168303891.19455.220.camel@localhost> References: <1168303891.19455.220.camel@localhost> Message-ID: Oddly, I was about to ask almost exactly the same question. The supplementary is: I'm trying to convert wxHaskell to use a cabal based build system. Building wxHaskell (somewhat simplified) consists of the following steps: 1) Build wxc, a library which provides C callable functions for the C++ methods in wxWidgets. This is really a C project, and I don't think cabal is the appropriate tool. I have a makefile for this. 2) Build wxdirect, an automated FFI generator. This is pure Haskell. I have a cabal build for this. 3) Build wxcore library. This is a low-level Haskell wrapper around the wxc library which is essentially autogenerated using wxdirect. I have a cabal build for this. 4) Build wx library. This is a higher level Haskell library which depends on wxcore. I have a cabal build for this. The problem is that I have currently put the three cabal builds in separate directories, which makes the whole thing rather messy. Is there some way to specify the basic dependencies that: wx depends on wxcore wxcore depends on running wxdirect on some set of files wxdirect tool (an executable) needs to be built first. It would seem to me like this is probably a fairly common pattern in any project which wraps a substantial external library, as the approach is: automatically wrap the C API to give a low level (basically imperative) Haskell API; wrap the low level API in something more 'Haskellish'. I'm looking for a suggested approach. I could roll my own, but it sounds like there is a generic pattern here, so I'd rather (if I have to) write something others can also use (or, better, use something others have already done ;-) Regards Jeremy On 09/01/07, Duncan Coutts wrote: > On Mon, 2007-01-08 at 15:20 -0800, Ashley Yakeley wrote: > > Is there a way to tell cabal to pick a particular .cabal file when there > > are several in the current directory? > > Not at the moment, no. > > Duncan > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From duncan.coutts at worc.ox.ac.uk Tue Jan 9 06:25:34 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Jan 9 06:22:14 2007 Subject: Multiple .cabal Files In-Reply-To: References: <1168303891.19455.220.camel@localhost> Message-ID: <1168341934.19455.248.camel@localhost> On Tue, 2007-01-09 at 10:35 +0000, Jeremy O'Donoghue wrote: > Oddly, I was about to ask almost exactly the same question. > > The supplementary is: > > I'm trying to convert wxHaskell to use a cabal based build system. I have similar issues in trying to convert Gtk2Hs to use Cabal. Basically Cabal doesn't yet have any coherent story for larger projects like Gtk2Hs, wxHaskell, GHC etc that are made up of many components and where some bits are needed to generate others. We're really only just past the early phase of Cabal development which was aimed at making simple libs/progs easy to build. So basically we need to discuss what we would like for larger projects and come up with a design. We also need volunteers to implement proposals (of course if these are one and the same then there's a good incentive to keep things simple!) Either this mailing list or the cabal-devel list is the appropriate place for such discussions. Duncan From lemming at henning-thielemann.de Tue Jan 9 07:12:56 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Jan 9 07:09:41 2007 Subject: Multiple .cabal Files In-Reply-To: References: Message-ID: On Mon, 8 Jan 2007, Ashley Yakeley wrote: > Is there a way to tell cabal to pick a particular .cabal file when there are > several in the current directory? I had the same question earlier. If multiple .cabal files are supported, there must also be multiple .installed-pkg-config and .setup-config files. From frederik at a5.repetae.net Tue Jan 9 08:49:08 2007 From: frederik at a5.repetae.net (Frederik Eaton) Date: Tue Jan 9 08:45:21 2007 Subject: Multiple .cabal Files In-Reply-To: References: Message-ID: <20070109134908.GA13107@a5.repetae.net> On Tue, Jan 09, 2007 at 01:12:56PM +0100, Henning Thielemann wrote: > > On Mon, 8 Jan 2007, Ashley Yakeley wrote: > > > Is there a way to tell cabal to pick a particular .cabal file when there are > > several in the current directory? > > I had the same question earlier. If multiple .cabal files are supported, > there must also be multiple .installed-pkg-config and .setup-config files. I've always seen this as a major issue with the design of Cabal. Why should there have to be a single file named XXX.cabal when XXX doesn't actually have a meaning to the Cabal system? If there can only be one such file, then it should be called Cabalfile or somesuch. On the other hand, if users are going to be asked to pick a name for their Cabal file, then multiple files should be allowed. The answer I've always received is that "someday multiple cabal files will be allowed". However, if that is the case (and I think it should be) then I think it would be better to start planning for such use as early as possible. Otherwise people start depending on things like .setup-config which may change in new versions of Cabal. And I imagine there are tools which currently depend on having a single Cabal-file in a directory, which will have to be changed as well. Although I don't have time to devote to this problem, anyone who does will have my special gratitude. Best wishes, Frederik -- http://ofb.net/~frederik/ From bulat.ziganshin at gmail.com Tue Jan 9 09:26:37 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Jan 9 09:23:57 2007 Subject: where to put project pages on haskell wiki? In-Reply-To: References: Message-ID: <418745048.20070109172637@gmail.com> Hello Conal, Tuesday, January 9, 2007, 9:06:21 AM, you wrote: > Are there any thoughts or even consensus on where to place project/package pages on http://haskell.org/haskellwiki?? I don't see any common structure.? Haskore & Hoogle have pages right under haskellwiki.? Another idea is to put them by Cabal package name under http://haskell.org/haskellwiki/Package.? i create pages under Library: http://haskell.org/haskellwiki/Library/ArrayRef http://haskell.org/haskellwiki/Library/Streams so on -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From conal at conal.net Tue Jan 9 12:32:02 2007 From: conal at conal.net (Conal Elliott) Date: Tue Jan 9 12:28:20 2007 Subject: haddock suggestion -- %{FILE} In-Reply-To: <1168335932.19455.230.camel@localhost> References: <1168335932.19455.230.camel@localhost> Message-ID: The only pre-processing is what's caused by using the cabal directive "Extensions: CPP". Using "./setup haddock --verbose ...", I get lines like c:\ghc\ghc-6.6\bin\ghc.exe -E -cpp -optP-P -o dist\build\tmp\src\Graphics\UI\TV\Input.hs src\Graphics\UI\TV\Input.hs -Dmingw32_BUILD_OS -Dmingw32_HOST_OS -Di386_BUILD_ARCH -Di386_HOST_ARCH -D__GLASGOW_HASKELL__=606 -D__HADDOCK__ When I try this preprocessing myself, I find that I *do not* get the Haskell line pragma: bash-3.2$ ghc -E -cpp -optP-P -o z src/Graphics/UI/TV/Input.hs -Dmingw32_BUILD_OS -Dmingw32_HOST_OS -Di386_BUILD_ARCH -Di386_HOST_ARCH -D__GLASGOW_HASKELL__=606 -D__HADDOCK__; head -3 z {-# OPTIONS -fglasgow-exts -cpp #-} ---------------------------------------------------------------------- Fiddling with flags, I see that -optP-P is the culprit. Removing it: bash-3.2$ ghc -E -cpp -o z src/Graphics/UI/TV/Input.hs -Dmingw32_BUILD_OS -Dmingw32_HOST_OS -Di386_BUILD_ARCH -Di386_HOST_ARCH -D__GLASGOW_HASKELL__=606 -D__HADDOCK__; head -3 z # 1 "src/Graphics/UI/TV/Input.hs" # 1 "" # 1 "" bash-3.2$ Any ideas? - Conal On 1/9/07, Duncan Coutts wrote: > > (oops, I meant to reply to the list as well as to Conal) > > On Mon, 2007-01-08 at 22:26 -0800, Conal Elliott wrote: > > I pre-process my source code before handing to haddock. The %{FILE} > > directive for --source-comments etc uses the actual preprocessed file > > name rather than the the original, which is not what I want. Is this > > just an oversight? > > If your pre-processor uses the C or Haskell line pragmas then haddock > (as of version 0.8) will know the original file name and the links to > source will work (I've tested it). > > So the question is, what pre-processor are you using, and how can we > persuade it to emit C or Haskell line pragmas. cpp can do it, as can > cpphs, hsc2hs, c2hs, alex, happy etc. > > It may be that they don't all do it by default at the moment, or that > Cabal doesn't instruct them to do it by default. Previous versions of > haddock didn't cope with C style line pragmas iirc so I think they used > to be disabled for cpp/cpphs. > > Duncan > > > _______________________________________________ > 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/20070109/d3a91c64/attachment-0001.htm From Malcolm.Wallace at cs.york.ac.uk Tue Jan 9 12:43:22 2007 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Jan 9 12:41:24 2007 Subject: haddock suggestion -- %{FILE} In-Reply-To: References: <1168335932.19455.230.camel@localhost> Message-ID: <20070109174322.0a9702b5.Malcolm.Wallace@cs.york.ac.uk> "Conal Elliott" wrote: > Fiddling with flags, I see that -optP-P is the culprit. Removing it: > > bash-3.2$ ghc -E -cpp -o z src/Graphics/UI/TV/Input.hs > -Dmingw32_BUILD_OS -Dmingw32_HOST_OS -Di386_BUILD_ARCH > -Di386_HOST_ARCH -D__GLASGOW_HASKELL__=606 -D__HADDOCK__; head -3 z > # 1 "src/Graphics/UI/TV/Input.hs" > # 1 "" > # 1 "" This may not answer your question, but assuming you want to get rid of the last two lines, keeping only the first, have you tried using the options -pgmPcpphs -optP-cpp (with a recent version of cpphs)? Regards, Malcolm From duncan.coutts at worc.ox.ac.uk Tue Jan 9 13:25:10 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Jan 9 13:21:49 2007 Subject: haddock suggestion -- %{FILE} In-Reply-To: References: <1168335932.19455.230.camel@localhost> Message-ID: <1168367110.19455.316.camel@localhost> On Tue, 2007-01-09 at 09:32 -0800, Conal Elliott wrote: > The only pre-processing is what's caused by using the cabal directive > "Extensions: CPP". > Fiddling with flags, I see that -optP-P is the culprit. Removing it: > > bash-3.2$ ghc -E -cpp -o z src/Graphics/UI/TV/Input.hs > -Dmingw32_BUILD_OS -Dmingw32_HOST_OS -Di386_BUILD_ARCH > -Di386_HOST_ARCH -D__GLASGOW_HASKELL__=606 -D__HADDOCK__; head -3 z > # 1 "src/Graphics/UI/TV/Input.hs" > # 1 "" > # 1 "" > bash-3.2$ > Any ideas? - Conal So for a quick hack, modify Cabal to unconditionally omit -optP-P and see if that makes all your links come out right. Probably the right thing to do however is to have Cabal use the -optP-P option only when we're using haddock-0.7 or older (otherwise haddock-0.7 users will get a lexical error when haddock encounters the C line pragmas). I think at the moment Cabal doesn't check haddock's version number at all. So that's something to look at if you or anyone else want to come up with a patch for this. Duncan From conal at conal.net Tue Jan 9 13:51:46 2007 From: conal at conal.net (Conal Elliott) Date: Tue Jan 9 13:47:58 2007 Subject: haddock suggestion -- %{FILE} In-Reply-To: <20070109174322.0a9702b5.Malcolm.Wallace@cs.york.ac.uk> References: <1168335932.19455.230.camel@localhost> <20070109174322.0a9702b5.Malcolm.Wallace@cs.york.ac.uk> Message-ID: I don't know what -optP-P or these other flags are. Do you know where they're documented? In any case, the context here is that cabal is controlling the preprocessing. So whatever the solution is, I'd like it to come from or through cabal. Cheers, - Conal On 1/9/07, Malcolm Wallace wrote: > > "Conal Elliott" wrote: > > > Fiddling with flags, I see that -optP-P is the culprit. Removing it: > > > > bash-3.2$ ghc -E -cpp -o z src/Graphics/UI/TV/Input.hs > > -Dmingw32_BUILD_OS -Dmingw32_HOST_OS -Di386_BUILD_ARCH > > -Di386_HOST_ARCH -D__GLASGOW_HASKELL__=606 -D__HADDOCK__; head -3 z > > # 1 "src/Graphics/UI/TV/Input.hs" > > # 1 "" > > # 1 "" > > This may not answer your question, but assuming you want to get rid of > the last two lines, keeping only the first, have you tried using the > options -pgmPcpphs -optP-cpp (with a recent version of cpphs)? > > Regards, > Malcolm > _______________________________________________ > 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/20070109/7c894eed/attachment.htm From conal at conal.net Tue Jan 9 14:22:31 2007 From: conal at conal.net (Conal Elliott) Date: Tue Jan 9 14:18:37 2007 Subject: haddock suggestion -- %{FILE} In-Reply-To: <1168367110.19455.316.camel@localhost> References: <1168335932.19455.230.camel@localhost> <1168367110.19455.316.camel@localhost> Message-ID: Commenting out the -optP-P in Haddock's PreProcess.hs fixes the problem. Thanks. Any takers for Duncan's suggested fix? - Conal On 1/9/07, Duncan Coutts wrote: > > On Tue, 2007-01-09 at 09:32 -0800, Conal Elliott wrote: > > The only pre-processing is what's caused by using the cabal directive > > "Extensions: CPP". > > > Fiddling with flags, I see that -optP-P is the culprit. Removing it: > > > > bash-3.2$ ghc -E -cpp -o z src/Graphics/UI/TV/Input.hs > > -Dmingw32_BUILD_OS -Dmingw32_HOST_OS -Di386_BUILD_ARCH > > -Di386_HOST_ARCH -D__GLASGOW_HASKELL__=606 -D__HADDOCK__; head -3 z > > # 1 "src/Graphics/UI/TV/Input.hs" > > # 1 "" > > # 1 "" > > bash-3.2$ > > > Any ideas? - Conal > > So for a quick hack, modify Cabal to unconditionally omit -optP-P and > see if that makes all your links come out right. > > Probably the right thing to do however is to have Cabal use the -optP-P > option only when we're using haddock-0.7 or older (otherwise haddock-0.7 > users will get a lexical error when haddock encounters the C line > pragmas). > > I think at the moment Cabal doesn't check haddock's version number at > all. So that's something to look at if you or anyone else want to come > up with a patch for this. > > > Duncan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20070109/c08e14ac/attachment.htm From dmhouse at gmail.com Tue Jan 9 14:38:46 2007 From: dmhouse at gmail.com (David House) Date: Tue Jan 9 14:35:10 2007 Subject: where to put project pages on haskell wiki? In-Reply-To: References: Message-ID: On 09/01/07, Conal Elliott wrote: > Haskore & Hoogle have pages right under haskellwiki. That's the first place I'd look to find a given project, so that's the best place for them. -- -David House, dmhouse@gmail.com From ashley at semantic.org Tue Jan 9 18:34:33 2007 From: ashley at semantic.org (Ashley Yakeley) Date: Tue Jan 9 18:30:58 2007 Subject: where to put project pages on haskell wiki? In-Reply-To: References: Message-ID: Conal Elliott wrote: > Are there any thoughts or even consensus on where to place > project/package pages on http://haskell.org/haskellwiki? I don't see > any common structure. Haskore & Hoogle have pages right under > haskellwiki. Another idea is to put them by Cabal package name under > http://haskell.org/haskellwiki/Package. Generally all projects, concepts and so forth should be at the top level, it makes things easier to find and link to. But feel free to use hierarchy a particular project. For instance, from page "GHC", [[/FAQ]] links to "GHC/FAQ". -- Ashley Yakeley From marco-oweber at gmx.de Tue Jan 9 20:52:52 2007 From: marco-oweber at gmx.de (Marc Weber) Date: Tue Jan 9 19:49:04 2007 Subject: Is there already a list class? Message-ID: <20070110015252.GA29286@gmx.de> Hello. Is here the right place to request a list class? eg class List l e where (:) :: e -> l e -> l e head :: .. This might be used in Data.Set, Data.Map class StorableAsList l e t where fromList :: l e -> t toList :: t -> l e I'd like to help implementing/ writing it. Do you consider this beeing a useful enhancement? Cheers Marc Weber From haskell at brecknell.org Tue Jan 9 20:23:20 2007 From: haskell at brecknell.org (Matthew Brecknell) Date: Tue Jan 9 20:23:05 2007 Subject: Is there already a list class? In-Reply-To: <20070110015252.GA29286@gmx.de> References: <20070110015252.GA29286@gmx.de> Message-ID: <1168392200.11437.1168459045@webmail.messagingengine.com> > Is here the right place to request a list class? > eg > class List l e where > (:) :: e -> l e -> l e > head :: .. > > This might be used in Data.Set, Data.Map > > class StorableAsList l e t where > fromList :: l e -> t > toList :: t -> l e > > I'd like to help implementing/ writing it. > > Do you consider this beeing a useful enhancement? I was looking for such a class just yesterday. I wanted a difference list over LazyByteString, and it seemed wrong just to rewrite Don Stewart's DList for byte strings without first having a list class. I would also like to help implement it. From conal at conal.net Tue Jan 9 20:32:43 2007 From: conal at conal.net (Conal Elliott) Date: Tue Jan 9 20:28:48 2007 Subject: haddock & web-friendly library links? In-Reply-To: <4582C444.8090600@microsoft.com> References: <4582C444.8090600@microsoft.com> Message-ID: I like your idea of placing a Haddock package URL in the .cabal file. Given the creativity of the Haskell community, it'll be important to have a mechanism for these cross-project links. I hope it gets some attention at Hac. Cheers, - Conal On 12/15/06, Simon Marlow wrote: > > Conal Elliott wrote: > > My library uses others (including base & wxHaskell), and so references > > to types & identifiers from those libraries show up in my Haddock docs. > > When I put the docs on the web, the links are bogus. How can I get > > those links to be web-accessible versions instead of my local versions? > > > > Similarly, I want to package up my library so that others can build on > > top of it and have their published haddock documentation contain > > web-accessible pointers to my doc. > > > > Have these issues been thought through? Thanks, > > I'm not suggesting that this is a long-term solution, but Haddock does let > you > link to docs at an arbitrary URL, using the --read-interface flag. This > isn't > exposed through Cabal, but you can always find out the Haddock command > that > Cabal is executing and run a modified version by hand. > > Ultimately I expect as part of the Hackage project we should automatically > generate Haddock docs for all the packages and link them together. This > needs > some thought, perhaps it's something we can talk about at Hac. > > Another thing we could consider doing is putting a public Haddock URL in > the > .cabal file, and propagating this into the package configuration. Then > when you > generate Haddock docs there could be an option to link to either local or > external docs for other packages. > > Cheers, > Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20070109/88998de0/attachment-0001.htm From seth at cql.com Tue Jan 9 20:31:11 2007 From: seth at cql.com (Seth Kurtzberg) Date: Tue Jan 9 20:28:54 2007 Subject: Is there already a list class? In-Reply-To: <1168392200.11437.1168459045@webmail.messagingengine.com> References: <20070110015252.GA29286@gmx.de> <1168392200.11437.1168459045@webmail.messagingengine.com> Message-ID: <20070109203111.edca7115.seth@cql.com> I've written some classes for this type of functionality as well. I think what I've written can be generalized, so I'd like to participate if folks decide to pursue this. Seth Kurtzberg On Wed, 10 Jan 2007 11:23:20 +1000 "Matthew Brecknell" wrote: > > Is here the right place to request a list class? > > eg > > class List l e where > > (:) :: e -> l e -> l e > > head :: .. > > > > This might be used in Data.Set, Data.Map > > > > class StorableAsList l e t where > > fromList :: l e -> t > > toList :: t -> l e > > > > I'd like to help implementing/ writing it. > > > > Do you consider this beeing a useful enhancement? > > I was looking for such a class just yesterday. I wanted a difference > list over LazyByteString, and it seemed wrong just to rewrite Don > Stewart's DList for byte strings without first having a list class. > > I would also like to help implement it. > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From droundy at darcs.net Tue Jan 9 20:54:11 2007 From: droundy at darcs.net (David Roundy) Date: Tue Jan 9 20:50:18 2007 Subject: Is there already a list class? In-Reply-To: <20070110015252.GA29286@gmx.de> References: <20070110015252.GA29286@gmx.de> Message-ID: <20070110015409.GA7589@abridgegame.org> On Wed, Jan 10, 2007 at 02:52:52AM +0100, Marc Weber wrote: > Is here the right place to request a list class? > eg > class List l e where > (:) :: e -> l e -> l e > head :: .. > > This might be used in Data.Set, Data.Map > > class StorableAsList l e t where > fromList :: l e -> t > toList :: t -> l e > > I'd like to help implementing/ writing it. > > Do you consider this beeing a useful enhancement? This is a major part of my wishlist for a new set of libraries in the post-Haskell' era (or perhaps for Haskell'). Rewriting the prelude (which is essentially what you're suggesting) and standard libraries is part of the haskell' effort, and most people I have talked with would prefer to reduce its size as far as possible. Alas, I don't forsee having any time for this in the forseeable future, but I've got lots of ideas. I think you'd want a higher-kinded list type rather than a MPTC: class List l where cons :: e -> l e -> l e -- you can't make a constructor a member of a class head :: l e -> e null :: l e -> Bool empty :: l e ... Also on the wishlist would be to rename fmap to map, and add an instance instance List l => Functor l where map :: (a -> b) -> l a -> l b map f l | null l = empty | otherwise = f (head l) `cons` tail l Ideally, I'd like the prelude contain almost no functions that are not defined within a class, so that we could apply all the standard prelude functions to any reasonable data type we wish. In my opinion, the API provided by modules like Data.Map and Data.FastPackedString which we are forced to import qualified because they conflict with the Prelude are an abomination forced upon us by the short-sighted design of the Prelude. The only argument for not putting these functions into classes is that it would make error messages harder for students. There have been multiple suggestions for alleviating that, ranging from better compiler error messages (pretty hard) to a special "easy" prelude. The latter seems like a better idea. There are some difficulties, however, such as the trickiness that some data structures (which you'd like to use the same interface) have constraints, such as they require that the stored type be in class Ord. These issues are a real pain, and I know other people have thought long and hard about it, but I haven't. -- David Roundy Department of Physics Oregon State University From sjanssen at cse.unl.edu Tue Jan 9 21:12:54 2007 From: sjanssen at cse.unl.edu (Spencer Janssen) Date: Tue Jan 9 21:09:16 2007 Subject: Is there already a list class? In-Reply-To: <20070110015252.GA29286@gmx.de> References: <20070110015252.GA29286@gmx.de> Message-ID: <448AAAEE-E8BB-41AB-9E20-EB53FB939940@cse.unl.edu> On Jan 9, 2007, at 7:52 PM, Marc Weber wrote: > Hello. > > Is here the right place to request a list class? > eg > class List l e where > (:) :: e -> l e -> l e > head :: .. Note that this approach isn't quite flexible enough. Your example forces the container type to have kind * -> *, and therefore can't support certain specialized containers like ByteString. There is a class like this in the Edison library (http:// www.eecs.tufts.edu/~rdocki01/edison.html), it is called Seq (Haddocks: http://www.eecs.tufts.edu/~rdocki01/docs/edison/Data- Edison-Seq.html). However, it suffers the same kind flexibility issues as your List class. Other classes in Edison take a MPTC +fundep approach and I'm not sure why Seq doesn't. Can you comment on this, Rob? > This might be used in Data.Set, Data.Map > > class StorableAsList l e t where > fromList :: l e -> t > toList :: t -> l e This is subsumed by other Edison functionality. > I'd like to help implementing/ writing it. > > Do you consider this beeing a useful enhancement? Oh yes, but let's avoid reinventing the wheel if at all possible. Spencer Janssen From droundy at darcs.net Tue Jan 9 21:35:03 2007 From: droundy at darcs.net (David Roundy) Date: Tue Jan 9 21:31:25 2007 Subject: Is there already a list class? In-Reply-To: <20070110015409.GA7589@abridgegame.org> References: <20070110015252.GA29286@gmx.de> <20070110015409.GA7589@abridgegame.org> Message-ID: <20070110023500.GB26604@abridgegame.org> On Tue, Jan 09, 2007 at 05:54:11PM -0800, David Roundy wrote: > I think you'd want a higher-kinded list type rather than a MPTC: > > class List l where > cons :: e -> l e -> l e -- you can't make a constructor a member of a class > head :: l e -> e > null :: l e -> Bool > empty :: l e > ... Okay, this was stupid of me. As Spencer points out, we wouldn't actually want a list type with kind * -> *, because we'd want to support specialized lists like Data.Bytestring. So we'd want something more like > class List l e, l -> e where > cons :: e -> l -> l > head :: l -> e > null :: l -> Bool > empty :: l > ... (But I don't like functional dependencies, because they confuse me, and hope that associated types end up making it into Haskell'...) -- David Roundy http://www.darcs.net From conal at conal.net Tue Jan 9 21:39:44 2007 From: conal at conal.net (Conal Elliott) Date: Tue Jan 9 21:35:50 2007 Subject: haddock & web-friendly library links? In-Reply-To: <4582C444.8090600@microsoft.com> References: <4582C444.8090600@microsoft.com> Message-ID: I fiddled with --read-interface to link to other-library docs at URLs. I'm trying to go through cabal and use --haddock-arg (a flag I recently added) to get additional flags to haddock. What seems to be happening is that --use-package wins over --read-interface for the same package, regardless of the order in which they're listed. The only way I can get the other-library links to point to web-documentation instead of local versions is to add --read-interface and *remove* the corresponding --use-package. Is that behavior what you intend? Given the use-package bias, I can't figure a way to get my web links via cabal. Using haddock manually would be quite a pain also, since I'm relying on cabal to preprocess all of my modules with -D__HADDOCK__ before passing them on to Haddock. The preprocessed versions come & go invisibly. Are you aware of the use-package bias? Can you think of a work-around? - Conal On 12/15/06, Simon Marlow wrote: > > Conal Elliott wrote: > > My library uses others (including base & wxHaskell), and so references > > to types & identifiers from those libraries show up in my Haddock docs. > > When I put the docs on the web, the links are bogus. How can I get > > those links to be web-accessible versions instead of my local versions? > > > > Similarly, I want to package up my library so that others can build on > > top of it and have their published haddock documentation contain > > web-accessible pointers to my doc. > > > > Have these issues been thought through? Thanks, > > I'm not suggesting that this is a long-term solution, but Haddock does let > you > link to docs at an arbitrary URL, using the --read-interface flag. This > isn't > exposed through Cabal, but you can always find out the Haddock command > that > Cabal is executing and run a modified version by hand. > > Ultimately I expect as part of the Hackage project we should automatically > generate Haddock docs for all the packages and link them together. This > needs > some thought, perhaps it's something we can talk about at Hac. > > Another thing we could consider doing is putting a public Haddock URL in > the > .cabal file, and propagating this into the package configuration. Then > when you > generate Haddock docs there could be an option to link to either local or > external docs for other packages. > > Cheers, > Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20070109/3ba88ed1/attachment.htm From conal at conal.net Tue Jan 9 21:51:24 2007 From: conal at conal.net (Conal Elliott) Date: Tue Jan 9 21:47:29 2007 Subject: haddock & web-friendly library links? In-Reply-To: References: <4582C444.8090600@microsoft.com> Message-ID: I also tried editing ghc's package.conf file to place the other library's HTML doc right into haddockHTMLs, replacing the pointer to my local copy. Then Haddock says: Warning: cannot use package phooey-0.1: HTML directory http://darcs.haskell.org/packages/phooey/doc does not exist. and I don't get any links. The directory does exist, though of course not on my machine. Why would Haddock care whether it can find a haddockHTMLs directory? - Conal On 1/9/07, Conal Elliott wrote: > > I fiddled with --read-interface to link to other-library docs at URLs. > I'm trying to go through cabal and use --haddock-arg (a flag I recently > added) to get additional flags to haddock. What seems to be happening is > that --use-package wins over --read-interface for the same package, > regardless of the order in which they're listed. The only way I can get the > other-library links to point to web-documentation instead of local versions > is to add --read-interface and *remove* the corresponding --use-package. Is > that behavior what you intend? Given the use-package bias, I can't figure a > way to get my web links via cabal. Using haddock manually would be quite a > pain also, since I'm relying on cabal to preprocess all of my modules with > -D__HADDOCK__ before passing them on to Haddock. The preprocessed versions > come & go invisibly. > > Are you aware of the use-package bias? Can you think of a work-around? > > - Conal > > On 12/15/06, Simon Marlow < simonmarhaskell@gmail.com> wrote: > > > > Conal Elliott wrote: > > > My library uses others (including base & wxHaskell), and so references > > > > > to types & identifiers from those libraries show up in my Haddock > > docs. > > > When I put the docs on the web, the links are bogus. How can I get > > > those links to be web-accessible versions instead of my local > > versions? > > > > > > Similarly, I want to package up my library so that others can build on > > > top of it and have their published haddock documentation contain > > > web-accessible pointers to my doc. > > > > > > Have these issues been thought through? Thanks, > > > > I'm not suggesting that this is a long-term solution, but Haddock does > > let you > > link to docs at an arbitrary URL, using the --read-interface flag. This > > isn't > > exposed through Cabal, but you can always find out the Haddock command > > that > > Cabal is executing and run a modified version by hand. > > > > Ultimately I expect as part of the Hackage project we should > > automatically > > generate Haddock docs for all the packages and link them together. This > > needs > > some thought, perhaps it's something we can talk about at Hac. > > > > Another thing we could consider doing is putting a public Haddock URL in > > the > > .cabal file, and propagating this into the package configuration. Then > > when you > > generate Haddock docs there could be an option to link to either local > > or > > external docs for other packages. > > > > Cheers, > > Simon > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20070109/e006ed43/attachment-0001.htm From conal at conal.net Wed Jan 10 00:58:09 2007 From: conal at conal.net (Conal Elliott) Date: Wed Jan 10 00:54:20 2007 Subject: WikiHaddock Message-ID: Suppose Haddock's documentation language ("-- | ...") were an extended form of a common wiki markup language, and specifically Wikimedia's, because the Haskell wiki uses it. Instead of converting to HTML, Haddock could then pass through most markup unchanged and make wiki links out of its current link markup (modules & entities). Some benefits: - We'd all get a much richer (and extensible) markup language. - We'd have only a single markup language (Wikimedia's) to learn instead of two, and no need to convert between them manually. - Automatically generated links to user-comment pages would be wiki links, so one could tell by looking at them whether there are any comments already there. Comments? - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20070109/c085c89e/attachment.htm From duncan.coutts at worc.ox.ac.uk Wed Jan 10 03:51:35 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Jan 10 03:48:11 2007 Subject: WikiHaddock In-Reply-To: References: Message-ID: <1168419095.19455.327.camel@localhost> On Tue, 2007-01-09 at 21:58 -0800, Conal Elliott wrote: > Suppose Haddock's documentation language ("-- | ...") were an extended > form of a common wiki markup language, and specifically Wikimedia's, > because the Haskell wiki uses it. Instead of converting to HTML, > Haddock could then pass through most markup unchanged and make wiki > links out of its current link markup (modules & entities). Haddock is designed to be able to produce various different output formats. It'd be perfectly reasonable to add a wkik markup backend. There's nothing that special about the html backend, it's just the most mature and most used. Duncan From jeanphilippe.bernardy at gmail.com Wed Jan 10 04:25:11 2007 From: jeanphilippe.bernardy at gmail.com (Jean-Philippe Bernardy) Date: Wed Jan 10 04:21:13 2007 Subject: Is there already a list class? In-Reply-To: <20070110023500.GB26604@abridgegame.org> References: <20070110015252.GA29286@gmx.de> <20070110015409.GA7589@abridgegame.org> <20070110023500.GB26604@abridgegame.org> Message-ID: <953e0d250701100125r7f68acei4281179f296c6407@mail.gmail.com> I suggest you have a look a the classes for collections that I've been working on. It's an attempt at unifying all collection types in a single framework of classes. darcs repository: http://darcs.haskell.org/packages/collections On 1/10/07, David Roundy wrote: > On Tue, Jan 09, 2007 at 05:54:11PM -0800, David Roundy wrote: > > I think you'd want a higher-kinded list type rather than a MPTC: > > > > class List l where > > cons :: e -> l e -> l e -- you can't make a constructor a member of a class > > head :: l e -> e > > null :: l e -> Bool > > empty :: l e > > ... > > Okay, this was stupid of me. As Spencer points out, we wouldn't actually > want a list type with kind * -> *, because we'd want to support specialized > lists like Data.Bytestring. So we'd want something more like > > > class List l e, l -> e where > > cons :: e -> l -> l > > head :: l -> e > > null :: l -> Bool > > empty :: l > > ... > > (But I don't like functional dependencies, because they confuse me, and > hope that associated types end up making it into Haskell'...) > -- > David Roundy > http://www.darcs.net > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From wnoise at ofb.net Wed Jan 10 04:54:57 2007 From: wnoise at ofb.net (Aaron Denney) Date: Wed Jan 10 04:51:19 2007 Subject: Is there already a list class? References: <20070110015252.GA29286@gmx.de> <20070110015409.GA7589@abridgegame.org> <20070110023500.GB26604@abridgegame.org> Message-ID: On 2007-01-10, David Roundy wrote: > (But I don't like functional dependencies, because they confuse me, and > hope that associated types end up making it into Haskell'...) Huh. I don't understand associated types, and functional dependencies seem fairly transparent, if perhaps low-level to me. -- Aaron Denney -><- From marco-oweber at gmx.de Wed Jan 10 06:19:08 2007 From: marco-oweber at gmx.de (Marc Weber) Date: Wed Jan 10 05:15:12 2007 Subject: Is there already a list class? - support for specialized lists? In-Reply-To: <20070110023500.GB26604@abridgegame.org> References: <20070110015252.GA29286@gmx.de> <20070110015409.GA7589@abridgegame.org> <20070110023500.GB26604@abridgegame.org> Message-ID: <20070110111908.GE29286@gmx.de> I think we should rewrite ByteString and call it WordString.. eg data WordString word = ... type ByteString = WordString Word8 Than the problem would be gone and we would also gain an ByteString implementation for Unicode, right? *smile* But I don't know ByteString that well by now so I might be totally wrong.. Marc From Malcolm.Wallace at cs.york.ac.uk Wed Jan 10 05:15:55 2007 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Wed Jan 10 05:16:24 2007 Subject: haddock suggestion -- %{FILE} In-Reply-To: References: <1168335932.19455.230.camel@localhost> <20070109174322.0a9702b5.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <20070110101555.3d47cc25.Malcolm.Wallace@cs.york.ac.uk> "Conal Elliott" wrote: > I don't know what -optP-P or these other flags are. Do you know where > they're documented? -optP is a GHC flag, which says to pass the remainder of the string as an argument to the preprocessor. (The preprocessor itself can be specified with GHC's -pgmP flag.) The -P flag to the standard C preprocessor says to omit #line droppings. Regards, Malcolm From marco-oweber at gmx.de Wed Jan 10 06:59:49 2007 From: marco-oweber at gmx.de (Marc Weber) Date: Wed Jan 10 05:55:54 2007 Subject: ListClass simple implementation Message-ID: <20070110115949.GF29286@gmx.de> Those who want to contribute: I've startet a darcs repository here darcs get shp@mawercer.de:/home/shp/darcs/ListClass pwd: shp Very much is still missing. Strange: I'm getting this error: marc@localhost /tmp/ListClass $ darcs get shp@mawercer.de:darcs/ListClass darcs failed: (sftp) failed to fetch files. source directory: darcs/ListClass/_darcs/patches source files: 20070110115136-ce738-38caa6448a675897ce2f755ad2caa8f4b060f33d.gz 20070110115103-ce738-4248ec806c18d50ae001281d6ff37b41eafb2889.gz 20070110032620-ce738-7c4ae0f11d3a40b397b31fbea82975b69ea0938d.gz sftp output: Request for subsystem 'sftp' failed on channel 0 Couldn't read packet: Connection reset by peer But you should be able to use scp Greetings Marc From marco-oweber at gmx.de Wed Jan 10 07:54:09 2007 From: marco-oweber at gmx.de (Marc Weber) Date: Wed Jan 10 06:50:13 2007 Subject: ListClass simple implementation In-Reply-To: <20070110115949.GF29286@gmx.de> References: <20070110115949.GF29286@gmx.de> Message-ID: <20070110125409.GG29286@gmx.de> On Wed, Jan 10, 2007 at 12:59:49PM +0100, Marc Weber wrote: > > Those who want to contribute: I've startet a darcs repository here > darcs get shp@mawercer.de:/home/shp/darcs/ListClass > pwd: shp > > Very much is still missing. Thanks to Spencer Janssen I know that the Edison library contain the right interface. All which seems to be missing is an instance for the type [] itself ;) I should start studying this lib. Greetings Marc From bulat.ziganshin at gmail.com Wed Jan 10 07:27:40 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Jan 10 07:24:58 2007 Subject: Is there already a list class? In-Reply-To: <20070110023500.GB26604@abridgegame.org> References: <20070110015252.GA29286@gmx.de> <20070110015409.GA7589@abridgegame.org> <20070110023500.GB26604@abridgegame.org> Message-ID: <307830917.20070110152740@gmail.com> Hello David, Wednesday, January 10, 2007, 5:35:03 AM, you wrote: >> class List l e, l -> e where > (But I don't like functional dependencies, because they confuse me, and > hope that associated types end up making it into Haskell'...) well, it is pretty studied design space, you can look the chapter about fundeps in ghc 6.6 manual which describes various solutions for containers class problem generally, we need either FD (which is not a part of Haskell') or AT (which is supported only by GHC HEAD) about existing implementations: 1) Stringable class in fps-soc project. it is aimed to generalize interface of String and ButeString 2) numerous classes in Collections [2] and Edison [3] libraries [1] http://darcs.haskell.org/SoC/fps-soc [2] http://darcs.haskell.org/packages/collections [3] http://www.eecs.tufts.edu/~rdocki01/projects/edison-1.2rc4-source.tar.gz -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From robdockins at fastmail.fm Wed Jan 10 09:30:07 2007 From: robdockins at fastmail.fm (Robert Dockins) Date: Wed Jan 10 09:20:44 2007 Subject: Is there already a list class? In-Reply-To: <448AAAEE-E8BB-41AB-9E20-EB53FB939940@cse.unl.edu> References: <20070110015252.GA29286@gmx.de> <448AAAEE-E8BB-41AB-9E20-EB53FB939940@cse.unl.edu> Message-ID: On Jan 9, 2007, at 9:12 PM, Spencer Janssen wrote: > On Jan 9, 2007, at 7:52 PM, Marc Weber wrote: >> Hello. >> >> Is here the right place to request a list class? >> eg >> class List l e where >> (:) :: e -> l e -> l e >> head :: .. > > Note that this approach isn't quite flexible enough. Your example > forces the container type to have kind * -> *, and therefore can't > support certain specialized containers like ByteString. > > There is a class like this in the Edison library (http:// > www.eecs.tufts.edu/~rdocki01/edison.html), it is called Seq > (Haddocks: http://www.eecs.tufts.edu/~rdocki01/docs/edison/Data- > Edison-Seq.html). However, it suffers the same kind flexibility > issues as your List class. Other classes in Edison take a MPTC > +fundep approach and I'm not sure why Seq doesn't. Can you comment > on this, Rob? I consider this mostly a historical artifact. The Edison design dates back to about 1998, before fundeps were available in a Haskell implementation. The Set/Bag and Finite Map classes were designed with MPTC, but no fundeps. The sequence class was nicer because it was more elegant, and played nicer with type inference. In the course of time, Set/Bag and Finite Map classes got fundeps, and became a bit nicer. When I took over maintenance, the typeclass hierarchy was much as it is now. I am personally in favor of the idea of changing the sequence class to the MPTC+fundep approach, for largely the reasons you've mentioned. The downsides are twofold: 1) Functor, Monad, and MonadPlus could no longer be superclasses of Sequence and 2) its a pretty major API change. Despite the downsides, I've become convinced this is the right direction to go, and this change will almost certainly take place sometime in the not too distant future. I'm now finished with some work which was occupying most my attention for the last six months or so. I am also considering a more sweeping API reorganization, where the typeclasses become less monolithic (especially the sequence class), and the non-observable classes go away, but I'm still trying to figure out the most optimal way to restructure things, so this change won't happen for awhile. >> This might be used in Data.Set, Data.Map >> >> class StorableAsList l e t where >> fromList :: l e -> t >> toList :: t -> l e > > This is subsumed by other Edison functionality. > >> I'd like to help implementing/ writing it. >> >> Do you consider this beeing a useful enhancement? > > Oh yes, but let's avoid reinventing the wheel if at all possible. > > > Spencer Janssen Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG From robdockins at fastmail.fm Wed Jan 10 09:34:36 2007 From: robdockins at fastmail.fm (Robert Dockins) Date: Wed Jan 10 09:25:05 2007 Subject: ListClass simple implementation In-Reply-To: <20070110125409.GG29286@gmx.de> References: <20070110115949.GF29286@gmx.de> <20070110125409.GG29286@gmx.de> Message-ID: <9FD88024-E5E3-4552-B79F-7050A3884227@fastmail.fm> On Jan 10, 2007, at 7:54 AM, Marc Weber wrote: > On Wed, Jan 10, 2007 at 12:59:49PM +0100, Marc Weber wrote: >> >> Those who want to contribute: I've startet a darcs repository here >> darcs get shp@mawercer.de:/home/shp/darcs/ListClass >> pwd: shp >> >> Very much is still missing. > > Thanks to Spencer Janssen I know that the Edison library contain > the right > interface. > All which seems to be missing is an instance for the type [] itself ;) http://www.eecs.tufts.edu/~rdocki01/docs/edison/Data-Edison-Seq- ListSeq.html > I should start studying this lib. > > Greetings > Marc > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG From robdockins at fastmail.fm Wed Jan 10 09:38:25 2007 From: robdockins at fastmail.fm (Robert Dockins) Date: Wed Jan 10 09:28:54 2007 Subject: Is there already a list class? In-Reply-To: <307830917.20070110152740@gmail.com> References: <20070110015252.GA29286@gmx.de> <20070110015409.GA7589@abridgegame.org> <20070110023500.GB26604@abridgegame.org> <307830917.20070110152740@gmail.com> Message-ID: <3083834E-D413-432C-9BCE-5E3947B31B13@fastmail.fm> On Jan 10, 2007, at 7:27 AM, Bulat Ziganshin wrote: > Hello David, > > Wednesday, January 10, 2007, 5:35:03 AM, you wrote: > >>> class List l e, l -> e where > >> (But I don't like functional dependencies, because they confuse >> me, and >> hope that associated types end up making it into Haskell'...) > > well, it is pretty studied design space, you can look the chapter > about > fundeps in ghc 6.6 manual which describes various solutions for > containers > class problem > > generally, we need either FD (which is not a part of Haskell') or > AT (which > is supported only by GHC HEAD) > > > about existing implementations: > > 1) Stringable class in fps-soc project. it is aimed to generalize > interface of String and ButeString > > 2) numerous classes in Collections [2] and Edison [3] libraries > > > [1] http://darcs.haskell.org/SoC/fps-soc > [2] http://darcs.haskell.org/packages/collections > [3] http://www.eecs.tufts.edu/~rdocki01/projects/edison-1.2rc4- > source.tar.gz FYI, this is not the latest release of Edison. The latest release is available from: http://www.eecs.tufts.edu/~rdocki01/edison.html > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG From stefanor at cox.net Wed Jan 10 10:18:28 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Wed Jan 10 10:14:32 2007 Subject: Is there already a list class? - support for specialized lists? In-Reply-To: <20070110111908.GE29286@gmx.de> References: <20070110015252.GA29286@gmx.de> <20070110015409.GA7589@abridgegame.org> <20070110023500.GB26604@abridgegame.org> <20070110111908.GE29286@gmx.de> Message-ID: <20070110151828.GB2665@localhost.localdomain> On Wed, Jan 10, 2007 at 12:19:08PM +0100, Marc Weber wrote: > I think we should rewrite ByteString and call it WordString.. eg > > data WordString word = ... > type ByteString = WordString Word8 > > Than the problem would be gone and we would also gain an ByteString > implementation for Unicode, right? *smile* > > But I don't know ByteString that well by now so I might be totally > wrong.. WordString a is a good idea, it would be *much* more efficient then [a], *but* it would be nowhere near as efficient as ByteString. WordString Word8 would require 4 or 12 bytes per character - one for a pointer (because you can't unpack a type variable), and optionally 8 more for the Word8 heap object (4 for the tag word, 1 for the Word8#, and 3 for alignment). By contrast, ByteString requires 1 byte per character, and [Word8] requires 12 or 20. (And 64-bit platforms will make it 1/8/24...) Furthermore, as a selfish American, I use the US-ASCII subset of Unicode exclusively, and don't want my ten-gigabyte bytestrings to quadruple in size and sloth. I would much rather see a Data.ByteString.UTF8. From droundy at darcs.net Wed Jan 10 10:31:03 2007 From: droundy at darcs.net (David Roundy) Date: Wed Jan 10 10:27:03 2007 Subject: Is there already a list class? In-Reply-To: <307830917.20070110152740@gmail.com> References: <20070110015252.GA29286@gmx.de> <20070110015409.GA7589@abridgegame.org> <20070110023500.GB26604@abridgegame.org> <307830917.20070110152740@gmail.com> Message-ID: <20070110153103.GA26950@abridgegame.org> On Wed, Jan 10, 2007 at 03:27:40PM +0300, Bulat Ziganshin wrote: > Hello David, Hi Bulat, > Wednesday, January 10, 2007, 5:35:03 AM, you wrote: > > >> class List l e, l -> e where > > > (But I don't like functional dependencies, because they confuse me, and > > hope that associated types end up making it into Haskell'...) > > well, it is pretty studied design space, you can look the chapter about > fundeps in ghc 6.6 manual which describes various solutions for containers > class problem I understand the idea of fundeps, but not their limitations--and every time I've tried to actually use them (admittedly, always for something harder than this) those limitations have bitten me. And the answer always seems to be that the code is correct, but there are reasons (involving termination or decidability) that I don't understand, why the compiler can't accept my code. From what I've heard from Manuel, with AT (and indexed types in general) the restrictions are identical, but are far easier to explain to a naive programmer such as myself. > generally, we need either FD (which is not a part of Haskell') or AT (which > is supported only by GHC HEAD) Yes, and I'm rooting for AT. Since no two implementations support the *same* FD, the only issues are that AT is only supported by ghc HEAD rather than also being supported by a released ghc, and also that no existing code uses AT. But to me, the ease of understanding absolutely outweighs those issues, and it seems like a language feature that's easy for programmers to reason about should also be easier for implementors to get right. And I don't know if you're aware of this, but the current plans are for ghc to switch to implementing fundeps via a translation into AT, which apparently will significantly simplify ghc's code. Admittedly, this is partly just because the fundeps implementation predates system fc, and doesn't take advantage of it as AT does. -- David Roundy http://www.darcs.net From droundy at darcs.net Wed Jan 10 10:32:50 2007 From: droundy at darcs.net (David Roundy) Date: Wed Jan 10 10:28:50 2007 Subject: Is there already a list class? In-Reply-To: References: <20070110015252.GA29286@gmx.de> <20070110015409.GA7589@abridgegame.org> <20070110023500.GB26604@abridgegame.org> Message-ID: <20070110153250.GB26950@abridgegame.org> On Wed, Jan 10, 2007 at 09:54:57AM +0000, Aaron Denney wrote: > On 2007-01-10, David Roundy wrote: > > (But I don't like functional dependencies, because they confuse me, and > > hope that associated types end up making it into Haskell'...) > > Huh. I don't understand associated types, and functional dependencies > seem fairly transparent, if perhaps low-level to me. The trouble is that fundeps *seem* transparent, but they aren't (at least, according to implementors). ATs, once you have heard about them, actually are simple, I believe. It's the restrictions on fundeps to allow termination and decideability that make them confusing... -- David Roundy http://www.darcs.net From sjanssen at cse.unl.edu Wed Jan 10 10:56:29 2007 From: sjanssen at cse.unl.edu (Spencer Janssen) Date: Wed Jan 10 10:52:46 2007 Subject: Is there already a list class? In-Reply-To: <953e0d250701100125r7f68acei4281179f296c6407@mail.gmail.com> References: <20070110015252.GA29286@gmx.de> <20070110015409.GA7589@abridgegame.org> <20070110023500.GB26604@abridgegame.org> <953e0d250701100125r7f68acei4281179f296c6407@mail.gmail.com> Message-ID: On Jan 10, 2007, at 3:25 AM, Jean-Philippe Bernardy wrote: > I suggest you have a look a the classes for collections that I've been > working on. > It's an attempt at unifying all collection types in a single framework > of classes. > > darcs repository: > > http://darcs.haskell.org/packages/collections How does this library compare to Edison? Cheers, Spencer Janssen From jeanphilippe.bernardy at gmail.com Wed Jan 10 11:12:05 2007 From: jeanphilippe.bernardy at gmail.com (Jean-Philippe Bernardy) Date: Wed Jan 10 11:08:07 2007 Subject: Is there already a list class? In-Reply-To: References: <20070110015252.GA29286@gmx.de> <20070110015409.GA7589@abridgegame.org> <20070110023500.GB26604@abridgegame.org> <953e0d250701100125r7f68acei4281179f296c6407@mail.gmail.com> Message-ID: <953e0d250701100812o7d07cc82o12cf86747156c8bc@mail.gmail.com> On 1/10/07, Spencer Janssen wrote: > On Jan 10, 2007, at 3:25 AM, Jean-Philippe Bernardy wrote: > > I suggest you have a look a the classes for collections that I've been > > working on. > > It's an attempt at unifying all collection types in a single framework > > of classes. > > > > darcs repository: > > > > http://darcs.haskell.org/packages/collections > > How does this library compare to Edison? > The collections package is intended as an evolution from the collection types in the package rather than a radically different design. In other words, it's easier to move to the collection packages than to edison. Another advantage is that every type is in the same "hierarchy" of classes (no separate class for associative collections). It also makes heavy usage of MTPC+fundeps, I suspect in a way very close to what Robert plans to do for edison. On the other hand, there are more types in the edison library. Robert: if that is actually the direction where you want to move for edison, I'd suggest to merge the two packages. Here's the link to the wiki page: http://haskell.org/haskellwiki/Library/New_collections Cheers, JP. From robdockins at fastmail.fm Wed Jan 10 11:36:19 2007 From: robdockins at fastmail.fm (Robert Dockins) Date: Wed Jan 10 11:26:51 2007 Subject: Is there already a list class? In-Reply-To: <953e0d250701100812o7d07cc82o12cf86747156c8bc@mail.gmail.com> References: <20070110015252.GA29286@gmx.de> <20070110015409.GA7589@abridgegame.org> <20070110023500.GB26604@abridgegame.org> <953e0d250701100125r7f68acei4281179f296c6407@mail.gmail.com> <953e0d250701100812o7d07cc82o12cf86747156c8bc@mail.gmail.com> Message-ID: <93889D7F-5639-4F92-822A-57FFC0D3E162@fastmail.fm> On Jan 10, 2007, at 11:12 AM, Jean-Philippe Bernardy wrote: > On 1/10/07, Spencer Janssen wrote: >> On Jan 10, 2007, at 3:25 AM, Jean-Philippe Bernardy wrote: >> > I suggest you have a look a the classes for collections that >> I've been >> > working on. >> > It's an attempt at unifying all collection types in a single >> framework >> > of classes. >> > >> > darcs repository: >> > >> > http://darcs.haskell.org/packages/collections >> >> How does this library compare to Edison? >> > > The collections package is intended as an evolution from the > collection types in the package rather than a radically different > design. In other words, it's easier to move to the collection packages > than to edison. Another advantage is that every type is in the same > "hierarchy" of classes (no separate class for associative > collections). It also makes heavy usage of MTPC+fundeps, I suspect in > a way very close to what Robert plans to do for edison. On the other > hand, there are more types in the edison library. > > Robert: if that is actually the direction where you want to move for > edison, I'd suggest to merge the two packages. Something like this might be feasible for the medium/long-term reorg I have in mind; however, like I said, I'm still trying to work out exactly what I'm aiming for. I have this thought that there should be some principled way to organize these classes based on an underlying mathematical model, but it hasn't quite crystalized in my head yet. > Here's the link to the wiki page: > http://haskell.org/haskellwiki/Library/New_collections > > Cheers, > JP. Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG From conal at conal.net Wed Jan 10 12:18:54 2007 From: conal at conal.net (Conal Elliott) Date: Wed Jan 10 12:14:57 2007 Subject: WikiHaddock In-Reply-To: <1168419095.19455.327.camel@localhost> References: <1168419095.19455.327.camel@localhost> Message-ID: I wonder how we could get the full expressiveness of Mediawiki (MW) markup out the back end, when haddock parses the input according to a less expressive markup language. Hm. Maybe just let it pass lots of markup through without realizing that it's markup. Then a MW back end would unparse a few things (italics, hyperlinks) back into markup. Of course, MW markup differs from Haddock markup, so we'd probably want to turn off some of Haddock's parsing (italics, at least). I don't see how to do that in a non-intrusive way. Perhaps Haddock could be refactored and exposed as a library, to give it some more flexibility. Some refactoring is intended anyway, to sync up with ghc language changes. In the process, its core functionality could be extracted as a library and hooked up to various front-ends as well as back-ends and maybe other processing as well. Cheers, - Conal On 1/10/07, Duncan Coutts wrote: > > On Tue, 2007-01-09 at 21:58 -0800, Conal Elliott wrote: > > Suppose Haddock's documentation language ("-- | ...") were an extended > > form of a common wiki markup language, and specifically Wikimedia's, > > because the Haskell wiki uses it. Instead of converting to HTML, > > Haddock could then pass through most markup unchanged and make wiki > > links out of its current link markup (modules & entities). > > Haddock is designed to be able to produce various different output > formats. It'd be perfectly reasonable to add a wkik markup backend. > There's nothing that special about the html backend, it's just the most > mature and most used. > > Duncan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20070110/b863e29b/attachment.htm From iavor.diatchki at gmail.com Wed Jan 10 13:18:47 2007 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed Jan 10 13:14:50 2007 Subject: WikiHaddock In-Reply-To: References: <1168419095.19455.327.camel@localhost> Message-ID: <5ab17e790701101018t16849aa9u18d091b1d353f1a7@mail.gmail.com> Hi, I am quite strongly opposed to using MW markup in my Haskell files. The reasons is that it is not well thought-out, it is not well defined, and it looks ugly, especially when viewed with a monospaced font (all the quotes!). While the last one is clearly subjective, the others are based on an attempt to write a MW parser, which was not a pleasant experience. -Iavor On 1/10/07, Conal Elliott wrote: > I wonder how we could get the full expressiveness of Mediawiki (MW) markup > out the back end, when haddock parses the input according to a less > expressive markup language. Hm. Maybe just let it pass lots of markup > through without realizing that it's markup. Then a MW back end would > unparse a few things (italics, hyperlinks) back into markup. Of course, MW > markup differs from Haddock markup, so we'd probably want to turn off some > of Haddock's parsing (italics, at least). I don't see how to do that in a > non-intrusive way. > > Perhaps Haddock could be refactored and exposed as a library, to give it > some more flexibility. Some refactoring is intended anyway, to sync up with > ghc language changes. In the process, its core functionality could be > extracted as a library and hooked up to various front-ends as well as > back-ends and maybe other processing as well. > > Cheers, - Conal > > > On 1/10/07, Duncan Coutts wrote: > > On Tue, 2007-01-09 at 21:58 -0800, Conal Elliott wrote: > > > Suppose Haddock's documentation language ("-- | ...") were an extended > > > form of a common wiki markup language, and specifically Wikimedia's, > > > because the Haskell wiki uses it. Instead of converting to HTML, > > > Haddock could then pass through most markup unchanged and make wiki > > > links out of its current link markup (modules & entities). > > > > Haddock is designed to be able to produce various different output > > formats. It'd be perfectly reasonable to add a wkik markup backend. > > There's nothing that special about the html backend, it's just the most > > mature and most used. > > > > Duncan > > > > > > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > > From conal at conal.net Wed Jan 10 14:11:17 2007 From: conal at conal.net (Conal Elliott) Date: Wed Jan 10 14:07:19 2007 Subject: WikiHaddock In-Reply-To: <5ab17e790701101018t16849aa9u18d091b1d353f1a7@mail.gmail.com> References: <1168419095.19455.327.camel@localhost> <5ab17e790701101018t16849aa9u18d091b1d353f1a7@mail.gmail.com> Message-ID: Hi Iavor, Thanks for the response. I'm with you about avoiding ugly markup or ugly anything in my Haskell code. Even worse in other people's code I look at. So let's broaden the conversation. How can we get (a) richer formatting, linking, etc in our library documentation, on the order of what something like MW can do, and (b) better integration & consistency between library documentation (currently Haddock) and other community-powered documentation (currently Haskell wiki). Then there's also lhs2TeX, which has a strong overlap and non-overlap with Haddock & HsColour. Cheers, - Conal On 1/10/07, Iavor Diatchki wrote: > > Hi, > I am quite strongly opposed to using MW markup in my Haskell files. > The reasons is that it is not well thought-out, it is not well > defined, and it looks ugly, especially when viewed with a monospaced > font (all the quotes!). While the last one is clearly subjective, the > others are based on an attempt to write a MW parser, which was not a > pleasant experience. > -Iavor > > > On 1/10/07, Conal Elliott wrote: > > I wonder how we could get the full expressiveness of Mediawiki (MW) > markup > > out the back end, when haddock parses the input according to a less > > expressive markup language. Hm. Maybe just let it pass lots of markup > > through without realizing that it's markup. Then a MW back end would > > unparse a few things (italics, hyperlinks) back into markup. Of course, > MW > > markup differs from Haddock markup, so we'd probably want to turn off > some > > of Haddock's parsing (italics, at least). I don't see how to do that in > a > > non-intrusive way. > > > > Perhaps Haddock could be refactored and exposed as a library, to give it > > some more flexibility. Some refactoring is intended anyway, to sync up > with > > ghc language changes. In the process, its core functionality could be > > extracted as a library and hooked up to various front-ends as well as > > back-ends and maybe other processing as well. > > > > Cheers, - Conal > > > > > > On 1/10/07, Duncan Coutts wrote: > > > On Tue, 2007-01-09 at 21:58 -0800, Conal Elliott wrote: > > > > Suppose Haddock's documentation language ("-- | ...") were an > extended > > > > form of a common wiki markup language, and specifically Wikimedia's, > > > > because the Haskell wiki uses it. Instead of converting to HTML, > > > > Haddock could then pass through most markup unchanged and make wiki > > > > links out of its current link markup (modules & entities). > > > > > > Haddock is designed to be able to produce various different output > > > formats. It'd be perfectly reasonable to add a wkik markup backend. > > > There's nothing that special about the html backend, it's just the > most > > > mature and most used. > > > > > > Duncan > > > > > > > > > > > > _______________________________________________ > > 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/20070110/6111b591/attachment.htm From simonpj at microsoft.com Thu Jan 11 03:20:59 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Jan 11 03:17:05 2007 Subject: FW: HDirect and GHC-6.6 Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From bulat.ziganshin at gmail.com Wed Jan 10 07:31:27 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Jan 11 07:19:29 2007 Subject: Is there already a list class? - support for specialized lists? In-Reply-To: <20070110111908.GE29286@gmx.de> References: <20070110015252.GA29286@gmx.de> <20070110015409.GA7589@abridgegame.org> <20070110023500.GB26604@abridgegame.org> <20070110111908.GE29286@gmx.de> Message-ID: <12010386527.20070110153127@gmail.com> Hello Marc, Wednesday, January 10, 2007, 2:19:08 PM, you wrote: > data WordString word = ... > type ByteString = WordString Word8 > Than the problem would be gone and we would also gain an ByteString > implementation for Unicode, right? *smile* > But I don't know ByteString that well by now so I might be totally > wrong.. yes, and it was proposed numerous times. but other parameter-less collection implementations can still exist btw, i've attached my own demo of such class together with example of generic foldr i also have proposed to extend syntax of (:), [] (including pattern matching) in Haskell' to use this class operations instead of be bound to lazy lists -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: ListLike.hs Type: application/octet-stream Size: 1361 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20070110/48574ae6/ListLike.obj From benjamin.franksen at bessy.de Thu Jan 11 19:09:27 2007 From: benjamin.franksen at bessy.de (Benjamin Franksen) Date: Thu Jan 11 19:05:44 2007 Subject: Multiple .cabal Files References: <1168303891.19455.220.camel@localhost> <1168341934.19455.248.camel@localhost> Message-ID: Duncan Coutts wrote: > On Tue, 2007-01-09 at 10:35 +0000, Jeremy O'Donoghue wrote: >> Oddly, I was about to ask almost exactly the same question. >> >> The supplementary is: >> >> I'm trying to convert wxHaskell to use a cabal based build system. > > I have similar issues in trying to convert Gtk2Hs to use Cabal. > > Basically Cabal doesn't yet have any coherent story for larger projects > like Gtk2Hs, wxHaskell, GHC etc that are made up of many components and > where some bits are needed to generate others. This is the sort of problems that make has been written for. Why re-invent this special wheel? Make tracks /any/ sort of dependency, and it is very good at that, you just need to give it all the necessary information i.e. write the appropriate rules. I think a large part of the (generic) rules needed for Haskell projects (including the large ones) could be written once and for all and thus shared among projects. It is of course necessary that these rules are completely configurable. Cabal could automatically generate make-variable definitions from the .cabal file to be included together with the generic rules; you could do this even for multiple sub-projects (which nevertheless might share some sources and depend on one another), using gnu-make's so called 'static pattern rules' (which are formulated generically but apply only to a given list of targets). This would mean that cabal becomes a generator for makefiles (or rather: make include files). The project author will write the top-level makefile which includes generic rules and cabal-generated variable definitions; for simple projects it wouldn't be necessary to add anything; complex projects could define extra rules (e.g. for special pre- or post-processing, for compiling in code in foreign languages, or for tracking dependencies on things external to the project). Well, that's how I would do this, anyway. Cheers Ben From shelarcy at gmail.com Fri Jan 12 01:49:23 2007 From: shelarcy at gmail.com (shelarcy) Date: Fri Jan 12 01:45:31 2007 Subject: HDirect and GHC-6.6 In-Reply-To: <45A65D97.6020205@galois.com> References: <20070110212440.77872.qmail@web27703.mail.ukl.yahoo.com> <45A65D97.6020205@galois.com> Message-ID: Hi Sigbjorn, Is there any plan to transition from CVS to darcs? HDirect is removed from darcs'ing fptools, and left cvs long ago. Because HDirect is not active. http://www.haskell.org/pipermail/cvs-ghc/2005-October/026817.html But HDirect is updated sometime. (We can see HDirect moves 'comlib' into a hierarchic setting, System.Win32.Com.* two month ago.) And Visual Haskell project changes comlib. http://www.haskell.org/pipermail/haskell/2006-September/018445.html http://www.haskell.org/pipermail/haskell-cafe/2006-September/018037.html Unfortunately these changes are independent. It forks comlib now. So I want to know what is common change both repository and what is useful change both version, easily. I think darcs'ing HDirect and two comlib branch realise it. And that helps to revive Visual Haskell's HDirect that can generate it's comlib source code. Best Regards, On Fri, 12 Jan 2007 00:53:59 +0900, Sigbjorn Finne wrote: > you may want to check out the CVS version of HDirect, which > does have a version of the compiler which is reasonably up-to-date > wrt GHC + Cabalized versions of both the 'comlib' and 'hdirect' > libraries. > > foo$ export CVSROOT=:pserver:anoncvs@cvs.haskell.org:/cvs > foo$ cvs login > (Logging in to anoncvs@cvs.haskell.org) > CVS password: cvs > foo$ cvs co fptools/hdirect > > (Derived from CVS setup instructions at http://cvs.haskell.org/ ) > > I apologize for not having the time to work on or support that code. -- shelarcy http://page.freett.com/shelarcy/ From kr.angelov at gmail.com Fri Jan 12 04:40:40 2007 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Fri Jan 12 04:36:41 2007 Subject: HDirect and GHC-6.6 In-Reply-To: References: <20070110212440.77872.qmail@web27703.mail.ukl.yahoo.com> <45A65D97.6020205@galois.com> Message-ID: Some time ago I even started to design my own comlib. It is quite different from HDirect's comlib but is more closer in spirit to Haskell's FFI lib. It isn't completed yet but if someone is interested in I would upload it in darcs next week. It is living in Foreign.COM namespace. Cheers, Krasimir On 1/12/07, shelarcy wrote: > Hi Sigbjorn, > > Is there any plan to transition from CVS to darcs? > > HDirect is removed from darcs'ing fptools, and left cvs long ago. > Because HDirect is not active. > > http://www.haskell.org/pipermail/cvs-ghc/2005-October/026817.html > > But HDirect is updated sometime. > (We can see HDirect moves 'comlib' into a hierarchic setting, > System.Win32.Com.* two month ago.) > > And Visual Haskell project changes comlib. > http://www.haskell.org/pipermail/haskell/2006-September/018445.html > http://www.haskell.org/pipermail/haskell-cafe/2006-September/018037.html > > Unfortunately these changes are independent. It forks comlib now. > So I want to know what is common change both repository and what > is useful change both version, easily. > > I think darcs'ing HDirect and two comlib branch realise it. And > that helps to revive Visual Haskell's HDirect that can generate > it's comlib source code. > > > Best Regards, > > > On Fri, 12 Jan 2007 00:53:59 +0900, Sigbjorn Finne wrote: > > you may want to check out the CVS version of HDirect, which > > does have a version of the compiler which is reasonably up-to-date > > wrt GHC + Cabalized versions of both the 'comlib' and 'hdirect' > > libraries. > > > > foo$ export CVSROOT=:pserver:anoncvs@cvs.haskell.org:/cvs > > foo$ cvs login > > (Logging in to anoncvs@cvs.haskell.org) > > CVS password: cvs > > foo$ cvs co fptools/hdirect > > > > (Derived from CVS setup instructions at http://cvs.haskell.org/ ) > > > > I apologize for not having the time to work on or support that code. > > -- > shelarcy > http://page.freett.com/shelarcy/ > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From marco-oweber at gmx.de Fri Jan 12 22:26:02 2007 From: marco-oweber at gmx.de (Marc Weber) Date: Fri Jan 12 22:26:03 2007 Subject: parsing commandline arguments using parsec Message-ID: <20080113043001.GA30553@gmx.de> Hello. I've rewritten the source position handing of parsec so that you can now use different position markers such as commandline arguments. You can find it with a demo application here: (Still very untested) http://www.mawercer.de/marcweber/haskell/fparsec/ Do you think this would be useful merging back (after fixing some small bugs like missing spaces in error message and adding some more documentation) ? Example application: ---------------------------------------------------- module Main where import Data.List import Text.ParserCombinators.Parsec.Prim import Text.ParserCombinators.Parsec.Combinator import Text.ParserCombinators.Parsec.Token import Text.ParserCombinators.Parsec.Char import Text.ParserCombinators.Parsec.Argument usage = unlines [ "cat (- means stdin/out)" , "tac (- means stdin/out)" , "calc 3 + 7 \\* 8 ... <- shell escape" ] cat :: ( String -> String ) -> String -> ArgParser () (IO ()) cat f s = do expectToken s input <- inputFile output <- outputFile return $ input >>= output . f calc :: ArgParser () (IO ()) calc = expectToken "calc" >> sum >>= return . print where sum = fmap (foldr1 (+)) (sepBy product (expectToken "+") ) product =fmap (foldr1 (*)) (sepBy value (expectToken "*")) value = intArg parser = choice [ cat id "cat" -- cat , cat (unlines . map reverse . lines) "tac" -- cat but reverse lines , calc -- simple calculator, only knows how to do + and * operations ] main = do action <- handleArgs parser () usage action ---------------------------------------------------- Marc Weber From dominic.steinitz at blueyonder.co.uk Sat Jan 13 05:07:46 2007 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Sat Jan 13 03:17:13 2007 Subject: Crypto Package Proposal Message-ID: <200701131007.46362.dominic.steinitz@blueyonder.co.uk> At Hac07, we discussed splitting up the crypto package to get rid of the dependency on NewBinary and so that you didn't have to have the whole of ASN.1 support if you just wanted to use md5 or base64. I've put the full proposal here (http://www.haskell.org/haskellwiki/Crypto_Library_Proposal) for people to comment on. Dominic. From conal at conal.net Sat Jan 13 15:09:39 2007 From: conal at conal.net (Conal Elliott) Date: Sat Jan 13 15:05:47 2007 Subject: Library dilemma / Cofunctor class Message-ID: I have a dilemma about library building that I'm expect comes up for other people as well. I'm working on a library that includes a Cofunctor instance. I'd love to import whatever standard module has the Cofunctor class, and maybe use some Cofunctor combinators. But, alas, I haven't found such a thing, and I'm wondering what to do. If I keep my Cofunctor class in my own library, the generality does no good to me or anyone else. I certainly wouldn't expect someone to install my library just to get Cofunctor. Just as I wouldn't want a dependency on some other mostly-irrelevant library just to get Cofunctor. Another option is for me to make a tiny Cofunctor package with just a single class declaration, and make my library dependent on it. I guess that's the cleanest way and is what I'm leaning toward. And maybe it could grow into a more useful Cofunctor library with the addition of functions on generic Cofunctor types. Does anyone have useful functionality to go into a Cofunctor module (beyond the class declaration)? Comments, advice, brainstorming most welcome. Cheers, - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20070113/a8ef07e8/attachment.htm From ajb at spamcop.net Sat Jan 13 19:57:50 2007 From: ajb at spamcop.net (ajb@spamcop.net) Date: Sat Jan 13 19:53:42 2007 Subject: Library dilemma / Cofunctor class In-Reply-To: References: Message-ID: <20070113195750.khw6fogk0kcokkok@webmail.spamcop.net> G'day all. Quoting Conal Elliott : > I'm working on a library that includes a Cofunctor instance. I'd love to > import whatever standard module has the Cofunctor class, and maybe use some > Cofunctor combinators. But, alas, I haven't found such a thing, and I'm > wondering what to do. I'd say that the "right" thing to do is first, claim a space in the module namespace (presumably Control.Cofunctor) and then, release the world's second-smallest Cabalised library (after hnop). I am mildly curious as to how you managed to come up with a use for covariant functors, though. Cheers, Andrew Bromage From conal at conal.net Sat Jan 13 20:59:29 2007 From: conal at conal.net (Conal Elliott) Date: Sat Jan 13 20:55:22 2007 Subject: Library dilemma / Cofunctor class In-Reply-To: <20070113195750.khw6fogk0kcokkok@webmail.spamcop.net> References: <20070113195750.khw6fogk0kcokkok@webmail.spamcop.net> Message-ID: Thanks, Andrew. I'd enjoy hearing more input on the location. I'm inclining to Data.Cofunctor rather than Control.Cofunctor. I doubt there's really a clearly appropriate place for this or most type classes to go. A beauty of type classes is that they generalize over uses. For instance, considering [] and IO (for starters) I don't know where I'd put Functor. So I offer rather bold statement that taxonomy (including namespace hierarchy) and type classes are in conflict with each other, About Cofunctor, my library includes a notion of "composable interfaces". These interfaces are consumers of values rather than producers of them, hence Cofunctor. Cheers, - Conal On 1/13/07, ajb@spamcop.net wrote: > > G'day all. > > Quoting Conal Elliott : > > >