- Libraries - Haskell.org

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 24 Jun '05

24 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

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

21 Jun '05

On 17 June 2005 17:19, Ross Paterson wrote: > On Thu, Jun 16, 2005 at 04:46:18PM +0100, Simon Marlow wrote: >>> Simon Marlow wrote: >>> >>>> Ok, so $(ProgramFiles) is determined by the registry. Taking into >>>> account comments so far, I think we have: >>>> >>>> prefix = $(ProgramFiles)\Haskell\$(PackageName)-$(Version) >>>> libdir = $(prefix)\$(Compiler)-$(Version) >>>> bindir = $(prefix)\bin >>>> >>>> these are only defaults - users & packagers are free to change >>>> them. >> >> Slight modification after Brian's comments: if the package is an >> executable, then >> >> prefix = $(ProgramFiles)\$(PackageName)-$(Version) >> >> (i.e. only libraries on under $(ProgramFiles)\Haskell). > > The default value of $(prefix) under Unix recently silently changed > from /usr/local to /usr/local/$(Compiler)-$(Version). I'm not sure > that's the right thing: it's incompatible with the FHS and with > autoconf, and puts executables in a place that's not on my path. I've fixed that, and made the changes above. However, I think $(libdir) and $(bindir) should be configurable as options to ./setup configure (weren't we going to do that at one stage?). The story is now: On Windows, prefix | is_excutable = $(ProgramFiles)\$(PackageId) | is_library = $(ProgramFiles)\Haskell\$(PackageId) libdir = $(prefix)\$(CompilerId) bindir = $(prefix)\bin On Unix, prefix = "/usr/local" libdir = $(prefix)/$(PackageId)/$(CompilerId) bindir = $(prefix)/bin This is ok for the default prefix, but not great if you want to set prefix to /opt/pkg-1.0, for example - that's why we need to be able to set libdir independently. Cheers, Simon

2 1

Re: [Haskell-cafe] CGI module almost useless
by Sven Panne 18 Jun '05

18 Jun '05

[ Moving this thread slowly to the libraries list... ] Bjorn Bringert wrote: > John Goerzen wrote: > >> My apologies if this sounds like a bit of a rant; I know people put good >> effort into this, but.... >> >> The Network.CGI module in fptools (and GHC) is not very useful. I think >> that it should be removed or re-tooled. Here are the main problems with >> it: >> >> 1. It does not permit custom generation of output headers. Thus the CGI >> script cannot do things like set cookies, manage HTTP auth, etc. >> >> 2. It does not permit generation of anything other than text/html >> documents. Many CGI scripts are used to manage other types of >> documents. Notably this makes it incompatible with serving up even >> basic things like stylesheets and JPEGs. >> >> 3. It does not permit the use of any custom design to serve up HTML, >> forcing *everything* to go through Text.Html. This makes it impossible >> to do things like serving up HTML files from disk. >> >> 4. There is documentation in the code, but it is as comments only, and >> doesn't show up in the Haddock-generated GHC library reference. (Should >> be an easy fix) >> >> 5. It does not appear to support file uploads in any sane fashion >> >> Is there a better CGI module out there somewhere that I'm missing, or >> should I just set about writing my own? > > > I wrote this module (based on the Network.CGI code) a while ago: > > http://www.dtek.chalmers.se/~d00bring/darcs/blob/lib/Network/SimpleCGI.hs > > I don't remember what it does really, but I think it solves issues 1,2,3 > and some of 4. Although (among other people) I did some hacking in this module in the remote past, I don't have the time and energy to maintain and/or extend this module anymore. It would be really great if somebody more actively working in this area could take the spec lead here and push the development via discussions here on this library list. John? Björn? A few general design thoughts: * To keep people's mind sane, backwards compatibility with the existing Network.CGI would be a very worthy goal. * Don't use any Haskell language extension available. :-) Currently the module can be used e.g. by Hugs in H98 mode, and keeping it that way would again be something very desirable. Cheers, S.

5 6

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

17 Jun '05

On 16 June 2005 16:23, Daan Leijen wrote: > Simon Marlow wrote: > >> Ok, so $(ProgramFiles) is determined by the registry. Taking into >> account comments so far, I think we have: >> >> prefix = $(ProgramFiles)\Haskell\$(PackageName)-$(Version) >> libdir = $(prefix)\$(Compiler)-$(Version) >> bindir = $(prefix)\bin >> >> these are only defaults - users & packagers are free to change them. >> >> Sound reasonable? > > Sounds fine to me. Slight modification after Brian's comments: if the package is an executable, then prefix = $(ProgramFiles)\$(PackageName)-$(Version) (i.e. only libraries on under $(ProgramFiles)\Haskell). Cheers, Simon

2 1