- Libraries - Haskell.org

RE: [Haskell] Hierarchical module namespace extension notsufficiently flexible
by Simon Peyton-Jones 08 Mar '05

08 Mar '05

| If we're going to allow (... items ...) at all, then I suggest instead that the last example be written: | | module R( qualified module R(f,g) as Q ) where | f = ...; g = ... Sorry -- that was a typo. Thanks for spotting it S

1 0

RE: [Haskell] Hierarchical module namespace extension not sufficiently flexible
by Simon Peyton-Jones 08 Mar '05

08 Mar '05

| Well, as an author of the Hierarchical Modules addendum, and as a | compiler maintainer, I am already reasonably convinced of the utility | of this suggestion. It does significantly alter the semantics | of import/export, in a way that the original Hierarchical Modules | addendum does not, but as Iavor pointed out, this is not necessarily | a bad thing. | | What we now need is a precise definition. After that, contributions | of code to implement it would also be welcome. :-) Simon and I agree. If someone is willing to evolve a detailed design, presumably based on the current Hierarchical Modules addendum, and that design met with general consent, we'd implement it in GHC. (Provided it didn't require massive changes, which would probably form part of the design criteria.) My current design is sketched below, but I have not thought about it as long as others have. Simon Syntax: Extend the export syntax to allow, as an export item, qualified module M [( ...items... )] [as N] Examples: module P( qualified module Button ) where import GTK.This.That.Button as Button module Q( qualified module GTK.This.That.Button as Button ) where import GTK.This.That.Button module R( qualified module Q( f,g ) ) where f = ...; g = ... Semantics. The effect of an export item 'qualified module' is to expose some qualified names as well a unqualified ones. That is the only way to expose qualified names. The rules on import are just as now. For example import P -- Exposes P.Button.new, Button.new import qualified P -- Exposes P.Button.new import qualified P as MyP -- Exposes MyP.Button.new That is, the names exposed by the exporter are imported with or without an extra qualifier, depending on the form of the import.

1 0

RE: Data.Dynamic
by Simon Peyton-Jones 07 Mar '05

07 Mar '05

Library folk: does anyone consider themselves responsible for Data.Dynamic and Data.Typeable? It would help if someone would volunteer... John: This looks fine: dynTypeRep :: Dynamic -> TypeRep we'll add it. but typeRepIndex :: TypeRep -> IO Int looks stranger. It breaks the TypeRep abstraction. Would you care to argue for it? Simon | -----Original Message----- | From: libraries-bounces(a)haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of John | Meacham | Sent: 04 March 2005 07:25 | To: libraries(a)haskell.org | Subject: Re: Data.Dynamic | | Actually, could this patch be applied? | it also provides a routine to get the index of a typerep for efficient | hashing. It is in the IO monad because the index may change between | runs. | John | | | -- | John Meacham - ⑆repetae.net⑆john⑈

2 1

Hierarchical module namespace extension not sufficiently flexible
by Duncan Coutts 07 Mar '05

07 Mar '05

