February 2006 - Libraries

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

external core
by John Meacham 22 Mar '06

22 Mar '06

Now, the external core feature of ghc is great, but it is not utilized very much. The main reason I think is that there is a large barrier to entry in writing something that uses it since you need to parse/generate it. It would be nice if there were a standard library that came with ghc (or cabalized and portable even better) that could parse and pretty print external core. ideally, one could write a simple pass-through core processor that interacts with ghc in a single line and someone working on a new optimization need only worry about that. Also, it would make it very easy for jhc to generate and parse ghc core files (always an ulterior motive). I wanted to use jhcs front end to generate ghc core so I could get a true measure of the difference in just their back-end performance without taking into account ghc's superior high-level optimizations. In any case. I think all the code is out there in ghc and it just needs to be separated and cabalized. I know there was talk of creating a ghc internals library, but it would be nice if this code were portable and independent. John -- John Meacham - ⑆repetae.net⑆john⑈

3 4

RFC: Time Library 0.3
by Ashley Yakeley 15 Mar '06

15 Mar '06

Please take a look at my third draft of a replacement for the standard time library. http://semantic.org/TimeLib/ Take a look at the Haddock documentation: http://semantic.org/TimeLib/doc/html/ Download the source: http://semantic.org/TimeLib/TimeLib-0.3.tar.gz Or keep up-to-date: darcs get http://semantic.org/TimeLib/TimeLib/ It needs GHC 6.4.1. (I haven't tested with 6.4 or other compilers.) It consists of two separate Cabal packages, "fixed" and "time", which can be installed in the usual way. See the README file. This release should be close to being ready to become part of the libraries distributed with some future version of GHC. I'm interested in any remaining issues. Major changes since 0.2: * The code has been reorganised into two separate packages, "fixed", containing only Data.Fixed for fixed-point arithmetic, and "time", containing everything else. * The modules in "time" have been reorganised. The three "first level" modules, Data.Time.*, contain functionality that most ordinary users want. The "root" module, Data.Time simply re-exports these three. The "second level" modules, Data.Time.*.*, contain more specialised functionality. http://semantic.org/TimeLib/doc/html/ Some points (largely repeated from the 0.2 RFC): 1. There is no leap second table provided, though there is a type (LeapSecondTable) for such things. Any software compiled with a fixed table would soon become out of date. 2. There is no table of time-zones provided, since these also change. However, if there's a good way of getting this from the TZ database on the machine, I'll add that. It is actually possible to get the local time-zone for any given time, indeed one of the test programs finds your local summertime transitions. The Timezone type includes name, minutes of offset, and a "summertime" flag. 3. The TimeLocale type comes from the already existing System.Locale. 4. The "fixed" package includes Data.Fixed which provides a fixed-point arithmetic type (wrapper around Integer). It allows dealing with seconds as a single thing, rather than as an integer/picoseconds pair. It should probably be merged into base. 5. I don't have any text-parsing functionality for times. This is a fair amount of work, so it would be good to know sensible requirements. 6. Time as measured by the CPU since system startup remains in System.CPUTime, which TimeLib does not intend to replace. -- Ashley Yakeley, Seattle WA

5 8

Trie implementation
by Keith Wansbrough 11 Mar '06

11 Mar '06

Hi... I was writing some code yesterday to walk over a directory tree, and needed a Trie. Not seeing one around, I wrote a basic implementation of the functions I needed (attached below). Has anyone else done this? Should I polish it up and offer it for inclusion in Data? --KW 8-)

7 8

RFC: Collection Framework, reprise.
by Jean-Philippe Bernardy 04 Mar '06

04 Mar '06

