- Libraries - Haskell.org

haskell.org libraries and tools page needs some fixing
by Björn Bringert 23 Mar '06

23 Mar '06

Hi all, I recently wanted to add some libraries to http://www.haskell.org/haskellwiki/Libraries_and_tools and noticed a number of problems. Problems: - The page is very large. - Many sections are large. - Many of the libraries linked to are obsolete. - Many of the links are dead [1]. - Many of the libraries have been moved into the standard libraries. - Some libraries are listed in multiple sections (at least some CGI libraries, there might be more). - Small and large, new and old libraries are mixed, and it's difficult for the reader to asses which things are relevant. - The page is not valid XHTML, the W3C Validator finds 433 errors [2]. * The pages uses <dt> tags everywhere, even though there is Wiki markup for definition lists. This seems to be causing most of the problems. Some possible remedies: - Replace dead links with Internet Archive links - Create an "obsolete" subsection of each section, and move old stuff there. Of course it can be difficult to figure out which things are obsolete, but I guess a first approximation would be everything for which the link is dead. - For libraries which are part of the standard libraries, provide links to the haddock page for the relevant module. - Replace HTML tags with Wiki markup. I'm willing to start working on this, but I want to check with you guys first. Any comments, ideas, or flames? I guess that if I start doing major stuff like chaning the mark-up, I'll put a note at the top asking people to hold off editing for a short while. /Björn [1] http://www.cs.chalmers.se/~bringert/misc/hslibs-checklink/checklink.html [2] http://validator.w3.org/check?uri=http%3A%2F%2Fwww.haskell.org%2Fhaskellwik…

8 10

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

Announcing Text.Regex.Lazy (0.33)
by Chris Kuklewicz 21 Mar '06

21 Mar '06

Announcing : Text.Regex.Lazy (0.33) Where : http://sourceforge.net/projects/lazy-regex Who : Chris Kuklewicz <haskell(a)list.mightyreason.com> License : BSD, except for DFAEngine.hs which is LGPL (derived from CTK light) What: This is an alternative to Text.Regex along with some enhancements. GHC's Text.Regex marshals the data back and forth to c-arrays to call libc and this is far too slow (and strict). This module understands regular expression Strings via a Parsec parser and creates an internal data structure (Text.Regex.Lazy.Pattern). This is then transformed into a Parsec parser to process the input String, or into a DFA table for matching against the input String or FastPackedString. The input string is consumed lazily, so it may be an arbitrarily long or infinite source. The main modules of interest are: (*) Text.Regex.Lazy.Compat is supposed to be a drop in replacement for Text.Regex which uses Parsec and lazy matching. (*) Text.Regex.Lazy.Full allows for different strategies and for expanded syntax . This uses Parsec and a choice of lazy or strict matching. (*) Text.Regex.Lazy.CompatDFA uses a fast lazy DFAEngine for regex matching. (*) And an early version of Text.Regex.Lazy.DFAEngineFPS applies the DFAEngine to a Data.FastPackedString (untested). Why might you use this? (+) You would rather not translate a regular expression into a hard coded predicate for matching or filtering a string. (+) You can parse something via parenthesized subgroup capture of a regular expression and not have to write all the parsec manually. (+) You need to filter a large input (from stdin, for example) with a regex and want to do it lazily instead of all at once. (+) You want to build your own extensions to regex syntax for your project and would rather not have to rewrite one of the c-libraries to do it. What might you contribute? (.) Use it and report rough edges, incompatibilities, and bugs. (.) You can think of clever analysis and optimizations (e.g. taking the Pattern data as input). (.) Your favorite extended syntax (e.g. giving meaning to various backslashed letters, etc.). (.) You have a sinister regular expression & input to contribute as an evil test case.

1 0

RE: UTF8 (was Re: Hexdump)
by Bayley, Alistair 21 Mar '06

21 Mar '06