All, So here's the problem: we have a binding to a large foreign library (GTK) which we are trying to fit nicely into hierarchical module name space. It would live under Graphics.UI.Gtk Graphics.UI.Gtk.Button Graphics.UI.Gtk.Frame ... etc Now there are over 100 modules directly under Graphics.UI.Gtk and you don't want to have to import each one of them separately. Of course you will not use all of them in one module but you might reasonably use 20+ of them. So it'd be nice to be able to say: > import Graphics.UI.Gtk or > import qualified Graphics.UI.Gtk as Gtk But now we have a problem. These import directives import a flat namespace, or a flat namespace qualified by a single module alias (ie Gtk in the second example). But the Gtk modules are deliberatly designed to have hierarchical names. You cannot simply combine them all together into a flat namespace without falling back to the trick of prefixing each function name with the module name. So while we would like to be able for users to do this: > import Graphics.UI.Gtk > > ... Button.setLabel ... They will instead have to say: > import Graphics.UI.Gtk > > ... buttonSetLabel ... Which is one of the things that the hierarchical module namespace extension was trying to get rid of! All the other language bindings for Gtk (apart from C) use the former import and useage style. It doesn't make us look good! :-) So my question is: have I overlooked something or is this really not possible at the moment. And secondly, if it is currently not possible is there a 'nice' extension that would allow this sort of thing. (Where nice probably means Haskell98 compatible / 'doesn't' break existing programs) How about: > module Graphics.UI.Gtk ( > > module qualified Graphics.UI.Gtk.Button as Button > ... > ) where > > import Graphics.UI.Gtk.Button or equivalently(?): > module Graphics.UI.Gtk ( > > module qualified Button > ... > ) where > > import Graphics.UI.Gtk.Button as Button Duncan Ps there's a oddity I found where if you say: > module Foo ( > module Bar > ) > > import qualified Bar then module Foo exports precisely nothing. But there's no error or warning.

6 8

ANN: HAppS -- Haskell Application Server v 0.3
by S. Alexander Jacobson 04 Mar '05

04 Mar '05

HAppS is a Haskell library for building Internet applications, featuring: * HAppS.ACID: Guarantee application integrity in the face of unplanned outages using this module's integrated write-ahead logging and checkpointing framework. * HAppS.DBMS: Do relational operations in Haskell (rather than SQL) on Haskell sets (outside the IO Monad). Define custom indices for your Haskell datatypes (e.g. geographic/geometric types). Use in combination with ACID for a robust relational DBMS customized for your application. * HAppS.Protocols: Expose your application using as an HTTP server and/or by recieving and sending SMTP. Changes since 0.2: HAppS Changes * Much cleaner interface for ACID transaction handlers * DBMS operators that look more like HaskellDB operators * SMTP send errors are exposed for use in future reliable deliver implementation * ACID callbacks disabled. Framework in place for total order on callbacks. * SideEffect queues are now algrebraic types rather than strings. * Parametrized HTTP using XML ToElement and HTTP ToMessage FromMessage and ToURI classes (you write transaction handlers in terms of Haskell types and the system takes care of exposing them for HTTP) * Parametrized HTTP response now has type (ToURL url,ToMessage msg)=>Response url message Framework takes care of automatically translating relative URLs to absolute URLs. Answers to questions a few people have asked: * Compare HAppS.DBMS with HaskellDB HaskellDB is really optimal if you want to talk to external databases. HAppS.DBMS is really good if you want to do relational operations on Haskell Sets without going to the IO monad. * Compare HAppS.ACID to STM Use STM if all your IO operations have a two-phase-commit interface. Use HAppS.ACID if your IO interfaces are not transactional. Instead HAppS.ACID gives you multi-queue, at-least-once execution of side-effects, and a total order on their callbacks. There is no rollback semantic because you can't unsend email. * Compare HAppS.Protocols.SMTP to Peter Simon's Postmaster Postmaster is trying to be a full fledged MTA. SMTP is trying simply to give you SMTP receive/send functionality in your applications. Neither yet has a queuehandler. We both hope to merge lessons learned soon. * Compare HAppS.Protocols.HTTP to Warrick Gray's Network.HTTP module Network.HTTP is more oriented towards building HTTP clients. HAppS..HTTP is more oriented towards building HTTP servers. Network.HTTP enforces a stronger separation between headers and body. HAppS..HTTP delivers a MIME message back to the app. With infrastructure to enable transparent conversion to and from application datatypes. -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com

1 0

Gtk2Hs
by David Owen 04 Mar '05

04 Mar '05

Hi all, I have recently downloaded and installed Gtk2Hs but am having problems running the sample programs. I am most interested in getting the TestEmbedMoz program working. However when I try to compile it (either using make or ghc on the command line) it says that the interface file for MozEmbed does not exist (cannot find interface file for Graphics.UI.Gtk.MozEmbed). I have tried it using both 2.4 and 2.6 of the Windows versions of Gtk+ and the corresponding Gtk2Hs packages and neither seem to provide the file. I have also built the packages from source and tried to compile but to no avail. Maybe I need to do something wlse with the MozEmbed package file (?). Mozilla 1.4 or greater is installed as needed. My second problem is running other test programs that have successfully compiled. For example the ButtonBox when I run it gives an "Entry Point Not Found" error, details: "The procedure entry point libiconv_set_relocation_prefix could not be located in the dynamic link library iconv.dll". I've tried reinstalling Gtk+ and GtkHs a few times but it hasn't helped. Any help with either problem would be appreciated. I've looked at the Gtk FAQs but didn't see any answers (unless i missed them!). regards all David

2 1

Time Library darcs Repository
by Ashley Yakeley 04 Mar '05

04 Mar '05

OK, I finally managed to get darcs to work on my ISP. Do this to get the code: darcs get "http://semantic.org/TimeLib/" Do this to get any subsequent changes: darcs pull I hope to get more implementation done this coming week. -- Ashley Yakeley, Seattle WA

2 2

Data.Dynamic
by John Meacham 04 Mar '05

04 Mar '05

Could we add a function: getTypeRep :: Dynamic -> TypeRep to Data.Dynamic? right now, there is no way to tell if two dynamics are of the same type. John -- John Meacham - ⑆repetae.net⑆john⑈

1 1

(no subject)
by Duncan Coutts 01 Mar '05

01 Mar '05

Gtk2Hs - A Haskell GUI library based on the Gtk+ GUI Toolkit. Version 0.9.7.1 is now available from: http://gtk2hs.sourceforge.net/ This release is only needed for Windows users. If you have version 0.9.7 working there is no need to upgrade. Source and binary packages are available for Windows. There are binary packages for Gtk+ 2.4.x and 2.6.x. The binary packages require GHC 6.2.2. You may wish to use Gtk+ 2.6 since it follows the Windows native look and themes whereas Gtk+ 2.4 did not. Installation on Windows is fairly straightforward. There is an installer for Gtk+ on Windows and installing Gtk2Hs just involves unzipping and running a batch file. Instructions are here: http://gtk2hs.sourceforge.net/archives/2005/02/17/installing-on-windows/ For future Gtk2Hs releases we hope to provide an MSI installer to make it even easier. Changes since 0.9.7: * build fixes for Windows * almost all modules now carry LGPL 2.1 license * a couple of extra functions are now bound Other changes and news since the last release announcement: * there is an introductory article by Kenneth Hoste in the first issue of The Monad.Reader: http://www.haskell.org/hawiki/TheMonadReader_2fIssueOne * a complete website redesign * many new screenshots: http://sourceforge.net/project/screenshots.php?group_id=49207 * packages of version 0.9.7 are available for Gentoo and FreeBSD Please report all problems to gtk2hs-users(a)lists.sourceforge.net . Contributions and feedback are also most welcome. Duncan

1 0

RE: Non-H98 crusade, contd.
by Simon Marlow 28 Feb '05

28 Feb '05

On 27 February 2005 10:47, Sven Panne wrote: > OK, let's try to summarize what seems to be the current consensus > about more or less conservative & settled extensions to Haskell98: > > a) rank 2 type signatures > b) polymorphic components for data constructors > c) pattern guards > d) data declarations with no constructors > e) constraints on typeclass methods > f) instances on type synonyms > g) relaxation of polymorphic recursion I'd also like to see at least h) exceptions up until the recent discovery of STM, I would have said concurrency too. Cheers, Simon

1 0