Hello, I'm glad you see so many good point in my design. I must say however that the operator names are (c) Ross Paterson :) On 2/21/06, Robert Dockins <robdockins(a)fastmail.fm> wrote: > Well, I have to begin with the caveat that I am not a data structures > expert, and that the design of Edison is almost entirely due to Chris > Okasaki. That said, I can certainly share my opinion. In no > particular order: > -- Your use of two type parameters to model read-only or unobservable > collections is very interesting. I wonder, though, how useful it > actually is. I facilitates some interesting possibilities with > views, but I can't think of any compelling use cases. I sort of > dislike the fact that it can turn certain of the class methods > "useless", but maybe the idea just hasn't grown on me yet. The truth is, I hope this will become nicer when (if) we move to associated types. I need to play a bit more with Phrac to have a clearer idea though. > -- I like the idea of views generally, and I'm now trying to think if > there is a good way to work something like them into Edison. > -- The 'isSingleton' method seems unnecessary. Are singleton > collections interesting enough to supply a special test for them? This is based on Christan Maeder idea. We are planning to move to AVL trees for A. Hey, which do not provide a O(1) size function. A singleton test thus becomes valuable, and since costs next to nothing to add to the class I decided to to it. > -- Your 'lookup' method has a Monad context, which I assume is the > 'NotJustMaybe' pattern, but 'front' and 'back' return Maybe. You > should probably pick one style and stick to it. True. > -- Qualified infix functions look horrible. I know you say this > module should be imported unqualified, but with Prelude clashes > people qualify it anyway. I'd suggest you stick to regular prefix > functions for your class methods and define the infix functions as > the appropriate aliases. That way people importing qualified can > still use something reasonable looking. > -- In a related thread I've been discussing argument orders. I think > I've just about come to the decision that all the Edison API > functions will take the collection argument last, including the > troublesome 'rcons'. If you take my suggestion to remove infix > symbols from your classes, I suggest you also make your right cons > and index functions take the collection argument last. However, I'd > probably leave the symbols as is, so that, e.g., (|>) = (flip rcons). If i understand this correctly, you suggest that regular functions should have a prefix meaning, whereas operators should have infix meaning (also in the light of your answer to Ross). I remember some peope spoke against this when we tuned Data.Map (& friends) API some years ago. I guess the reason is that some functions cannot be assigned a clear enough operator (isSubsetOf, etc.) > -- In fact, I like your right and left insert symbols so much, I may > adopt them myself. > -- You claim that 'union' takes an unspecified element in the case of > duplicates, but you also claim it is commutative. You need to > specify in what sense you claim commutativity; your collection class > doesn't require an Eq or Ord instance, and the claim seems very > suspect if you mean up to identity. Similar with intersection. This has been written in a hurry, and I didn't mean anything very formal. We have re-hashed implied meanings of Eq and Ord quite a few times however, and the general idea is that we require Eq to mean equality, and similarly for Ord, otherwise all bets are off. This is better stated in a general comment rather than on the definition on union though. > -- Does 'adjust' affect all elements with the given key, or just a > single unspecified one? The class has the (implicit) assumption that a key cannot exist twice. The semantic could be generalized however. > -- 'Indexed' doesn't have any notion of bounds. That seems like a > pretty necessary concept. Humm, I see now that MapLike is a subclass > of Indexed. Perhaps then you should have 'DenseIndexed' or > 'ArrayLike' which has bounds related methods together with the > "denseness" property. It seems like the class you suggest to add would become a replacement for the Array class. > > Overall, I'd say the methods you have carved out seem to be the ones > that are most-used, with the notable exception of 'head' and 'tail' > for sequences. Rather, I intend to start with those. It seems easier to add than to remove. > If you are attempting to go for a fairly minimal set > of operations (that's more or less what I read your design goals as > saying), then the only method I'd consider adding is a strict fold. > People get irritated if they can't, e.g., sum the elements in a > collection without building a gajillion unnecessary closures. Every day I pray for a genius to come with the generic solution to eliminate unnecessary lazyness :) Thanks again for the helpful comments. JP.

11 17

darcs patch: Years have 365 days, not 30*365 (and 1 more)
by Ian Lynagh 27 Feb '06

27 Feb '06

(On second thoughts, this might be a more appropriate address to send this to). The libraries/base repo (and presumably the others too) is missing an _darcs/prefs/email giving the address to send patches to. Fri Feb 10 14:28:53 GMT 2006 Ian Lynagh <igloo(a)earth.li> * Years have 365 days, not 30*365 Fri Feb 10 14:46:38 GMT 2006 Ian Lynagh <igloo(a)earth.li> * Avoid overflow when normalising clock times Thanks Ian

3 3

Re: [Haskell] Long live Edison
by Jean-Philippe Bernardy 22 Feb '06

22 Feb '06

As you might know, I've been working on a class-based framework API to accomodate existing collection types, which I intend to be used in place of the concrete modules APIs. It can be found here: http://hackage.haskell.org/trac/ghc/wiki/CollectionClassFramework By all means, I'd be interested to have your feedback on my design. I don't mean that there can exist only one, but I guess we can benefit from each other's ideas. Cheers, JP. On 2/21/06, Malcolm Wallace <Malcolm.Wallace(a)cs.york.ac.uk> wrote: > Robert Dockins <robdockins(a)fastmail.fm> wrote: > > > On Feb 20, 2006, at 5:19 PM, ajb(a)spamcop.net wrote: > > > > > > Data.Set, Data.Map, Data.Hash and the various Array interfaces are > > > all inconsistent in subtle ways, so whatever you do, do not take > > > them as the ideal to which Edison should aspire. > > > > This is all true. The main advantage that the current Data.* APIs > > have is that people use them ;-) > > And AFAIK the only reason people use them is because they are widely > distributed, not because they are a perfect design. I certainly have > reservations about the Data.* APIs, such as the left bias and so on, > and personally preferred the older Data.FiniteMap API. > > Regards, > Malcolm > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell >

