- Libraries - Haskell.org

haxml
by Don Stewart 17 Jun '08

17 Jun '08

The haxml version of hackage.haskell.org relied on the deprecated function 'ByteString.join' which has been replaced with 'ByteString.intercalate' since the last release. This means haxml doesn't build with bytestring 0.9.1.0, which some people might have updated to. Malcolm, what should we do ? I can reintroduce 'join' and leave it deprecated for another year, or is there a new haxml release on the horizon? A non-working haxml affects an awful lot of hackage. -- Don

3 5

Re: [Haskell-cafe] 1/0
by Henning Thielemann 17 Jun '08

17 Jun '08

On Mon, 16 Jun 2008, Dan Doel wrote: > On Monday 16 June 2008, Evan Laforge wrote: > >> (huge negative number) >> >> Ok, so integral types don't have that exceptional value. Shouldn't >> trying to convert NaN or Infinity to an Integral throw something? Is >> it a performance thing? I'd think if you're converting to Integer you >> don't really need hardware level performance anyway, so a couple of >> checks wouldn't kill anyone. > > This is a (known by some) bug of sorts in the various floating point -> > integral transformations (which ultimately boil down to decodeFloat or > something like that at some point). It apparently doesn't know about the > various exceptional values in the IEEE representation, so it just treats the > representation like any other value. Infinity and NaN look like various huge > numbers if you interpret them like any other value, so that's what you get > out of round/ceiling/floor/etc. > > It's not ideal, but I guess no one's bothered to fix it. Might be something to > bring up on the libraries mailing list. This could be combined with improving performance: http://hackage.haskell.org/trac/ghc/ticket/2281 http://hackage.haskell.org/trac/ghc/ticket/2271 http://hackage.haskell.org/trac/ghc/ticket/1434

1 0

HTTP(S) ?
by Johannes Waldmann 16 Jun '08

16 Jun '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 can the HTTP module handle https connections? would this then work with haxr: remote "https://foo.bar/cgi-bin/server.cgi" ... best regards, J.W. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIVgyHDqiTJ5Q4dm8RAv6NAKChUNuQWdW1Ej8YY3+/GeqR+b3TiACcCxha hIFujlBcmWGxiplXo519USo= =gO8x -----END PGP SIGNATURE-----

2 1

Maybe-summary was: Re: [Haskell-cafe] Re: [Haskell] ANN: random-access-list-0.1
by Isaac Dupree 13 Jun '08

13 Jun '08

