- Libraries - Haskell.org

haddock - links with fragments messed up
by apfelmus 18 Nov '07

18 Nov '07

Hello, the #-links to the references at the bottom of System.Random work fine in http://www.haskell.org/ghc/docs/latest/html/libraries/random-1.0.0.0/System… but not in http://hackage.haskell.org/packages/archive/random/1.0.0.0/doc/html/System-… Besides, I doubt that the links like System.Random#globalrng are intended to be rendered as such but rather as the title of the destination The global random number generator or something. Regards, apfelmus

2 1

Control.Category in base
by Bertram Felgenhauer 18 Nov '07

18 Nov '07

Hi, I played with ghc head today. I saw that its base library contains Control.Category, and Control.Arrow uses that. (I also saw the discussion about it on this mailing list. There weren't any serious objections; the discussion was far from focused though [*], and I found that the patch was applied rather abruptly. [1]) Anyway, here's what I found trying to compile HXT: 1) Control.Arrow doesn't export (>>>) and (<<<) anymore. 2) All user defined instances of Control.Arrow.Arrow break. The first one is easily fixed in the base library. The second one is more annoying. The required changes to HXT aren't that big - my patch inserts 30 lines and deletes 10 - but it'll be harder to make it compatible between several ghc versions. So all in all I'm rather unhappy that this patch went in, because it breaks existing code and personally I see little gain from it. Personally I'd like to see that patch reverted. However I realize that my complaint comes rather late, so if we decide to keep the patch we have to fix the first issue above to minimize breakage of other packages. regards, Bertram [*] a lot of mails in the thread went off tangents, extending the proposal to refining the class hierarchy of arrows. For reference, the thread starts at http://www.haskell.org/pipermail/libraries/2007-October/008291.html [1] http://www.haskell.org/pipermail/libraries/2007-October/008496.html

2 2

META-PROPOSAL: Documentation should be required to say when exports were introduced
by Ian Lynagh 17 Nov '07

17 Nov '07

Hi all, This is trac #1903: http://hackage.haskell.org/trac/ghc/ticket/1903 One of the nice things about, for example, PHP is that if you look at the documentation for one of its functions, e.g. http://www.php.net/manual/en/function.file-get-contents.php it tells you that file_get_contents is available in PHP >= 4.3.0. I propose that all exports in Haskell libraries should be required to have such a thing in their haddock documentation. For the current code we could either give the current versions as the date of introduction, or do some digging and put precise data in. Initial deadline: 1 December 2007. Thanks Ian

4 6

Adding a DSEL library to the hierarchy
by Alfonso Acosta 15 Nov '07

15 Nov '07

Hi, I'm expecting to publicly release the library of a Haskell-embedded Domain Specific Language, ForSyDe [1], in a few weeks time. However, I'm not still sure of what would be the most appropriate place in the hierarchy where to "plug" the library. To provide a little background, ForSyDe is aimed at modelling systems, and its implementation shares many concepts with Lava [2], the successful Haskell-embedded HDL. So the my question could be rephrased as "If you had to adapt the Lava library to the namespace extension, where would you put it?" My options are: 1) Use Language.ForSyDe But I don't know if embedded-languages really fit here since they don't explicitly "operate on source code" for the end-user (i.e. they don't transform or make computations over the representation of a language but rather provide the language itself) 2) Use the Org root name. However, we don't still have a domain, don't really think we'll have it any time soon, and besides, although the "Org" root name is proposed in the namespace extension, it doesn't really seem to be used in practice (tell me if I'm wrong). 3) Use our own root name: "ForSyDe". That's how it's currently implemented, but I guess that one of the purposes of having a namespace extension was precisely to avoid people adding their own root names. I would really appreciate any advice regarding this matter. Thanks in advance, Alfonso Acosta [1] http://www.imit.kth.se/info/FOFU/ForSyDe/ [2] http://www.cs.chalmers.se/~koen/Lava/

10 12

-- Cabal-1.2 and Haddock behaviour
by Andrea Rossato 11 Nov '07

11 Nov '07