3 3

RFC: Collection framework.
by Jean-Philippe Bernardy 15 Feb '06

15 Feb '06

Hello libraries folk, Following popular demand, I've been working on a class-based collections framework that I would like to submit for review. The main goal is to have something usable right now, making use of generally available haskell extensions for maximum usability/portability ratio (or rather product). http://hackage.haskell.org/trac/ghc/wiki/CollectionClassFramework Cheers, JP.

4 3

[Haskell] ANN: FFI Imports Packaging Utility (pre-release)
by Dimitry Golubovsky 13 Feb '06

13 Feb '06

I am pleased to announce the pre-release of the FFI Imports Packaging Utility (ffipkg), a new member of the HSFFIG package. The `ffipkg' utility prepares a Haskell package containing FFI imports for building by accepting locations of C header and foreign library files as command line arguments and producing Haskell source files with FFI declarations, a Makefile, a Cabal package descriptor file, and a Setup.hs file suitable for running the Cabal package setup program. The utility acts as a "driver" running the C preprocessor, the equivalent of the hsffig program, and the source splitter. Everybody working on a project involving imports from foreign libraries: feel free to try it out. Any feedback will be appreciated. Suggested reading: http://www.haskell.org/haskellwiki/FFI_Imports_Packaging_Utility How to get it: This pre-release is available from the darcs repo only: no new downloads have been added yet to the project page at sourceforge.net. darcs get --partial http://hsffig.sourceforge.net/repos/hsffig-1.1 Run `make' first Then run Setup.hs as usual to configure/build/install the package. Don't forget to specify path to Alex if it is not on the default PATH. The package installs as HSFFIG-1.1 Requirements: GHC >=6.4 (I use 6.4.1) Cabal >= 1.1.3 (older version may not work because of excutables install bug and missing parts of API). For Cabal from darcs, read about the "new userHooks" option of ffipkg. Alex is needed Packages parsec and FilePath are needed. The package also contains an unfinished "xmldump" utility which depends on the hxt (XML Toolbox) package. Please let me know if this is a great inconvenience: I may remove it from the release. Hope that this utility will be useful for the developers. -- Dimitry Golubovsky Anywhere on the Web

1 0

Re: [Haskell] System.FilePath survey
by Bulat Ziganshin 09 Feb '06

09 Feb '06

Hello Krasimir, Friday, February 03, 2006, 2:03:20 PM, you wrote: KA> * Do you think that we have to use unboxed arrays of Word8/Word16 KA> for file path? utf8-encoded FastPackedString is much more appropriate and about unicode filenames in windows - i have a library what supports such filenames in NT/2000/XP systems. i plan to incorporate this functionality in Standard Hierachical Libraries AS> The task: Remove all files in a directory recursively. AS> The problem: In case the current encoding is UTF-8, filenames stored in AS> a different locale can comprise illegal UTF-8 sequences and are AS> therefore not representable as FilePath which is a Unicode string. Even AS> if the resulting Unicode sting is not 'error ".."', it is impossible to AS> call 'delete' on that file name, since fromUTF8 . toUTF8 cannot be the AS> identity function if the UTF8 byte sequence is illegal. AS> The solution: FilePath must be an abstract data type that is a sequence AS> of bytes. Programmers should only convert these to Unicode for AS> displaying them and otherwise treat them as opaque entities. In case of AS> invalid UTF-8 strings, the corresponding String will have an "invalid AS> unicode code character" substituted. but even my library can't really solve all problems. win95-based Oses don't support unicode APIs, afaik -- Best regards, Bulat mailto:bulatz@HotPOP.com

9 28