- Libraries - Haskell.org

darcs patch: make head/build rule apply to all types, not just Bool.
by John Meacham 03 Mar '06

03 Mar '06

Thu Mar 2 20:57:53 PST 2006 John Meacham <john(a)repetae.net> * make head/build rule apply to all types, not just Bool.

1 0

FunctorM
by Ross Paterson 02 Mar '06

02 Mar '06

I propose to deprecate Data.FunctorM in favour of Data.Traversable: http://www.haskell.org/ghc/dist/current/docs/libraries/base/Data-Traversabl…

3 4

conditional code, was: Template haskell instance checking
by Christian Maeder 02 Mar '06

02 Mar '06

heatsink wrote: > Is there a way, in template haskell, to find out what instance > declarations exist? I'm not trying to accomplish anything specific > right now, but I can see two potential uses for this. One is to emit > compile-time error messages from TH code which would be more informative > than the typechecker's output. The other is to produce TH functions > that conditionally generate code depending on the instances satisfied by > their arguments. Apologies for becoming off-topic now, I've got nothing against template haskell (TH), on the contrary, it is a great device to increase genericity. But I want to warn about conditional code, because this may become a nightmare to maintain. I.e. we (at Bremen) have (few) bits in TH that check if we run under windows or unix (but no one knows if the windows part is still working). Furthermore we support a few older (still recent) ghc versions with conditional code (like ghc itself can be bootstrapped with different older version). Plugging in various libraries using Cabal is a nice feature, but imagine if you would start to program depending on the currently installed packages (and visible instances)! (Fortunately, this would be hard to do currently.) So (despite cabal and the desire for a minimal kernel) I hope that ghc will continue to supply a large number of more or less "standard" packages or modules that can safely be expected to exist in (almost) every installation. (Therefore I've suggested to keep Data.Set and Data.Map in the base package, but another "standard" package may be fine, too). Otherwise truly application specific 3rd party cabal packages may all come with their own "Prelude extensions" rather than reusing increasingly solidified Haskell basics (that are hopefully not disputed too much by the design of Haskell-Prime). If you agree with me, great, ignore this posting. Respectfully Christian

1 0

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