- Libraries - Haskell.org

Re: libraries in hugs/nhc
by Jean-Philippe Bernardy 01 Mar '06

01 Mar '06

Good, so I propose to create a separate package (collections?) where we'll put the AVL-tree based collection types, plus the code they are based on. I will do this next week, provided I have the rights to create a new package on darcs.haskell.org Later on Data.Set/Map/IntSet/IntMap shall be moved to that package. Cheers, JP. On 3/1/06, Simon Marlow <simonmar(a)microsoft.com> wrote: > On 28 February 2006 16:47, Adrian Hey wrote: > > > On Tuesday 28 Feb 2006 9:46 am, Jean-Philippe Bernardy wrote: > >> On 2/27/06, Simon Marlow <simonmar(a)microsoft.com> wrote: > >>> I didn't see the start of this discussion, but I'd question whether > >>> AVL should go into the base package. What's the goal here? > >> > >> See my other reply to Ross. Text quoted below. > >> > >> A (better) alternative is of course to put this in its own package. > >> This is in line with the "decentralisation" idea indeed. I even say > >> we should put the existing Data.Map/Set; etc. into that package; so > >> "base" become lighter. > > > > To be honest it's never been too clear to me what the long term > > plans are for library distribution and the base package. > > As far as possible I think we should extract non-essential code from the > base package. The main constraint on base is that it must contain > enough to be able to implement the Prelude. There's a lot in there that > doesn't fit that criteria. If Prelude gets smaller in Haskell', then > base can be reduced even further (splitting out the I/O library, > perhaps). > > The minimum we can ship GHC with is those libraries required to > bootstrap GHC itself (any less would cause undue difficulties, I think). > This set is currently: base, haskell98, template-haskell, unix, Cabal, > readline. > > Ideally it should be configurable which packages are included in a GHC > build, so that systems with a good package manager (Debian, Gentoo, > FreeBSD etc.) can provide a minimal GHC and deliver further (Haskell) > packages as separate OS-managed packages. For some distributions, such > as the plain binary distribution, we will probably want to ship GHC with > a larger set of libraries by default. > > It has been at the back of my mind to think about this reorg at some > point. The main technical hurdle is that we really need to build the > libraries with Cabal, and that needs some extra support in Cabal. >

1 0

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 14 Feb '06

14 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

Re: [Haskell] System.FilePath survey
by Isaac Jones 08 Feb '06

08 Feb '06

Wolfgang Jeltsch <wolfgang(a)jeltsch.net> writes: > Am Freitag, 3. Februar 2006 12:03 schrieb Krasimir Angelov: >> [...] > >> * Will you be happy with a library that represents the file path >> as String? The opposite is to use ADT for it. The disadvantage is that >> with the current IO library we should convert from ADT to String and >> back again each time when we have to do any IO. The ADT may have >> advantages for the internal library implementation. > > I would very much prefer an ADT. An ADT would describe the actual logical > structure of a file path and this is something we should always try to > achieve. Has anyone yet volunteered to do the hard work of defining an ADT and made a proposal for how it should interact w/ the System.IO functions? I think that lacking a FilePath module is a serious problem that is holding haskell back. Lots of languages use String for filepath, like Python, which is hugely popular for these uses, but has nothing on Haskell, IMO, except this single library. Lots of people have written home-grown FilePath modules. How long can we wait for an implementation to appear? peace, isaac

5 6

RE: building haddock?
by Simon Marlow 08 Feb '06

08 Feb '06

On 31 January 2006 21:38, Isaac Jones wrote: > Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk> writes: > >> On Tue, 2006-01-31 at 13:54 +0000, Simon Marlow wrote: >>> Duncan Coutts wrote: >> >>>> We really need a field: >>>> >>>> cabal-depends: 1.1.4 >>>> >>>> So that older versions of Cabal can say "you need version >>>> ${cabal-depends} of Cabal to build this package". >>> >>> There is such a field: >>> >>> cabal-version: >=1.1.4 >> >> Really! I had never seen it. >> >>> but I didn't use it in Haddock (now fixed). This field doesn't help >>> with all the backwards compatibility issues, particularly API >>> changes in the Cabal libraries, as we know (see previous >>> discussions). >> >> Indeed, because by the time the cabal Setup.lhs reads the file it's >> too late. Hence my suggestion in the previous discussions for a cabal >> program that reads the file, decides which version of the Cabal libs >> to use and then builds a setup program and passes control on to that. > > Ahem. Cabal-install. > > It doesn't read that field yet, though. Do you intend cabal-install to be the main interface to Cabal? That's what Duncan was proposing (and others have suggested) - that we deprecate the use of 'runhaskell Setup.lhs' as the interface to Cabal in favour of a program to do the same. Certainly there doesn't seem much point in having *both* cabal-install and another wrapper, so clearly they should be the same thing. I do think this is the way to go, though. Cheers, Simon

5 6

cabal
by John Meacham 08 Feb '06

08 Feb '06

I am trying to get a development version of cabal working ;darcs get http://darcs.haskell.org/packages/Cabal ;runhaskell Setup.lhs ./Distribution/Simple.hs:61:1: lexical error zsh: exit 1 runhaskell Setup.lhs ;make Makefile:2: ../mk/boilerplate.mk: No such file or directory Makefile:24: ../mk/target.mk: No such file or directory make: *** No rule to make target `../mk/target.mk'. Stop. zsh: exit 2 make is there another one to try? John -- John Meacham - ⑆repetae.net⑆john⑈

2 3

SerTH for Data.Map
by Arie Peterson 07 Feb '06

07 Feb '06

Hello, Having read about the SerTH library, I am now trying to use it in my application. It works great for simple types. However, I ran into trouble when I tried to serialise > data S = S (Map Int Int) ; ghc complains that there is no instance for 'Serializable (Data.Map.Map Int Int)'. I am not sure how to derive such an instance. I tried > $(deriveSerializable ''Map) , which gave "Exception when trying to run compile-time code: ./Codec/Serialize/SerTH/BSerDerive.hs:(56,0)-(57,98): Non-exhaustive patterns in function sdef". Is this perhaps because 'deriveSerializable' cannot handle type constructors with arguments? Next I tried > type MapIntInt = Map Int Int > $(deriveSerializable ''MapIntInt) , giving the same error message. To investigate, I tried to serialise > type Foo = Int which did not work. However, it is possible to derive serialisation for > data Bar = Bar Char Foo Int with 'Foo' as above. So it seems that type synonyms can be serialised indirectly, but not directly. Could anyone give me a hint as to what I'm doing wrong? Or is what I'm trying not possible with SerTH? Thanks and greetings, Arie Peterson

2 3