Hi, I don't know whether this is going to be a question of just a way to express my deep frustration: I'm trying to maintain a Haskell tool chain for the Slackware GNU/Linux distribution and I'm now trying to update it to ghc-6.8.1. Packaging a Haskell library/application for a Linux distribution usually means writing a script. For Slackware we use SlackBuilds, shell scripts that perform all the needed steps for compiling and installing a package with all the needed documentation. I'm not going to stress the importance of software documentation. Now, as far as I understand, in the transition from Cabal-1.1 to Cabal-1.2, for which I want to express all my gratitude to the Cabal team since it seems to me a huge step forward in the right direction, a small and undocumented change happened: documentation used to be installed in "$PREFIX/share/packagename-version/doc/html" now, instead, it is installed in "$PREFIX/share/doc/packagename-version/html" Almost the same, you may say. Probably someone thought it was cooler this way. Maybe someone else, in the future, may think differently and change it once again. It doesn't matter if a shell script expects to find the documentation somewhere. It doesn't matter if tens, or thousands, or even millions of shell scripts will be broken. We are work in progress, after all. Nothing is required to be stable, and so on and so forth... I think I'm going to give up, actually. If every .x update requires all that effort on my side for packaging the software I'm compiling for myself in such a way that others may find useful too, well, I'm not that committed to sharing and all that kind of stuff. Or, at least, I prefer to use my limited time for having fun as everyone seems to do in the Haskell community: just write that wonderfully concise and nice code! Haskell is self documenting, if you know what it means, if you are an Haskeller. And I'm coming to think I am an haskeller, after all. Why should I care about the other Slackware users? I know Cabal quite well and it is very powerful to enable me to managing all my libraries and applications, and everything almost effortlessly... You did a great job! Thanks Andrea

2 3

Data.IntSet bug
by Ian Lynagh 11 Nov '07

11 Nov '07

Hi all, Can someone familiar with Data.IntSet please look into http://hackage.haskell.org/trac/ghc/ticket/1762 wrong result of isProperSubsetOf IntSet.isProperSubsetOf (IntSet.fromList [2,3]) (IntSet.fromList [1,2,3]) is evaluated to False, but should be True. Thanks Ian

2 1

Bug/infelicity with System.Locale.iso8601DateFormat
by Jon Fairbairn 09 Nov '07

09 Nov '07

According to <http://www.w3.org/TR/NOTE-datetime> (and other random sources), the iso format for date+time in one field is YYYY-MM-DDThh:mm:ssTZD (eg 1997-07-16T19:20:30+01:00), ie no spaces around the "T" but iso8601DateFormat outputs a space after the day if the timeFmt is not Nothing, so formatTime System.Locale.defaultTimeLocale (System.Locale.iso8601DateFormat (Just "T%H:%M:%SZ")) (UTCTime (fromGregorian 2007 10 20) 26540) yeilds "2007-10-20 T07:22:20Z". I reckon this is a bug, but at the very least it's not a good design. Please can we change Just fmt -> ' ' : fmt to Just fmt -> fmt ? if someone wants a space, they can put it in the string, but it's a pain to take it out when you want the one field format with a T there. -- Jón Fairbairn Jon.Fairbairn(a)cl.cam.ac.uk

1 0

Space handling with Parsec
by Anakreon Mendis 08 Nov '07

08 Nov '07

I hope this is the correct mailing list do address parsec related questions. There is a question about parsec which I hope you could help. According to the documentation space parser recognizes '\n' as a space character. I am implementing a Basic parser where newline is important. For example, now the parser accepts the expression: a = 1 + 2 as equivalent to "a= 1 + 2" when it shouldn't. If this was the only problem, it wouldn't be a big deal. However, in basic, a function call is not required to enclose the arguments with parenthesis. Thus, the expressions: myFunc anOtherFunc arg1, arg2 are valid. Since the newline is skipped, when the parser tries to match the optional arguments of myFunc, it will search them in the line below. The parser will consume characters and will fail. What I tried to do is: imported the Parsec module, hiding the `space`. Reimplemented the space parser as space = oneOf [' ', '\t'] The parser behaved the same. Afterwords, I implemented the whiteSpace parser as whiteSpace = skipMany space This didn't work either.

2 2

[Fwd: Re: readline]
by Simon Marlow 05 Nov '07

05 Nov '07

Forwarding on behalf of alpheccar <alpheccar(a)gmail.com>

1 0

System.FilePath.joinDrive problem
by Twan van Laarhoven 04 Nov '07

04 Nov '07

Hello all, The joinDrive function currently produces paths such as "C:File" when calling "C:" </> "File". This is apparently handled in a special case: > | otherwise = case a of > [a1,':'] | isLetter a1 -> a ++ b > _ -> a ++ [pathSeparator] ++ b This seems wrong, as far as I know "C:File" is not a valid path. What is the reason for this special case? In particular this problem results in cabal wanting to install packages to "E:Haskell" on my computer (unless I pass a --prefix flag). Twan

5 11