November 2006 - Libraries

proposal: add 'unsafeCoerce'
by Malcolm Wallace 02 Apr '07

02 Apr '07

Currently, all implementations provide either the 'unsafeCoerce' or 'unsafeCoerce#' functions, but they live in implementation-specific locations. This proposal is to adopt the Haskell'98-compatible name 'unsafeCoerce', and to add it to the standard base library package. Suggested location: Data.Function.Unsafe? http://hackage.haskell.org/trac/ghc/ticket/994 Regards, Malcolm

17 45

hs-plugins runtime error with GHC 6.6: index out of range
by Cyril Schmidt 14 Jan '07

14 Jan '07

After upgrading from GHC 6.4.2 to GHC 6.6 and rebuilding hs-plugins package, I noticed that hs-plugins does not work anymore. When I try to load a plugin, I get an "Index out of range" error. For example, when I compile the hs-plugins\testsuite\make\simple example and run the executable, the error message is a.out: Ix{Int}.index: Index (65536) out of range ((0,11)) Other tests give similar results; the values of the index and the range vary. Does anybody know what is wrong here? I use hs-plugins-1.0-rc0 and GHC 6.6 on Windows (hs-plugins worked fine with GHC 6.4.2). Cheers, Cyril

4 4

RE: Idea to allow people to comment on Haskell docs
by Simon Peyton-Jones 09 Jan '07

09 Jan '07

| I've had a go at patching Haddock to put a link on the page for each | module. It's controlled by an optional --wiki=URL flag. | | As an example, I used this with the (devel version of the) Gtk2Hs docs: | | http://haskell.org/gtk2hs/docs/devel/ | | For example this page: | | http://haskell.org/gtk2hs/docs/devel/Graphics-Rendering-Cairo-SVG.html It looks great! But I'd never have found the link if you hadn't pointed me at it. Rather than "Wiki" say "User comments". And I think the per-entry [User comment] link is essential. Typically people are going to be looking at a particular thing. For example, here http://haskell.org/gtk2hs/docs/devel/Graphics-Rendering-Cairo-SVG.html#v %3AsvgRenderFromString is where I'd look for the link for svgRenderFromString. Does MediaWiki support anchors in the middle of a page? That's essential here -- we want one Wiki page for one Haddock page. On a closely related matter, Benjamin Pierce told me how often he wished that there was a link from the Haddock documentation to the source code for a function. Especially for Prelude functions, he's dead right. So another really useful Haddock enhancement would be the ability to add links to the source code from the Haddock docs --- again on a per-function basis. Do you feel like adding that too? Where should the code live? I'd suggest snap-shoting it at the moment that the Haddock docs are generated, and putting the files with the Haddock docs. Simon

12 15

Proposal: Add parsing (and some other changes) to the time package
by Bjorn Bringert 21 Dec '06

21 Dec '06

