- Libraries - Haskell.org

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

08 Mar '05

On 08 March 2005 15:39, Malcolm Wallace wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: > >>> module R( qualified module Q( f,g ) ) where >>> f = ...; g = ... >> >> 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 = ... > > I initially understood the first form to mean something different, > although admittedly the original example does not actually illustrate > it: > > module R( f,g, qualified module Q( f,g ) ) where > import qualified Q (f,g,h) > f = ...; g = ... > > That is, the subordinate items mentioned in conjunction with the > qualified export are a subset of those imported from Q, not those > defined in R. Within the subordinate clause of the export list, they > do not need further qualification since they belong unambiguously to > Q. Yes, I think we're all on the same page here. That's my understanding of the meaning of 'qualified module Q(f,g)' too, and I think it's what Simon intended. Cheers, Simon

3 2

Chestit 8-mi mart
by Iavor Diatchki 08 Mar '05

08 Mar '05

Zdraveyta Mayko, i Babo, Pisha vi na barzo da vi chestitya 8-mart! Nadyavam se da izlezeta nyakada da go otpraznuvate. Makar che e mejdunaroden den na jenata, amerikancite ne go praznuvat ne znam zashto. Az imam dosta rabota i zatova ne sam pisal otdavna, no mislya da vi zvanna po telefona prez weekenda. Minalata sedmica pravih prezentaciya na edna ideya po koyato rabotya i mislya che mina dobre. Ayde ciao zasega i shte si pogovorime po telefona. Celuvki Iavor

1 1

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

08 Mar '05

On 08 March 2005 14:36, Simon Peyton-Jones wrote: >> 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 = ... >From the last example is looks like (... items ...) are understood in the context of the top-level scope of the current module. That looks a bit strange to me, because it's different from an import declaration where the (... items ...) are entities exported by the named module. 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 = ... Cheers, Simon

2 1

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