> From: libraries-bounces(a)haskell.org > [mailto:libraries-bounces@haskell.org] On Behalf Of Malcolm Wallace > > I was also thinking it would be nice to have pure Haskell > implementations of the various Unicode encodings. Here is my > attempt at > the UTF-8 codec. Like Dominic, I am wondering where such a module > should live in the hierarchy? > > Text.Codec.UTF8 > Codec.Text.UTF8 > Text.UTF8 > Codec.UTF8 > > Regards, > Malcolm My initial instinct is to put the UTF codecs in Foreign.C (Foreign.C.Unicode, say, or Foreign.C.Codec), because I've only used ever used them to marshall between Haskell Strings and CStrings. Also, a bunch o' functions like withUTF8CString{Len}, peekUTF8CString, etc are also useful. OTOH, I can think of uses for non-CString oriented codecs (e.g. converting an HTTP request body from a specific charset to Unicode), so maybe this is a dumb idea. Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

1 0

Capturing facility of OpenAL binding
by Dmitry V'yal 18 Mar '06

18 Mar '06

Hello. I am going to play with sound processing using Haskell. I need to capture sound in my program somehow. According to it's documentation, OpenAL supports sound capturing. So I decided to use Haskell binding to it. http://haskell.org/ghc/docs/latest/html/libraries/ doesn't mention OpenAL. I managed to find API where: http://www.haskell.org/HOpenGL/newAPI/OpenAL/Sound-OpenAL-ALC-Capture.html But it's half complete compared to http://openal.org/openal_webstf/specs/OpenAL1-1Spec_html/AL11Spec6.html Then I looked through ghc-6.4.1 library sources and didn't find ghc-6.4.1/libraries/OpenAL/Sound/OpenAL/ALC/Capture.hs at all. But it must be where according to online docs. So the question is whether OpenAL binding supports capturing or not and is it planned to add it in the latter case? Thanks in advance.

2 1

Re: 6.4.2 release plans
by shelarcy 18 Mar '06

18 Mar '06

On Thu, 16 Mar 2006 01:54:03 +0900, Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk> wrote: > We have 2 patches. One to fix compilation of OpenAL: > http://haskell.org/~gentoo/gentoo-haskell/portage/dev-lang/ghc/files/ghc-6.… > (I know this is fixed in darcs, I've not checked cvs ghc-6.4-branch) OpenAL's configure.ac uses different form that is compared by OpenGL and GLUT, and also darcs repositories ALUT. So now version - both cvs ghc-6.4-branch and darcs - can't build on Mac OS X platform. And cvs ghc-6.4-branch's OpenAL has also some problems, so can't build under Windows platform, either. http://www.haskell.org//pipermail/libraries/2005-September/004399.html I think best solution is: 1. to change darcs repository OpenAL's configure.ac form that is same as ALUT, OpenGL and GLUT. 2. then, to merge darcs repository's OpenAL. -- shelarcy <shelarcy capella.freemail.ne.jp> http://page.freett.com/shelarcy/

1 1

cabal-setup
by Simon Marlow 16 Mar '06

16 Mar '06

Following discussions a while back: http://www.haskell.org//pipermail/libraries/2006-January/004815.html there was some concensus (although not unanimous) that Cabal's user interface should be a wrapper program that runs Setup.hs. I've implemented a first cut at this, see the attached Cabal patch. It addresses this ticket: http://hackage.haskell.org/trac/hackage/ticket/63 I'm sending it here rather than committing directly, because I imagine there will be some discussion about whether this is the right thing. I'm pretty convinced this is the right way to go: it solves the Cabal versioning problem, and it frees the programmer from having to write a boilerplate Setup.hs file. It's a step on the way to supporting building of multiple packages. Look at the patch, tell me what you think. You'll need a completely up-to-date Cabal from darcs to build it. Cheers, Simon

5 4

Network.CGI
by Sebastian Sylvan 15 Mar '06

15 Mar '06

Hello. Sending values (over GET or POST) to a CGI-script does not work in IE if the value contains the character '@'. Sending it a string "hello@world" will return just "hello" in the key-value pair list that you get from the wrapper. Is there a reason for this? It looks like IE isn't encoding the strings (while firefox is), but should we require that it does? Couldn't we just change 'extra' to: extra :: Parser Char extra = sat (`elem` "!*'(),@") -- note the added '@' That would fix it, right? /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862

1 0

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

14 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

UArray
by Frederik Eaton 14 Mar '06