Claus Reinke wrote: >> To summarize: Monad isn't the proper abstraction for failable/Maybe. >> Maybe is an algebraic data type that *exactly* represents the spirit >> of what you're trying to do: e.g. Conor McBride said: "Maybe is the >> most general abstraction. Requiring (>>=), or even (<*>) seems >> excessive. What we need is "any f with zero and return", so why not >> pick the canonical, initial, inductively defined such thing?" In this >> case the typeclass adds no generality to the function's behaviour >> (Maybe can be trivially converted to any other type, with a combinator >> even). And the confusion that results, when the function is almost >> always used at type Maybe anyway. If you want to read the whole >> discussion... if you haven't been subscribed to libraries(a)haskell.org >> , it's archived: >> http://thread.gmane.org/gmane.comp.lang.haskell.libraries/9082 > > Thanks for the summary. I had been wondering about this > change of mood, and I disagree with the suggestion that > Maybe Nothing is the right replacement for Monad fail. > Whether fail should be in Monad, or whether we really want MonadZero, > MonadPlus, MonadError, or something else entirely has been open for > discussion, but it is easily shown > that Maybe is not the most general abstraction - it loses information > wrt to (Either String), for instance: > > Prelude> let {f [] = fail "empty"; f [_] = fail "singleton"; f l = > return l } okay, I see, it's just that most partial functions in Data.* / container libraries don't really have multiple failure modes that need distinguishing. You could say, in a type/information-theoretic mindset, that even your "f [_]" above loses information because it doesn't vary based on the _ (and so it isn't reversible) (and this is very common and normal especially for error messages, but there's a large design space for places where they're needed, depending on whether a machine needs to understand the message, etc.) I think we didn't conclude much about e.g. parser-library return types, because we (thankfully) weren't trying to. -Isaac

2 1

darcs patch: Re: Readline readHistory & writeHistory API broken
by Judah Jacobson 12 Jun '08

12 Jun '08

On Wed, Jun 11, 2008 at 5:04 AM, Krasimir Angelov <kr.angelov(a)gmail.com> wrote: > Just fixing the comments is also fine for me. I personally use another > file name. > > On 6/11/08, Ian Lynagh <igloo(a)earth.li> wrote: >> On Sun, Jun 08, 2008 at 05:30:34PM +0200, Krasimir Angelov wrote: >> > >> > Note the comments "(if null, write ~/.history)"! This is supported in >> > the original C API but in Haskell the filepath cannot be null. In the >> > best case it can be empty string. Either the type signatures have to >> > be changed to accept (Maybe FilePath) or the comments have to be >> > changed because the Haskell binding currently doesn't support this >> > functionality. >> >> If writing to ~/.history is useful then Maybe FilePath makes sense to >> me, as ~/.history is a bit fiddly to work out yourself. >> >> However, it doesn't sound that useful to me, as then all applications >> would trample over each other. >> >> If you want to propose that it uses Maybe FilePath then you'll need to >> follow http://www.haskell.org/haskellwiki/Library_submissions; otherwise >> I'll just fix the comments. >> I agree that just fixing the comments is fine. Ian, it looks like the editline library also has this problem. Can you please apply the attached patch (or its equivalent)? Wed Jun 11 11:16:24 PDT 2008 Judah Jacobson <judah.jacobson(a)gmail.com> * Remove erroneous comment from readHistory and writeHistory. M ./System/Console/Editline/Readline.hsc -2 +2 Thanks, -Judah

2 2

installing non-haskell binaries with cabal
by Misha Aizatulin 12 Jun '08

12 Jun '08

hello, I would like to distribute a shell script as part of my haskell project. How can I tell cabal to install the script as an executable? Cheers, Misha

7 11

haddock: record types with partially exported fields
by Misha Aizatulin 12 Jun '08

12 Jun '08

hello, attached (M1) is an example of a situation, where haddock hides all fields of a record, just because one field is hidden. The result is that the other field is not shown in the documentation as well, even though it is exported. As an example for why hiding certain fields of a record might make sense, consider M2. There we export two functions for decomposing T: f and g, whereas f is a class function that can be used for other datatypes as well, and g is a function specific to T. The ugly fT function is hidden from the user. I'd wish myself a haddock output in which T would be shown in record style, but there would be a blank instead of fT or maybe something like "<hidden>". Cheers, Misha P.S. What's the right place to talk about haddock by the way?

5 9

Readline readHistory & writeHistory API broken
by Krasimir Angelov 11 Jun '08

11 Jun '08

The current readHistory and writeHistory bindings are defined as: -- |Read in a history file. Returns 'False' on failure -- (for example, if the file does not exist). readHistory :: FilePath -- ^ The file to read (if null, read ~\/.history) -> IO Bool readHistory fp = do ok <- withCString fp read_history return (ok==0) foreign import ccall unsafe read_history :: Ptr CChar -> IO CInt -- |Write out a history file. Returns 'False' if there was a problem writing the file. writeHistory :: FilePath -- ^ The file to write (if null, write ~\/.history) -> IO Bool writeHistory fp = do ok <- withCString fp write_history return (ok==0) foreign import ccall unsafe write_history :: Ptr CChar -> IO CInt Note the comments "(if null, write ~/.history)"! This is supported in the original C API but in Haskell the filepath cannot be null. In the best case it can be empty string. Either the type signatures have to be changed to accept (Maybe FilePath) or the comments have to be changed because the Haskell binding currently doesn't support this functionality. Comments? I hope that this will not start another endless discussion. Regards, Krasimir

2 2

Feature request: more transparency for Data.Graph.Inductive.NodeMap
by Misha Aizatulin 11 Jun '08

11 Jun '08

hello, would it be possible to add functions to NodeMap for inspecting the contents of the map? I would be particularly interested in a function like toList :: NodeMap a -> [LNode a] If I use a node map m to construct a graph g, then of course (labNodes g) would achieve the same as (toList m), but if I later transform the labels of the graph, say using nmap, then I cannot do it anymore - the connection between old label values and nodes is still a valuable piece of information, but I cannot access it. Cheers, Misha

4 5

Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries
by Krasimir Angelov 09 Jun '08

09 Jun '08

Ups! According to the library submission procedure this message should have been sent to libraries(a)haskell.org. I appologise for the multiple copies. ---------- Forwarded message ---------- From: Krasimir Angelov <kr.angelov(a)gmail.com> Date: Sat, May 31, 2008 at 10:42 AM Subject: Re: [Haskell-cafe] Data.Tree.Zipper in the standard libraries To: Haskell-cafe <haskell-cafe(a)haskell.org> Hi again, I was silent for some time but in this time I created QuickCheck tests for Data.Tree.Zipper which achieve 100% coverage with HPC. I also created a ticket for it: Ticket #2324 http://hackage.haskell.org/trac/ghc/ticket/2324 The attached file is the current implementation and it contains the version updated from Iavor Diatchki. It has the advantage that it also works with forests, not just with trees. Initially I thought that complete testsuite for such a simple module might be overkill but actually I found a bug :-) in the splitChildren function which is now fixed. The dead line for further considerations is one week. Regards, Krasimir On Sun, May 25, 2008 at 1:09 AM, Iavor Diatchki <iavor.diatchki(a)gmail.com> wrote: > Hello, > I think that the modified API (no state monad, and using Maybe) is > quite nice! I implemented a version of the the suggested API using a > slightly different data structure, which makes the code a bit simpler, > I think. I put the code in the Haskell wiki: > http://www.haskell.org/sitewiki/images/2/2d/RoseZipper.hs > I also added a couple of extra functions that seemed useful, and > renamed a few of the functions to be more consistent. > > As for how to distribute the code, it seems that Zipper should live in > the same place as Data.Tree. I think that Data.Tree is part of the > "containers" package, so it would make sense to add the Zipper there > as well. > > -Iavor > > > > On Sat, May 24, 2008 at 1:24 AM, Neil Mitchell <ndmitchell(a)gmail.com> wrote: >> Hi, >> >>> It doesn't use State monad anymore and it returns Maybe. This seems to >>> be the common preference, is it? Feel free to vote against. Should we >>> change Data.Map also? There is another proposal for changes in >>> findMin/findMax so it is better to make this two breaking changes >>> together rather than in a later release. >> >> The standard libraries proposal thingy is to go via the libraries >> list, create tickets etc. What reason is there to make this part of >> the base libraries, rather than a separate package on hackage? I can't >> see much reason to make Data.Tree part of the base libraries, other >> than the fact it already is, and it could easily get moved out at a >> future date. >> >> We've seen there is some advantage in leaving the implementation >> outside the base library, as its already changed several times in the >> past few days. >> >> Thnanks >> >> Neil >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >

16 44