Re: [Haskell-cafe] Re: The instability of Haskell libraries
On Tue, 27 Apr 2010, Brandon S. Allbery KF8NH wrote: I despair that a better Numeric hierarchy will never make it into Haskell. I thought the main reason for that was that nobody could agree on a better hierarchy that was actually usable. (Nobody wants to chain 10 typeclasses together to get work done.) I think that there is a way to do this so that everyone can be happy, if hassled. But GHC already has what we need to define our own numeric preludes. What we don't have is any numeric prelude at all. We just have a prelude prelude. I think it would *really* help if we could break the Prelude down into component packages, that can be separately imported, so that we don't have nonsense like this: http://hackage.haskell.org/packages/archive/list-extras/latest/doc/html/Prelude-Listless.html And such a thing could be done without breaking any code -- each compiler already has it's own non-standard breakdown anyway. Friendly, --Lane ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: The instability of Haskell libraries
Christopher Lane Hinson schrieb: On Tue, 27 Apr 2010, Brandon S. Allbery KF8NH wrote: I despair that a better Numeric hierarchy will never make it into Haskell. I thought the main reason for that was that nobody could agree on a better hierarchy that was actually usable. (Nobody wants to chain 10 typeclasses together to get work done.) I think that there is a way to do this so that everyone can be happy, if hassled. But GHC already has what we need to define our own numeric preludes. What we don't have is any numeric prelude at all. NumericPrelude does not count as numeric prelude? :-( http://hackage.haskell.org/package/numeric-prelude/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: The instability of Haskell libraries
I'm so sorry. I mean to say that there is no part of the standard prelude that is the numeric part. I was aware of the numeric-prelude package, which is good work and deserves recognition. Friendly, --Lane On Tue, 27 Apr 2010, Henning Thielemann wrote: Christopher Lane Hinson schrieb: On Tue, 27 Apr 2010, Brandon S. Allbery KF8NH wrote: I despair that a better Numeric hierarchy will never make it into Haskell. I thought the main reason for that was that nobody could agree on a better hierarchy that was actually usable. (Nobody wants to chain 10 typeclasses together to get work done.) I think that there is a way to do this so that everyone can be happy, if hassled. But GHC already has what we need to define our own numeric preludes. What we don't have is any numeric prelude at all. NumericPrelude does not count as numeric prelude? :-( http://hackage.haskell.org/package/numeric-prelude/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: The instability of Haskell libraries
On 2010-04-24, John Goerzen jgoer...@complete.org wrote: It is a funny thing, because our fundamental libraries *have* had time to settle down, in a sense. In another sense, I must say that the innovations we have seen recently have been sorely needed and are unquestionably a good thing. Overall, agreed. It still makes it a pain to write to the current standard, because it is moving. Unicode support in IO, This was just a bugfix in GHC, made more painful by people writing code dependent on the old behaviour. I guess this is the price of failing to avoid success, to borrow Simon's phrase. And again, not entirely bad. I despair that a better Numeric hierarchy will never make it into Haskell. -- Aaron Denney -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: The instability of Haskell libraries
On 27 April 2010 14:55, Aaron Denney wno...@ofb.net wrote: I despair that a better Numeric hierarchy will never make it into Haskell. I think the reason it hasn't is because I for one still haven't seen a fully implemented such hierarchy that's worth using. Then again, most of my numerical calculations are very basic; yay for combinatorics! :p -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: The instability of Haskell libraries
On Apr 27, 2010, at 00:55 , Aaron Denney wrote: I despair that a better Numeric hierarchy will never make it into Haskell. I thought the main reason for that was that nobody could agree on a better hierarchy that was actually usable. (Nobody wants to chain 10 typeclasses together to get work done.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: The instability of Haskell libraries
John Goerzen jgoer...@complete.org writes: It is somewhat of a surprise to me that I'm making this post, given that there was a day when I thought Haskell was moving too slow ;-) My problem here is that it has become rather difficult to write software in Haskell that will still work with newer compiler and library versions in future years. I have the same problem, except that I work so slowly that things have changed before I finish anything! Here is a prime example. (Name hidden because my point here isn't to single out one person.) This is a patch to old-locale: Wed Sep 24 14:37:55 CDT 2008 xx...@x. * Adding 'T' to conform better to standard This is based on information found at http://en.wikipedia.org/wiki/ISO_8601#Combined_date_and_time_representations diff -rN -u old-old-locale/System/Locale.hs new-old-locale/System/Locale.hs --- old-old-locale/System/Locale.hs 2010-04-23 13:21:31.381619614 -0500 +++ new-old-locale/System/Locale.hs 2010-04-23 13:21:31.381619614 -0500 @@ -79,7 +79,7 @@ iso8601DateFormat mTimeFmt = %Y-%m-%d ++ case mTimeFmt of Nothing - - Just fmt - ' ' : fmt + Just fmt - 'T' : fmt A one-character change. Harmless? No. It entirely changes what the function does. Virtually any existing user of that function will be entirely broken. Of particular note, it caused significant breakage in the date/time handling functions in HDBC. Now, one might argue that the function was incorrectly specified to begin with. It certainly was, and I said so in wfmytn48x5@calligramme.charmers posted to the Libraries list back in 2007: According to http://www.w3.org/TR/NOTE-datetime (and other random sources), the iso format for date+time in one field is -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. Now, while that change would still have been incompatible, I think it would have hurt less. But the problem here is that no one noticed my message, and then someone else must have seen the problem and made the different change without checking through old messages. If I remember correctly, I didn't report it as a bug because (a) I had some problem accessing trac at the time and anyway 2007-10-20 07:22:20Z is acceptable as a two field format, so it was a feature request (make it possible to output the correct single field format). But no discussion ensued. My own, related, gripe about Haskell libraries is that they seem very patchy; not adhering very well to relevant standards and not using Haskell's types enough. For your cited example, there is an applicable standard, so it should have been written to adhere to it and properly typed formats are rather awkward to do, so that can be forgiven. But in many other places Strings are used, with the effect that there's no typechecking at all. An example I came across yesterday: I wanted to read a file modification time and use that as the If-Modified-Since header in an HTTP request. System.getModificationTime returns one type of date, and I couldn't find how to format that correctly (There's old-time and new time -- which one do I choose for future compatibility? And how /do/ I convert that date to something I can format for http?), but more to the point, I shouldn't have to care: the IF-Modified-Since header in HTTP expects a date, and I got a date from the system, so it should be typed that way; converting it to the right format for HTTP is simple-HTTP's job. -- Jón Fairbairn jon.fairba...@cl.cam.ac.uk http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2009-01-31) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
