- Libraries - Haskell.org

Re: Haskell Matrix Library
by Keean Schupke 29 Jun '05

29 Jun '05

Must be the season for matrix-libraries... Alberto Ruiz has just posted bindings to the GSL library on the haskell-cafe which seems to do more or less what I need from a matrix library - and more efficiently than doing it in Haskell. I'm going to give this a go and see if it does what I need. Keean.

1 0

Are new sequences really O(1)?
by Adrian Hey 28 Jun '05

28 Jun '05

Hello, Just been trying a few simple benchmarks to compare the new sequences with AVL trees for simple deque operations and I'm getting some strange results. Code for both is attached at the end of this post, but basically the test in each case is: 1- Build a sequence of sz elements by pushing them one by one on the right. 2- Rotate the sequence right sz times, each rotation pops the rightmost element and pushes it on the left. 3- Empty the sequence by popping the leftmost element sz times. With ghc-6.4, results are (time in no particular units) sz AVL Sequence ---------------------- 2^10 0.278 0.177 2^11 0.666 0.425 2^12 1.464 0.958 2^13 3.112 2.214 2^14 6.664 5.525 2^15 14.18 12.18 2^16 30.16 27.31 2^17 62.14 60.6 2^18 130.4 142.6 2^19 269.3 365.1 2^20 564.4 ***** The AVL figures seem to show roughly the kind of n*(log n) growth I would expect. The Sequence figures start out promisingly enough, but seem to get progressively worse until it's actually slower than AVL. This isn't what I'd expect from an algorithm advertised as having O(1) asymptotic complexity for pushing/popping. It seems more like O(log n) or worse? Also there are no figures for 2^20 for Sequence because I get a stack overflow at this point. So any idea whether this is a bug in my understanding?, or a bug in the theory?, or a bug in the code perhaps? Maybe it's being excessively lazy somewhere (often the cause of stack overflows IME). Regards -- Adrian Hey Code follows: {-# OPTIONS -fno-cse -fno-full-laziness #-} module Main (main) where import Data.Sequence import System.CPUTime(getCPUTime,cpuTimePrecision) import System.Mem(performGC) result :: Int -> Seq () result sz = rep pop $ rep rot $ rep push empty where rep = rep' sz rep' 0 f x = x rep' n f x = let x' = f x in x' `seq` rep' (n-1) f x' push sq = sq |> () rot sq = case viewR sq of sq' :> x -> x <| sq' EmptyR -> empty pop sq = case viewL sq of _ :< sq' -> sq' EmptyL -> undefined test :: (Int,Int) -> IO () test (n,sz) = do performGC t0 <- getCPUTime rep n t1 <- getCPUTime putStr $ show sz ++ " : " putStrLn $ show $ (fromIntegral ((t1-t0) `div` cpuTimePrecision)) / (fromIntegral n) where rep 0 = return () rep m = (result sz) `seq` rep (m-1) main :: IO () main = mapM_ test [(10*2^(maxP-p), 2^p) | p <- [10..maxP]] where maxP = 20 ---------------------------------------------------------------- {-# OPTIONS -fno-cse -fno-full-laziness #-} module Main (main) where import Data.Tree.AVL import System.CPUTime(getCPUTime,cpuTimePrecision) import System.Mem(performGC) result :: Int -> AVL () result sz = rep pop $ rep rot $ rep push empty where rep = rep' sz rep' 0 f x = x rep' n f x = let x' = f x in x' `seq` rep' (n-1) f x' push sq = pushR sq () rot sq = case popR sq of (sq', x ) -> pushL x sq' pop sq = case popL sq of (_ , sq') -> sq' test :: (Int,Int) -> IO () test (n,sz) = do performGC t0 <- getCPUTime rep n t1 <- getCPUTime putStr $ show sz ++ " : " putStrLn $ show $ (fromIntegral ((t1-t0) `div` cpuTimePrecision)) / (fromIntegral n) where rep 0 = return () rep m = (result sz) `seq` rep (m-1) main :: IO () main = mapM_ test [(10*2^(maxP-p), 2^p) | p <- [10..maxP]] where maxP = 20

14 45

RE: package mounting
by Simon Marlow 28 Jun '05

28 Jun '05

[ moved to the libraries list; replies here please ] On 24 June 2005 16:22, Frederik Eaton wrote: > (By the way, sorry about cross-posting again. People have already > replied to just 'haskell@' and just 'libraries@' but I'll try to stick > to 'libraries@' after this since it seems that some users' mail > clients show them two copies otherwise) > >> This idea has been raised before, but it was a while back, and we >> called it "grafting". Here's the start of the thread, which went on >> for quite some time: >> >> http://www.haskell.org/pipermail/libraries/2003-August/001310.html > > Actually it looks like that is slightly different from my idea, > perhaps I should have expounded a bit more in my original post. > Correct me if I'm wrong, but in my proposal: > > - grafting/mounting would be done per compilation unit. In yours it > seems it would be done per (user, system). > > - configuration of graft/mount points would be done at compile time, > zero or one times per package import option. In yours it would be at > package install time. Technologically it makes no difference; the key point from an implementation point of view is that the grafting point is not specified when a package is compiled, it is specified at some later time, and without modifying the contents of the package itself. The rest is "just" the user interface. > I think my proposal is better. In it there would be no cross-system > compatibility issues: since each program would specify where its > imported packages get mounted itself, you could write a Haskell > program on one system and be assured that someone else could use it on > another system without problems. I think this is a rather important > property and we shouldn't allow it to be broken Plain Haskell source code is already not portable, because it doesn't contain packaage dependencies. Also, "exposed" and "hidden" packages break portability, which is why Cabal now explicitly hides all packages. Our story for portability is that the extra information needed to ensure portability of your source code is contained in the Cabal package: you can't necessarily move plain Haskell source from one system to another and expect it to compile, but you *can* move a Cabal pacakge. If we had grafting/mounting, I think it would be most naturally exposed as a straightforward extension of Cabal's build-depends field, where a grafting location would be listed with each package dependency. Of course, there would be equivalent command-line options for raw use of the compiler. And for the same reason we have "exposed" packages, it makes sense to have a default set of grafting locations per user/system (this is debatable; indeed sometimes I think we should remove "exposed" completely and force non-Cabal users to write -package flags). Cheers, Simon

2 1

Dummy export for Text.Show.Functions
by Thomas Jäger 27 Jun '05

27 Jun '05

Greetings list, The module Text.Show.Functions only defines a Show instance for function types, and thus exports nothing. This is annoying when -Wall is used, as ghc can't check whether the instance is actually used in the program and always issues a warning. > Warning: Module `Text.Show.Functions' is imported, but nothing from it is used > (except perhaps instances visible in `Text.Show.Functions') Would it be possible for Text.Show.Functions to (re)export a dummy entity, preferably Show(..), since most modules that use this module will call show anyway? Thomas

2 1

AVL library update available.
by Adrian Hey 26 Jun '05

26 Jun '05

Hello, At.. http://homepages.nildram.co.uk/~ahey/HLibs/Data.Tree.AVL/ ..you can find the another release of the Data.Tree.AVL library. A few notes about this release: The library is not intended to provide an elegant api or to be a model of what general purpose collection classes should look like. It just aims to provide raw AVL operations as efficiently and flexibly as possible. This version and the Data.COrdering library have had a major purge of 1 line trivia (which I decided were really little more than name space pollution in practice). I'm sure that anybody using it is quite capable of writing whatever trivia they need so I decided to try and restrict myself to the stuff you really don't want to have to write yourself if you can avoid it. So the Map module has been removed completely. This release has also had a Zipper module added, which should be useful for implementing many of those awkward operations not covered by the main library. Earlier (on the libraries list I think), I said I would also include AVL tree based clones of Data.Set and Data.Map. I did start on this but then stopped as I don't think there's any point. The native AVL api is more useful (in my completely biased and not at all humble opinion :-). But these clones are about 75% complete so if somebody really wants them finished I might be persuaded to do this. In the meantime there's are some conversion utilities to convert between AVL trees and Data.Set, Data.Map. The library is not yet cabalised as there are apparently some difficulties using cabal with the ghc -split-objs option (which I use to reduce the bloat of executables). But the makefile enclosed should work OK on *nix environments for ghc 6.4 only (it uses new package descriptions so won't work with earlier ghc versions). The source code should be OK with other Haskells too, but the makefile assumes ghc. I haven't tried building under windows (shouldn't be too hard but makefile would probably need some hacking). I'd like to think this is reasonably complete (and stable) now, but it almost certainly isn't complete. So if anybody has any feature requests please let me know. I've marked the modules as being "stable", so I promise not to introduce any radical api changes or disappearances in future releases. Regards -- Adrian Hey

1 0

cabal permissions problems
by Frederik Eaton 25 Jun '05

25 Jun '05

I think I remember running into something like this a long time ago and mentioning it to someone, is it fixed in a new version of Cabal? I'm using ghc 6.4... The problem is that executable files are installed to be only executable by user: $ ls -al built/bin/ total 3644 drwxrwxr-x 2 frederik frederik 4096 2005-06-25 15:35 . drwxrwxr-x 3 frederik frederik 4096 2005-06-24 19:57 .. -rwxrw-r-- 1 frederik frederik 1183668 2005-06-25 15:40 fcq -rwxrw-r-- 1 frederik frederik 2528637 2005-06-25 15:40 fcq-www.cgi $ umask 002 I haven't experienced this with any other installation procedures, only Cabal. Thanks, Frederik -- http://ofb.net/~frederik/

1 0

ANNOUNCE: Gtk2Hs version 0.9.8 released
by Duncan Coutts 25 Jun '05

25 Jun '05

Gtk2Hs - A Haskell GUI library based on the Gtk+ GUI Toolkit. Version 0.9.8 is now available from: http://haskell.org/gtk2hs/ Changes since 0.9.7: * much greater API coverage, including the new Gtk+ 2.6 APIs * Yampa/wxHaskell-style properties added for all widgets * improved reference documentation, there is more of it and the docs for each module are now split into sections. * works with GHC 6.4 * there is now an easy-to-use installer for Windows * build process now works in 80Mb of RAM rather than 380Mb * added functions for manipulating Pixbufs using the Haskell mutable array interface * fixed a limitation on signal handlers on Sparc machines * minor API changes * minor bug fixes * completed GPL to LGPL conversion * internal code cleanups and improvements The API changes are documented here: http://haskell.org/gtk2hs/archives/2005/06/20/api-changes-between-gtk2hs-09… Other changes since the last release announcement: * new screenshots, including HRay and HanDict: http://haskell.org/gtk2hs/screenshots/ * we are now included in the Gnome news feed: http://planet.gnome.org/news/ Gtk2Hs feature highlights: * automatic memory management * Unicode support * nearly full coverage of Gtk+ 2.6 * bindings for several Gnome modules: * libglade for loading GUIs from xml files at run-time. This allows you to design your user interface visually with the Glade user interface builder. (This works on Windows too.) * GConf, Gnome's system for storing app preferences * SourceView, code editor widget with syntax highlighting * the Mozilla browser rendering engine in a widget * API reference documentation * multi-platform support with native look * LGPL licence Platforms and requirements: * an installer for Windows is available * packages are now available for Fedora Core 3,4 and Gentoo * packages for other platforms should become available soon * builds from source on Linux, Windows, MacOS X and Solaris * builds with GHC 6.4.x, 6.2.x, 6.0.x and 5.04.x * works with Gtk+ version 2.0 through to 2.2, 2.4 and 2.6 * optional Gnome support requires Gnome 2.0 or better * optional Mozilla support requires Mozilla 1.4 or better Goals for the 1.0 release: * autumn 2005 release * a stable API for the 1.0.x series * complete coverage of the Gtk+ API (we're about 90% there now) * support for OpenGL 3D rendering API * support for cairo 2D rendering API * bindings for more Gnome modules * introductory and other tutorials * packages for all popular platforms Please report all problems to gtk2hs-users(a)sourceforge.net Contributions and feedback are also most welcome. Duncan

2 3

rfc: package mounting
by Frederik Eaton 23 Jun '05

23 Jun '05

Hi all, It looks like there's been a bit of recent discussion regarding module and package namespaces. There is a certain possible design feature that I don't think has been mentioned yet, that I think would be very helpful, so I thought I should at least bring it up. What I want is to be able to build a module namespace for a program out of packages in much the same way that filesystem namespaces are built, namely with mounting operations, rather than just by "union" or "overlay" operations as in the status quo. In other words I would like to be able to specify along with the "-package" option a "mount point" for that package in the module namespace. One possible option syntax might be e.g. "-package my-graphics-lib -package-base Graphics.UI.MyGraphicsLib". (Also, for backward compatibility and convenience, packages should probably be able to specify a default "mount point", to allow existing compiler command-line syntax to be used.) The idea is that with such a feature, library packages could get rid of the common module path prefixes which currently must be specified in every module in the library (such as "Graphics.UI.MyGraphicsLib" above). These prefixes would instead be specified once by each user of the library package (unless the default was desired), perhaps after the package import option on the compiler command line. Modules would have simple unqualified names within the library, like "Button" or "Window" which, if the package mount point were specified as say "Graphics.UI.MyGraphicsLib" in a certain compiler invocation, would be mapped to "Graphics.UI.MyGraphicsLib.Button" and "Graphics.UI.MyGraphicsLib.Window" respectively for code compiled by that invocation. But they could just as easily be mapped to "MGL.Button" etc. in a different invocation in a different project if a different mount point were preferred or were necessary to eliminate a namespace collision. There would be many benefits to being able to do things this way. First, developers would be able to move shared code across libraries without having to worry about the need to make widespread trivial changes to reflect the new module names. I could copy a 'Debug' or 'Util' module into my library from another library, and not have to go through the code to update the module hierarchy base location - furthermore I could incorporate new upstream changes easily without having to repeat this menial fixing-up procedure each time. While it's true that new version control systems like 'darcs' are meant to handle search-and-replace style changes effectively, I think that as far as this issue goes, a VC-based solution would be less elegant and less usable than what I am proposing. Second, this would decouple some aspects of the design process that in my opinion shouldn't be coupled. I would be able to start writing a library before deciding on a name, for instance - currently I at least have to stick in a dummy name as the module namespace base to avoid potential conflicts with other library imports while testing. But under this proposal I could just concentrate on building interior, bottom-up functionality first - at the end of the process a certain set of the package modules would be marked for external visibility, would comprise the exterior interface, and would suggest to me a fitting package name. Setting this name would only involve touching the cabal file rather than every single source file in my library. This would also make it easier to merge and split packages. Third, it would encourage the use of lightweight modules, by reducing the maintenance overhead of each module. Currently modules are the only way (correct me) to partition parts of the top-level namespace of a program - this is OK except that especially in libraries each module contains a certain amount of administrative paperwork, which is to say that it has to know the name of the library that contains it, because that, or some form of it, has to be part of the module name; and other importers of the module have to specify this information too; and as argued above there is a little work involved in touching up these references when code moves between libraries or when the library name changes. As a result I think people end up sticking more code in the same module at times when multiple modules would have been otherwise more suitable. Fourth, I think there would be psychological benefits. I think it's a bit patronizing to the programmer that he has to pretend to remind himself "you are in the following package" at the top of each file. I think people can easily enough keep track of that amount of state. It's as if the building code required me to put a sign with the current city and country in each room of my house. These are bits of context that I can easily call to mind if necessary, but which I would sometimes like to temporarily forget about. I believe programming is somewhat the same. We've come a long way from languages like C where one has to decide whether to precede each symbol in a library with an otherwise-meaningless identifier like "Py_", or risk namespace collisions with other libraries - but I don't think we're at the end of the road yet. It's true that if a module occurs in a package then that is its package, but often the package name doesn't do anything to suggest what the module functionality is - maybe the module exists only because other package modules depend on it, or maybe the package provides an assortment of otherwise unrelated functionality in its modules. In other words, the package name may describe something that the module functionality is only *applicable* to, or it may just be a catchy name. Being able to leave out this not-quite-relevant piece of information would make package-distributed code more conceptually streamlined, easier to quote out of context in e.g. papers, etc. Haskell is really a beautiful language - it's very dense and I think it is one of its great advantages that it allows the programmer to eliminate from code almost all save that which is absolutely relevant to its functionality - this proposal would take the language further in that direction. There is a strong tradition in science to put things in taxonomies, in static hierarchies, and people have tried to do this with collections of code libraries too, perhaps in imitation of scientists. One thing to note however is that the things from the natural world such as the genes of biological organisms change a lot more slowly than man-made code does. Science is different from engineering. A related reason that language designers may be drawn to requiring users to participate in universal classifications is that doing so projects an artificial aura of stability and organization onto the evolving code situation. But these designers, in shading themselves from progress, also stifle it. They create a central administrative hoop which couples all packages and impacts the scalability of the collective development effort. What I'm proposing would be a big departure from the practice of languages like Perl and Java that demand such a global module hierarchy. I've been told that the Haskell community is trying to make it so that two packages can have modules of the same name, as long as they aren't imported in the same compilation unit. My proposal would go further by (1) removing the latter restriction (2) allowing the package code to be completely ignorant of any "mount point". By the way, if you look at some aspects of operating system interfaces I think you'll see that often the choice I'm suggesting has already been made. For instance, you don't have to specify your current working directory with every command you execute, and furthermore the same command can easily be used in different working directories without modification; you can install binaries at different locations in the filesystem; you can mount filesystems at different mount-points, etc. One further thing, there have been proposals to simplify the importing of collections of modules from a certain point in the namespace, etc. I hope it is realized that they are independent from my proposal. They would not be very useful in implementing my proposal, at least I think any such solution would be far from optimal; and vice-versa. Modules and packages are quite distinct constructs, modules are needed for namespace partitioning and packages are needed to delineate administrative boundaries and sources of change. Both are necessary and both deserve special consideration in the ongoing design of Haskell. I will not be surprised if it seems strange to people that I attach such importance to what is likely seen as an unimportant detail of the language, but I do, and I hope that people will consider my suggestion. Also, I haven't said anything about implementation. I realize that this would probably require some modification to the linker. I hope I'm correct in assuming that the modifications will be relatively easy to make, provided it turns out of course that this feature is really something that people want. Frederik P.S. Thanks to John Meacham for a useful discussion. -- http://ofb.net/~frederik/

1 0

Re: [Haskell] Haskell XML RPC
by Bjorn Bringert 21 Jun '05

21 Jun '05

Johannes Waldmann wrote: > I am looking at the Haskell XML RPC library http://www.haskell.org/haxr/ > First of all, this is a very nice thing to have, and installation is > really easy, using Cabal and the packaged source archives. Hi Johannes, I'm the maintainer of HaXR, and I'll try to answer your questions as well as I can. I'm moving this thread over to the Haskell Libraries list. > *) Of course I want to dervie XmlRpcType instances automatically. > The examples suggest $(asXmlRpcStruct (reifyDecl Person)) > but I cannot get this to compile (with ghc-6.4). It seems reifyDecl is > gone, and reify has different type. I worked out this: > > helper name = asXmlRpcStruct > ( ( reify name ) >>= ( \ (TyConI dec) -> return dec )) > > $(helper ''Person) > > Does xmlrpc.cabal should contain a build-dependency > on template-haskell? (Otherwise I get linker errors.) Thanks for reporting this. I have fixed it in the development version available in the darcs repo at http://cvs.haskell.org/darcs/xmlrpc/ and made a new release today which fixes the TH support. > *) what is the recommended representation that should be created > for data T = A { .. } | B { .. } | ... i. e. discriminated unions? > Certainly some solution can be coded, but ... Hmm, I haven't had a need for that yet, so I haven't thought about it. If you come up with a good solution, we could modify THDeriveXmlRpcType to do it automatically. > *) what about the "Java side of things" - perhaps I want (need) > to interface to a Java Client. If it's Haskell-to-Haskell, > then both server and client of course can derive their > XmlRpcType instances from identical data declaraions > and everything is fine. For intergration with a different language, > what do you recommend: Start from a Haskell data declaration, > and derive a Java representation, directly or indirectly? > Or start from some language independent data declaration, > as it happens (I assume) for JAXB? Hmm, I guess it's up to you. If you come up with a good solution, or even a tool for autogenerating Haskell types and XmlRpcType instances from som language-independent description, I'll be happy to include it in HaXR. /Björn

1 0

RE: Default prefix for Cabal on Windows
by Simon Marlow 21 Jun '05

21 Jun '05

On 21 June 2005 12:42, Ross Paterson wrote: > Actually you have > > libdir = $(prefix)/lib/$(PackageId)/$(CompilerId) That's what I meant, sorry. Simon

1 0