I propose adding parsing to the time package. I also propose some minor other changes and bugfixes. I have implemented the changes that I consider reasonably clear-cut. The rest I will implement after community input. All already implemented changes are available from: http://www.cs.chalmers.se/~bringert/darcs/time/ All objections, comments, etc. are welcome. I especially would like feedback on the unimplemented enhancements, and any objections to the already implemented ones. I have created ticket #1007 to track this proposal: http:// hackage.haskell.org/trac/ghc/ticket/1007 Proposal: == Executive summary == (see below for more details). === Implemented enhancements === * Add time parsing to the time package, including Read instances. * Add fromMondayStartWeek and fromSundayStartWeek. * Add secondsToDiffTime and picosecondsToDiffTime. === Unimplemented enhancements === * Change %S to: the number of whole seconds. * Add %q: the number of picoseconds (including trailing zeroes). * Add %Q: decimal point and second decimals, without trailing zeros. * Add %f: The century part of the week date year. * Change %Z to produce the time zone offset if the time zone name is "". * Add Eq and Ord instances for ZonedTime? * Add Typeable and Data instances for all the time package types. === Fixed bugs === * formatTime "%c" did not include the time zone when applied to ZonedTime or UTCTime. * s/propleptic/proleptic/ in some Haddock comments. * formatTime documentation of range of %U and %W was wrong, should include 00. * The showWeekDate Haddock comment was missing the example. * The taiEpoch Haddock comment was missing the epoch time. === Unfixed bugs === * Haddock comments for toJulianYearAndDay and isJulianLeapYear talk about the Gregorian calendar. == Details == === Implemented enhancements === * Add time parsing to the time package. Rationale: The old System.Time has had a TODO "* add functions to parse strings to `CalendarTime' (some day...)" for a long time. The question about date parsing comes up once in a while on the mailing lists (e.g. http://comments.gmane.org/gmane.comp.lang.haskell.cafe/16438) * Add fromMondayStartWeek and fromSundayStartWeek to Data.Time.Calendar.OrdinalDate. Rationale: I can't find any duals of mondayStartWeek and sundayStartWeek. They are useful when implementing parsing for %W and %U. * Add secondsToDiffTime and picosecondsToDiffTime. Rationale: As has come up on haskell-cafe (http://comments.gmane.org/gmane.comp.lang.haskell.cafe/15653) it takes a while to figure out how to make DiffTime values. secondsToDiffTime is not that important since it is just another name for fromInteger, but I suspect that it would be used a lot. Using fromRational to create a DiffTime from a number of picoseconds is a bit of a hassle, so having a picosecondsToDiffTime would be useful. === Unimplemented enhancements === * formatTime: Change %S to: the number of whole seconds. * formatTime: Add %q: the number of picoseconds (including trailing zeroes). * formatTime: Add %Q: decimal point and second decimals, without trailing zeros. If the number of picoseconds is zero, nothing is produced (not even the decimal point). Rationale: Currently %S includes decimals if there are any. This is different from strftime, and there is no format specifier for just the integer part of the seconds. It would be nice to have such a specifier to implement many standard date formats (e.g. RFC 822). Also a specifier for second decimals would also help when using %s. Currently there is no reasonable way to get more than integer second precision with since-epoch timestamps. Thus the current %S would be equivalent to %S%Q under this proposal. * Add %f: The century part of the week date year. Rationale: There is a %g specifier for the last two digits of the week date year, but no specifier for the century. %C cannot be used, since the normal century and the week date century can differ: {{{ > formatTime defaultTimeLocale "%Y %G" (fromGregorian 2000 1 1) "2000 1999" }}} * Change %Z to produce the time zone offset if the time zone name is "". Rationale: Without this, if you format a ZonedTime which contains an unnamed timezone, %Z produces the empty string. This is invalid in many formats. It would be better to output the offset when there is no timezone name. * Add Eq and Ord instances for ZonedTime? Rationale: It's useful at least for the QuickCheck properties, but probably also elsewhere. There are lots of standard functions that want Eq and Ord. Problems: Should ZonedTimes be converted to UTC and compared, or should times in different timezones never be equal? I would argue for the latter, but I suspect that this problem is the reason why it never got included in the first place. Interestingly, there is a derived instance of Eq for TimeZone, which means that timezones with the same offset but different names are considered different. Following this logic, I think that ZonedTimes with different timezones should also be different. This should be noted in the documentation. * Add Typeable and Data instances for all the time package types. Rationale: It's useful and doesn't hurt anyone. === Fixed bugs === * formatTime "%c" does not include the time zone even when applied to ZonedTime or UTCTime, since "%c" is handled by the FormatTime LocalTime instance: {{{ > fmap (formatTime System.Locale.defaultTimeLocale "%c") getZonedTime "Sat Nov 11 19:12:45.395568 2006" > fmap (formatTime System.Locale.defaultTimeLocale "%c") getCurrentTime "Sat Nov 11 18:13:52.010944 2006" }}} * s/propleptic/proleptic/ in Data/Time/Calendar/JulianYearDay.hs and Data/Time/Calendar/OrdinalDate.hs * formatTime documentation of range of %U and %W was wrong, should include 00. * The showWeekDate haddock comment is: "show in ISO 8601 Week Date format as yyyy-Www-dd (e.g." * The taiEpoch haddock comment is just "The epoch of TAI, which is" === Unfixed bugs === * The haddock comments for toJulianYearAndDay and isJulianLeapYear in Data.Time.Calendar.JulianYearDay talk about the proleptic Gregorian calendar. This looks like a copy-and-paste problem. What is the calendar called? Proleptic Julian? /Björn Bringert

2 2

Library docs on Debian
by Yitzchak Gale 10 Dec '06

10 Dec '06

It used to be that the Haddock docs for all of the standard libraries were automatically installed on my Debian system together with GHC. I could browse them conveniently through a single consolidated index. But now that I have upgraded to GHC 6.6, many of them are gone. The packages that I most yearn for are mtl and network. What is the new Right Way to install these docs on a Debian system? Thanks, Yitz

2 2

Re: [GHC] #974: Add isLeft, isRight, fromLeft, fromRight, and splitEithers to Data.Either
by dons＠cse.unsw.edu.au 07 Dec '06

07 Dec '06

ndmitchell: > Hi > > >#974: Add isLeft, isRight, fromLeft, fromRight, and splitEithers to > >Data.Either > > Woohoo! Finally! > > >This proposal would add basic functionality to `Either` similar to that > > for `Maybe`. The `splitEithers` function of type `[Either a b] -> > > ([a],[b])` is unique; however, it seems to be a widely useful function. > > This (in my mind) is a parallel to unzip? unzipEithers to me gives a > much clearer picture of what is going on here. yeah, if its an unzip, then unzipEithers makes more sense. -- Don

