March 2004 - Haskell - Haskell.org

ANNOUNCE: HaskellDB 0.6
by Anders Höckersten 03 Mar '04

03 Mar '04

We are pleased to announce the second alpha release of our "remake" of HaskellDB, version 0.6. The main feature of this release is our implementation of bounded lists, which may even be interesting outside of HaskellDB. Read on below for more information about it. HaskellDB is a Haskell library for expressing database queries and operations in a type safe and declarative way. HaskellDB compiles a relational algebra-like syntax into SQL, submits the operations to the database for processing, and returns the results as ordinary Haskell values. The original version of HaskellDB was written by Daan Leijen and is available at http://www.haskell.org/haskellDB/. The implementation is based on his paper which can be found at: http://www.cs.uu.nl/people/daan/download/papers/dsec.ps Our implementation is available at: http://haskelldb.sourceforge.net New in HaskellDB 0.6: - Bounded lists and bounded strings (see below) - Vastly increased performance. On reasonably modern computers, I/O is now the limiting factor when doing database operations - Transactions are now supported - Some error messages (esp. some type errors) are easier to understand - Better documentation - Many, many bug fixes About bounded lists: The main idea of bounded lists is to create lists with predetermined maximum sizes. BoundedList is a simple, fast and type safe approach to implementing this idea. The implementation is based on inductive instances, making it very easy to expand with new bounds. A new bound only requires one instance of Size and two instances of Less. NOTE: Due to changes in DbDirect, any files generated using the old version of HaskellDB should be regenerated. The developers can be reached at haskelldb-users(a)lists.sourceforge.net or on #haskelldb at irc.freenode.net. / The HaskellDB development team

1 0

[Haskell] Incremental Array update (Re: performance tuning Data.FiniteMap)
by Koji Nakahara 03 Mar '04

03 Mar '04

Hi, Reading the recent discussions abount Array and FiniteMap, I want to know what people think about the current specification of the Array update. The Array implementaton of GHC effectively has this property (like FiniteMap): (arr // cs1) // cs2 == arr // (cs1 ++ cs2) -- allow duplicate indices Because (//) copies a whole array and slow, instead of the successive updates, I usually accumulate those changes to a list as many as I can in advance, and then give it to (//). As far as GHC is concerned, all we have to do is to concatenate the list of changes by (++) thanks to the propety. It generally results in a huge performance inprovement. However, Haskell Report reads (16.2): > (As with the array function, the indices in the association list must be unique for the updated elements to be defined.) So, we must somehow (as oleg's add_uniq[1]) remove the preceding elements having the same index from the list to make the program comply Haskell 98 and support Hugs since Hugs does implement that check. The preconditioning (and also the check performed by the runtime system) causes no small amount of performance hit. I think it would be better if the above property of incremental updates of Array is guaranteed sometime hopefully in Haskell 2. Note: 0) Array give us O(1) read. 1) FiniteMap has the same property. 2) Array is more convenient than monadic arrays, e.g. STArray. 3) Array is faster than ST(U)Array in my experience, if the size of the array is no more than about 100 (when the updates can be combined). 4) The runtime optimization which converts "(arr // cs1) // cs2" to "arr // (cs1 ++ cs2)" might be possible? [1] http://www.haskell.org//pipermail/haskell/2004-February/013724.html --- Koji Nakahara

2 2

[Haskell] Postdoc in program development, analysis and transformation
by Wim Vanhoof 03 Mar '04

03 Mar '04

(apologies for multiple copies) Dear all, I would like to announce that the department of computer science of the University of Namur, Belgium, is seeking a post-doctoral researcher for a one-year fellowship in the area of (logic-based) program development, analysis and transformation. Candidates should not be older than 35 years and hold a PhD in computer science (or equivalent) acquired within the past five years at a university outside Belgium. For more details, please contact Wim Vanhoof (wva(a)info.fundp.ac.be) or visit http://www.info.fundp.ac.be/~cri/PostDocProjects/index.html Please note the deadline for application is april 2, 2004. Kind regards, Wim Vanhoof. ------------------------------------------------------------ Wim Vanhoof E-mail: wva(a)info.fundp.ac.be University of Namur Tel. ++32(0)81.72.49.77 Rue Grandgagnage, 21 Fax. ++32(0)81.72.52.80 B-5000 Namur http://www.info.fundp.ac.be/~wva Belgium

1 0

Announce: wxHaskell 0.6
by Daan Leijen 03 Mar '04

03 Mar '04

Announcement: wxHaskell version 0.6 ---------------------------------------------------------------------- <http://wxhaskell.sourceforge.net> This new release fixes many bugs, adds basic support for MDI applications and compiles with the latest CVS snapshots of wxWidgets. For now, only an installer for windows is provided. All the best, Daan. News (see the wxHaskell website for more information): - wxWindows is now called wxWidgets! (and yes, it is due to Microsoft :-) - wxWidgets runs on mobile phones (Symbian OS). - Borland Builder-X will ship with wxWidgets as its windowing toolkit. Updates: - Support for MDI applications - Combobox now catches enter keys through "on command" - Many list-like controls now react on "on select" instead of "on command" - Attribute "enable" is now called "enabled" - Resize bugs are fixed, new "dynamic" layout combinator added - Repaint bugs are fixed, new "fullRepaintOnResize" attribute added. - Basic support for unicode fonts (see the screenshots page) Tested on: - windowsXP and windows 2000 with ghc 6.2, 6.0.1, and wxMSW 2.4.2 - MacOS X 10.3 (Panther) with ghc 6.2 and wxMAC 2.5.1 (20 feb 2004) - MacOS X 10.2 (Jaguar) with ghc 6.0.1 and wxMAC 2.4.2 - Red Hat Linux 10 (Fedora) with ghc 6.2 - FreeBSD, with ghc 5.05.xxxx and wxGTK 2.4.1 - and wxHaskell has been known to run on other platforms :-) ---------------------------------------------------------------------- wxHaskell is a portable GUI library for Haskell. The goal of the project is to provide an industrial strength portable GUI library, but without the burden of developing (and maintaining) one ourselves. wxHaskell is therefore build on top of wxWidgets -- a comprehensive C++ library that is portable across all major GUI platforms; including GTK, Windows, X11, and MacOS X. Furthermore, it is a mature library (in development since 1992) that supports a wide range of widgets with native look-and-feel, and it has a very active community (ranked among the top 25 most active projects on sourceforge). Since most of the interface is automatically generated from the wxEiffel binding, the current release of wxHaskell already supports about 75% of the wxWindows functionality -- about 2900 methods in 500 classes with 1400 constant definitions. wxHaskell has been build with GHC 6.x on Windows, MacOS X and Unix systems with GTK. A binary distribution is available for Windows and MacOS X. And even if you don't intend to write GUI's yourself, it will be fun to check out the screenshots at <http://wxhaskell.sourceforge.net>. All the best, Daan Leijen.

4 7

definition of intersperse
by Iavor S. Diatchki 03 Mar '04

03 Mar '04

hello, i'd like to suggest that the definition of "intersperse" from the List module be made more lazy. in the hugs prelude (and GHC exhibits the same behaviour) we are given the following defn: intersperse :: a -> [a] -> [a] intersperse _ [] = [] intersperse _ [x] = [x] intersperse sep (x:xs) = x : sep : intersperse sep xs the second equation makes the defn, strict in the tail of the list. this is a probelm when processing lazy lists (e.g. things coming over a network), as one gets all events with a delay. here is an alternative definition: intersperse :: a -> [a] -> [a] intersperse _ [] = [] intersperse sep (x:xs) = x : rest where rest [] = [] rest xs = sep : intersperse sep xs bye iavor -- ================================================== | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | ==================================================

2 1

Re: [Haskell] performance tuning Data.FiniteMap
by JP Bernardy 03 Mar '04

03 Mar '04

> I believe FiniteMap works by representing the data > in binary trees. It is therefore O(log2(n)) to > read and update. > > However, if my application reads many more times > than it writes, then perhaps I can get a > substantial performance boost by increasing the > branch factor on the tree. For example, if each > node was an array of 256 elements, reads would be > O(log256(n)), a 128x improvement! Not quite. In fact, O(log256(n)) is equivalent to O(log2(n)), because there is only a constant factor between the two. That's why basis of logarithms are usually omitted in O() expressions. Besides, the ratio between log256(n) and log2(n) is more like 8 than 128. (And you'd loose this factor in searching the right subtree, as Ketil pointed out) Tuning Data.FiniteMap probably is not what you want. I don't know, but you can have a look at Data.Hashtable. Just my 2 cents, JP. __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools

6 9

RE: [Haskell] System.Random
by Simon Marlow 03 Mar '04

03 Mar '04

> Now, I don't understand this at all... > > All the development of the Random stuff in all languages has nothing > of random whatsoever. Perhaps *some* people like to seed the generator > with the clock time, but most *real* developers *known to me* > usually choose > the seed deterministically, in order to reproduce the sequence, until > the program is ready to run in the end-user environment. I suspect that developers requiring a good source of randomness for security would disagree with you. Not to say that there aren't lots of good reasons for having a deterministic pseudo-random generator too (eg. random test generation), but let's not say that one is more important than the other. However, the current System.Random doesn't provide a good interface for those requiring true randomness. You have to reseed all the time, and the implementation is pretty weedy (seeding from /dev/random where available would be better). The Random library *could* be split into its pure and IO-ish parts. It's probably only worth doing if someone were to undertake a redesign/rewrite of the library. Cheers, Simon PS. why on earth did I let myself get dragged into this thread? I have no interest in it whatsoever :-S

2 1

RE: [Haskell] System.Random
by Simon Marlow 02 Mar '04

02 Mar '04

> why is the Random module situated under System? Wouldn't > something like Data be more adequate? There is usually an external source of randomness, which is why the library in placed in System rather than Data. A purely functional random library would be rather less useful... Cheers, Simon

4 3

Announce: buddha version 1.1
by Bernard James POPE 02 Mar '04

02 Mar '04

Announcing buddha version 1.1 ----------------------------- www.cs.mu.oz.au/~bjpop/buddha New in this release: - support for GHC 6.2 - better user interface - many bug fixes -------------------------------------------------------------------------- A declarative debugger for Haskell 98. It is based on program transformation and works with GHC 5.x and 6.x. buddha offers a declarative debugging algorithm and a browsing mechanism. It is useful for finding logical errors in programs and for exploring computations in a high-level manner. Version 1.1 is known to work on GNU/linux (x86). It _ought_ to work on any unix-like system including Mac OS X, and freeBSD. It does not work on Windows (as far as I know). buddha is released under the GPL license. Enjoy! Bernie.

1 0

System.Random
by Wolfgang Jeltsch 01 Mar '04

01 Mar '04

Hello, why is the Random module situated under System? Wouldn't something like Data be more adequate? Wolfgang

1 0