14 Mar '06

I was trying to track down the problem with this piece of code: instance (Elt k, IxB a, Eq a, Eq k) => Num (Vector k a) where (+) = vmap2 (+) (-) = vmap2 (-) (*) = vmap2 (*) negate = vmap negate signum = vmap signum abs = vmap abs fromInteger n = vconst $ fromInteger n Vector2.hs:246:0: Could not deduce (Eq (UArray a k)) from the context (Elt k, IxB a, Eq a, Eq k) arising from the superclasses of an instance declaration at Vector2.hs:246:0 Probable fix: add (Eq (UArray a k)) to the instance declaration superclass context or add an instance declaration for (Eq (UArray a k)) In the instance declaration for `Num (Vector k a)' So it appears that here is another barrier to using UArray polymorphically. Am I the first user of this interface? In Data/Array/Base.hs it says: eqUArray :: (IArray UArray e, Ix i, Eq e) => UArray i e -> UArray i e -> Bool eqUArray arr1@(UArray l1 u1 _) arr2@(UArray l2 u2 _) = if rangeSize (l1,u1) == 0 then rangeSize (l2,u2) == 0 else l1 == l2 && u1 == u2 && and [unsafeAt arr1 i == unsafeAt arr2 i | i <- [0 .. rangeSize (l1,u1) - 1]] ... instance Ix ix => Eq (UArray ix Bool) where (==) = eqUArray instance Ix ix => Eq (UArray ix Bool) where (==) = eqUArray instance Ix ix => Eq (UArray ix Char) where (==) = eqUArray instance Ix ix => Eq (UArray ix Int) where (==) = eqUArray instance Ix ix => Eq (UArray ix Word) where (==) = eqUArray ... etc. Why define separate instances when one could just define one equivalent one: instance (Ix ix, Eq e, IArray UArray e) => Eq (UArray ix e) (==) = eqUArray ??? The same question applies to the Ord instances in that file. I can give an answer *why not* do this: it makes UArray even more unusable. UArrays which are polymorphic in their element types cannot be compared. Here is another patch, please apply: --- /home/frederik/ghc-6.4/libraries/base/Data/Array/Unboxed.hs.old 2006-03-12 18:34:14.000000000 +0000 +++ /home/frederik/ghc-6.4/libraries/base/Data/Array/Unboxed.hs 2006-03-12 18:35:32.000000000 +0000 @@ -10,6 +10,9 @@ -- -- Unboxed immutable arrays. -- +-- Beware that these arrays are generally not usable polymorphically +-- because of problems with Eq and Ord instances. +-- ----------------------------------------------------------------------------- module Data.Array.Unboxed ( Confused, Frederik On Sun, Mar 12, 2006 at 02:58:42AM +0000, Frederik Eaton wrote: > I see. The solutions on that thread, i.e.: > > http://www.mail-archive.com/haskell%40haskell.org/msg17085.html > > would seem to require me to at least declare an instance of some > class, for every type that I want to support. So the short answer to > "I'm trying to figure out how to use STUArray. Is it possible to let > it be polymorphic?" appears to be "No". > > Perhaps some sort of warning in the documentation for STUArray is in > order, until Bulat's code can be incorporated? > > By the way, why make the distinction between unboxable types and > "other" types in the first place? E.g., just because I want something > to work quickly on "Int", doesn't mean that I don't want it to work at > all on "String". It seems that there could be a default "IArray UArray > e" instance which just implements a regular Array behind the scenes. > > Frederik > > On Fri, Mar 10, 2006 at 11:49:10PM +0100, Benjamin Franksen wrote: > > On Friday 10 March 2006 23:01, Frederik Eaton wrote: > > > I'm trying to figure out how to use STUArray. Is it possible to let > > > it be polymorphic? > > > > Hi Frederik > > > > I think this thread (and the one it referres to) provide a solution: > > > > http://www.mail-archive.com/haskell%40haskell.org/msg17081.html > > > > Ben > > -- > > There are three kinds of programmers: those who make off by one errors, > > and those who don't. > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > -- > http://ofb.net/~frederik/ > -- http://ofb.net/~frederik/

4 4