10 30

base libraries
by Bulat Ziganshin 04 Dec '06

04 Dec '06

Hello libraries, current situation when Base lib includes everything, from 'const' to starship control, creates serious problems for upgrading to next GHC version. this problem arise because every GHC version arrives with its own, non-upgradable version of Base library and even minor API changes here results in total loss of ability to use new ghc version without #ifdef workarounds it seems strange, but even in this situation some developers prefer to include their modules in base lib instead of providing them as separate libs that can be easily upgraded using Cabal so that any library version can be used with any version of ghc after analyzing the situation, i concluded that source of problem, at least partially, is GHC HQ's policy of packaging libraries with GHC. The list of such libraries is *closed* and odd at first look. why, for example, it includes 2 of 4 regexp libs? at last end, we can learn that this is the list of libs required to build ghc itself! unfortunately, ghc building process don't require FilePath or ByteString support. this results in situation when authors of these libs, looking for a way to include their libs in every ghc distro, don't find other solution except for including them in Base lib. moreover, while Simon & Ian argued against inclusion of these very useful libs in base libs set, they don't have anything against inclusion of the same code in Base lib i'm all for docracy, but not in this case. having the experience of patching the program after each ghc upgrade, and having a bunch of conditionally compiled code in my libs, i can easily imagine ghc version hell that these new modules will provide for us so, i think, it is time to revise ghc libraries policy. i propose to split libs into the 3 "rings": core, base and other * core libs includes ghc version dependent libs. currently it's base, stm and th * base libs are libs, which is guaranteed to be shipped with *every* haskell distribution. on windows, it should be a part of monolithic installer while on unixes these libs may be a separate packages, but porters should ensure that they ported all these libs too this set should include only small and widely used libs, what is mainly datastructure processing ones. my current list includes regexps, bytestring, filepath, time, mtl, fgl, newbinary and so on * other libs are either too specific or too large, such as gui, database and xml ones. these may be included in some distros or installed separately these rules don't say anything about ghc self-building process. it will be great to maintain the list of libraries, required to do it, separately and while we are here - splitting of Base library should be very easy task. its ghc version specific part is in GHC.* modules. these modules should be moved into the new Core library. plus a few modules from Data.* or System.* hierarchy they imports. plus a few modules imported by Hugs/NHC Prelude. the rest of Base library should be pretty portable, at least between various GHC versions. and independent on this work, we can always look into moving pieces of Base into independent libs. as a rule of thumb, everything not used in Base lib may be moved outside of it. of course, these new libs should be included in base libs set in particular, my hottest hope is that ghc 6.6.1 will be shipped with fps 0.8 as separate library that will provide both backward compatibility with 6.6 and will allow to upgrade fps without recompiling ghc itself :D -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

15 77

Success Story: Cabal and Dlls
by Jason Dagit 01 Dec '06

01 Dec '06

Hello, I would like to report that I was able to use Cabal with Visual Haskell to build Dlls in windows. I have posted the details about this on the Haskell wiki (and started an extremely minimal Cabal page). If my content is in the wrong place, please feel free to move it (or edit it or whatever). http://www.haskell.org/haskellwiki/Cabal The trick was to take the final HSfoo-0.1.o file generated by the normal build process (and linked with the DllMain.c code) and tell ghc to build a dll. I use -package with each of the dependencies in the cabal file to link with the needed libraries. The resulting dll seems to be working. This approach is a bit hackish and while I've tried to implement as much of it as I can in a general way it requires you to hack your Setup.lhs file if you want to 1) build static 2) specify your exports 3) specify the name of the resulting dll. Also, it's only been tested on my setup which uses Visual Haskell so it may not be fit for general consumption. Finally, I just started really looking at Cabal yestarday so I may not have considered things which an experienced Cabal user would think about. Is it possible to get this functionality built directly into Cabal so that I tell it I want a DLL built from a library and it knows how to make it happen? Thanks, Jason

5 11

Typo fix for Test.HUnit
by Andriy Palamarchuk 30 Nov '06

30 Nov '06

Please let me know if this list is not correct place for this patch. Thanks, Andriy Palamarchuk ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com

2 1

Cabal preprocessing
by Ulf Norell 30 Nov '06

30 Nov '06

Hi. Currently when Cabal preprocesses a module the result ends up in the source directory. I would have expected it to end up in dist, since it's a generated file and not a source file. So, - are there strong reasons for putting preprocessed files in src? - if not, is there a simple (and robust) way to have them end up in dist? / Ulf

3 5