September 2007 - Libraries

There are too many error handling conventions used in library code!
by dons＠cse.unsw.edu.au 13 Aug '11

13 Aug '11

This article on the 8 different error handling strategies various common Haskell libs use: http://www.randomhacks.net/articles/2007/03/10/haskell-8-ways-to-report-err… got me thinking: we need to standardise/recommend a small set of methods for library error handling. The lack of consistent error reporting between libs results in verbose code, as we're not able to use a single error handling technique when gluing together code from different libs (i.e. we can't just use Maybe or Either/ErrorT). (It's always nice when you *can* use, say, a Maybe monad to glue code from a number of sources, but eventually you reach code with a different error system, and the Maybe monad breaks down). So, some questions I think we can tackle: * can we identify error handling strategies from the list that should not be used anymore? (throwDyn?) * can we move some of the outlying libraries to a more consistent error framework? * do we need more support for gluing together our different error systems? (it should be easier to glue code using , say, Maybe/Either). * what role does MonadError play here, as a generic error handler? * can we make precise recommendations about which error strategies to use? -- Don

11 16

Data.Map, Data.IntMap documentation
by Andriy Palamarchuk 19 Mar '08

19 Mar '08

Improved, fixed documentation for Data.Map, Data.IntMap. Moved time complexity Big-O values to the end of function descriptions. Added examples. For the initial review I submitted only changes for Data.Map. I'll update IntMap for the final review. Deadline - August 27 (two weeks). Ticket: http://hackage.haskell.org/trac/ghc/ticket/1611 Haddock output: http://hackage.haskell.org/trac/ghc/attachment/ticket/1611/Data-Map.html?fo… The module source and diff are also attached to the ticket. Andriy ____________________________________________________________________________________ Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/

17 50

Proposal: Add &&& and *** to Data.Tuple
by Josef Svenningsson 23 Oct '07

23 Oct '07

Hi all, It is becoming increasingly popular to import Control.Arrow just to get access to the functions &&& and *** specialized to the function arrow. I propose to add the specialized version of these two functions to Data.Tuple which is more logical thing to import if you wish to have functions operating on tuples. I have chosen the same fixities for these operators as in Control.Arrow. I have deliberately chosen not to include any tests. These functions are so simple that eye-balling them beats any other method of verification, at least in my opinion. Some suggestions for better documentation of &&& would be very welcome. Proposal period: 2 weeks. Deadline October 1st. I haven't been able to create a ticket for this proposal. I'm unsure what the problem is, maybe trac and Firefox doesn't work so well together. No matter what I've tried (logging as both myself and as guest) trac tells me that I don't have the permission to create a ticket whenever I submit it. If someone would be willing to create a ticket for this proposal I would be grateful. Cheers, /Josef

18 44

Fwd: Suitable new name for Dimensional library
by Björn Buckwalter 09 Oct '07

09 Oct '07

On 9/28/07, Henning Thielemann <lemming(a)henning-thielemann.de> wrote: > > On Thu, 27 Sep 2007, Björn Buckwalter wrote: > > > Secondly, I feel that "Dimensional" is to vague and ambiguous, in > > particular it could just as well refer to dimensions in the linear > > algebra sense as physical dimensions. I'd like a more specific and > > perhaps less pretentious name for the library. This is where I would > > appreciate some feedback as to what would be appropriate. Some > > suggestions are: > > > > - Numeric.Units > > - Numeric.PhysicalUnits > > - Numeric.PhysicalDimensions > > - Numeric.SI > > - Numeric.SIUnits > > - Numeric.Units.Static > > It's certainly a good idea to distinguish between static and dynamic > implementations. Incidentally, my implementation of numbers with units > uses dynamic unit checking. It is also implemented in a generic way for > any unit system, but has a specialisation for SI units. Currently it does > not adhere to standard top-level module names (which are these and why?) > but this could be changed. >From the wiki[1] it appears there is no standard, only three proposals (which all have 'Numeric' at the top-level). [1] http://www.haskell.org/haskellwiki/Applications_and_libraries#Guidelines_fo… > I use: > > Number/Physical.hs > Number/Physical/Read.hs > Number/Physical/Show.hs > Number/Physical/Unit.hs > Number/Physical/UnitDatabase.hs > Number/SI.hs > Number/SI/Unit.hs > > To be compatible with your library, the module names should contain some > hint to their dynamic nature. And conversely by this argument my module names should contain some hint to their static nature, under the assumption that you (or somewhen else) will eventually move a "dynamic" unit library to the 'Numeric' namespace. A suitable namespace would be 'Numeric.Units.Static'. Taken further though, if someone develops another "static" unit library where should they put it? An arbitrarily complex tree of namespaces could be built trying to distinguish libraries to anticipate future clashes. This leads me to wonder -- is it better for a library to have a more or less arbitrary differentiating name rather than a descriptive name? Examples are 'Text.ParserCombinators.Parsec', 'Text.Parsers.Frisby'. >From their names it's not obvious what distinguishes them from other parsers in the same namespace but at least the tree is fairly flat and hopefully narrowed down enough to permit investigating each alternative. In the units case I imagine 'Numeric.Units.SomethingArbitrary' would be appropriate. As counterexamples I also notice there are cases where a library has a unique name but still a very generic namespace, e.g. Takusen which uses 'Database', Haifa with among other 'Text.XML.Serializer'. Then there is HAppS which at a cursory glance appears to use 'HAppS' as its top-level namespace, which has the obvious advantage of not having to worry about other libraries in the same namespace while also keeping the rather broad HAppS code collected in one place. Comments on what is appropriate (for my case, not necessarily for all cases)? I'm still leaning towards 'Numeric.Units' or something thereunder. Thanks, Bjorn

2 2

Hackage and GHC 6.8
by Don Stewart 08 Oct '07

08 Oct '07

Neil Davies wrote: > Given that GHC 6.8 is just around the corner and, given how it has > re-organised the libraries so that the dependencies in many (most/all) > the packages in the hackage DB are now not correct. > > Is there a plan of how to get hackage DB up to speed with GHC 6.8 ? Ian, GHC HQ, can you elaborate on what the plan is on fixing the hackage libraries for ghc 6.8 -- should everyone be springing into action to update .cabal files and fix api changes? -- Don

5 6

Proposal: Fix abstract unix sockets (#1699)
by Lennart Kolmodin 05 Oct '07

05 Oct '07

Hi, I've added proposal #1699 to fix abstract unix sockets on Linux for the network library. The patch is so far only tested under Linux (2.6.15), but should not affect Windows or other OSes which does not have AUS. >From the darcs patch comment: Abstract Unix Socket paths begin with a zero, are not zero terminated and needs accurate socklen calculation. Thus this patch, on linux: * Calculates the exact size of sockaddr. * Pokes sockaddr correctly wrt aus. Also, due to much more socklen usage: * Switch Network.Socket to use CSockLen instead of CInt. * Cleanup surrounding code. Cheers, Lennart Kolmodin -- "The only thing that interferes with my learning is my education." -- Albert Einstein

2 2

Suitable new name for Dimensional library
by Björn Buckwalter 29 Sep '07

29 Sep '07

All, For quite a while[1] now I've been wanting to change the name of my Dimensional library[2]. The library blurb is: "Dimensional is a library providing data types for performing arithmetic with physical quantities and units. Information about the physical dimensions of the quantities/units is embedded in their types and the validity of operations is verified by the type checker at compile time. The boxing and unboxing of numerical values as quantities is done by multiplication and division with units. The library is designed to, as far as is practical, enforce/encourage best practices of unit usage." There are two primary reasons I have been wanting to change the name. Firstly I wanted to move the library from the arbitrary 'Buckwalter.Dimensional' namespace into the standard hierarchy. At Don's suggestion (patch) the library has been moved to the 'Numeric.Dimensional' namespace and if no-one objects it will remain under 'Numeric'. Secondly, I feel that "Dimensional" is to vague and ambiguous, in particular it could just as well refer to dimensions in the linear algebra sense as physical dimensions. I'd like a more specific and perhaps less pretentious name for the library. This is where I would appreciate some feedback as to what would be appropriate. Some suggestions are: - Numeric.Units - Numeric.PhysicalUnits - Numeric.PhysicalDimensions - Numeric.SI - Numeric.SIUnits - Numeric.Units.Static (While the library isn't limited to SI units or even the SI dimensions they are the main focus and default export.) Personally I like 'Numeric.Units' (it emphasizes that units are the key to interacting with the library) but I'd love to get a second, third and fourth opinion! Thanks, Bjorn Buckwalter [1] http://www.haskell.org/pipermail/haskell/2006-December/018993.html [2] http://dimensional.googlecode.com

4 3

Re: Suitable new name for Dimensional library
by Björn Buckwalter 28 Sep '07

28 Sep '07

On 9/28/07, Isaac Dupree <isaacdupree(a)charter.net> wrote: > >> I don't remember, is it possible for modules that import yours, to > >> define arbitrary new units of their own? > > > > Yes, e.g. "nauticalMile = prefix 1.852 (kilo meter)". > > I mean a new dimension, like "prettyness" measured in "Emilys", for example. Ah, yes. The 'Extensible' module makes it relatively easy to add a new base dimension on top of the seven SI base dimensions. The 'CGS' module demonstrates how to replace the SI with another system altogether. Both of these should be considered experimental, however. -Bjorn

1 0

Re: Suitable new name for Dimensional library
by Isaac Dupree 28 Sep '07

28 Sep '07

Björn Buckwalter wrote: > On 9/28/07, Isaac Dupree <isaacdupree(a)charter.net> wrote: >> Björn Buckwalter wrote: >>> There are two primary reasons I have been wanting to change the name. >>> >>> Firstly I wanted to move the library from the arbitrary >>> 'Buckwalter.Dimensional' namespace into the standard hierarchy. At >>> Don's suggestion (patch) the library has been moved to the >>> 'Numeric.Dimensional' namespace and if no-one objects it will remain >>> under 'Numeric'. >> seems fine to me >> >>> Secondly, I feel that "Dimensional" is to vague and ambiguous, in >>> particular it could just as well refer to dimensions in the linear >>> algebra sense as physical dimensions. >> They are somewhat related. But indeed your library only deals with >> specific named dimensions... >> >>> I'd like a more specific and >>> perhaps less pretentious name for the library. This is where I would >>> appreciate some feedback as to what would be appropriate. Some >>> suggestions are: >>> >>> - Numeric.Units >>> - Numeric.PhysicalUnits >>> - Numeric.PhysicalDimensions >>> - Numeric.SI >>> - Numeric.SIUnits >>> - Numeric.Units.Static >>> >>> (While the library isn't limited to SI units or even the SI dimensions >>> they are the main focus and default export.) >>> >>> Personally I like 'Numeric.Units' (it emphasizes that units are the >>> key to interacting with the library) but I'd love to get a second, >>> third and fourth opinion! >> perhaps: Numeric.Units.SI exports the SI units... but then it's not >> obvious what to do with the other exports (Dimensionless etc.) - >> Numeric.Units I guess? > > Normal usage would be: > > import qualified Prelude > import Numeric.Units.Prelude > import Numeric.Units.NonSI (poundMass) > > The Prelude replacement includes all SI units. > >> I don't remember, is it possible for modules that import yours, to >> define arbitrary new units of their own? > > Yes, e.g. "nauticalMile = prefix 1.852 (kilo meter)". I mean a new dimension, like "prettyness" measured in "Emilys", for example. > >> Is the module's API good enough (or unlikely enough to be duplicated or >> significantly changed) to use a clean name -- or are we not supposed to >> be worrying about that because of namespace separation by package? I'm >> a little confused here, but I think it doesn't matter if our >> infrastructure is good enough? > > I don't foresee any changes to the API. I'm rather happy with it > though I haven't gotten much feedback from others. The library isn't > haskell98 though, indeed it is GHC6.6+ only. Not sure whether that > should be a concern. > > I'd also like to think all this doesn't matter if our infrastructure > is good enough, but are we there yet? I don't know. > Thanks, > Bjorn >

1 0

Survery of Setup.hs with Cabal-1.2
by Duncan Coutts 27 Sep '07

27 Sep '07

This is a survey of the problems in updating to Cabal-1.2. (This is independent of the problems in updating to GHC-6.8, though of course many people will encounter both at the same time.) I've compiled The Setup.(l)hs scripts of all 248 packages (394 package-version pairs) on hackage with the new Cabal-1.2 library. Of those, the Setup scripts from 20 packages fail to compile (there are 31 package-version pairs). 4 more compile but with warnings. I've categorised the failures by their cause & remedy: ------------------------------ There are several packages which currently use custom code in the Setup.hs script that can now be replaced entirely by using the new configurations feature. They are doing things like picking the dependencies based on the ghc version or the operating system. This is exactly what configurations are for. These packages can then use the "build-type: Simple" and the trivial Setup.hs script. cabalmdvrpm-0.0.1 cabalrpmdeps-0.0.3 HDBC-odbc-1.0.1.0 hslogger-1.0.2 MissingH-0.18.2 tar-0.1 unix-compat-0.1 hsql-odbc-1.7 (actually does compile but with a warning) ------------------------------ A similar case is using code to run an external program to discover the correct build flags for a package. In general this still needs to use custom code but in the common case of using the "pkg-config" program we can take advantage of the pkg-config support in Cabal-1.2 and again get away with using the build-type: Simple and the trivial Setup.hs script. hsql-sqlite3-1.7 ------------------------------ An API change in the "UserHook" hooks interface that affected many Setup scripts was that the result type was changed from IO ExitCode to just IO (). Then instead of returning codes all over the place (which were not being consistently checked) we now use IO exceptions instead. So Setup scripts which used to return ExitSuccess can now return () and ExitFailure n can be replaced by exitWith (ExitFailure n). debian-1.0 hburg-1.0 YamlReference-0.1 to 0.5 ------------------------------ There are a number of packages where the Setup script makes extensive use of the internal API of Cabal's default build system. I'll mention each one briefly: fenfire-0.1: needs updating to use new PreProcessor abstraction. Can drop the local def of c2hs pre-processor as this hack is no longer required in the minimum version of c2hs that Cabal supports (and it probably would no longer work anyway). lhs2tex-1.12: requires significant work. It makes use of the Program abstraction and system for managing installation dirs both of which have changed significantly. hsql-mysql-1.7, hsql-postgresql-1.7: requires significant work. can be simplified by using the cabal api effectively and using configurations. These both call external config programs to find the right build flags. I posted an update to hsql-mysql-1.7 the other day as an example. alex-2.1.0, happy-1.16: requires significant work (though already done in darcs versions). Again these used the internal Program abstraction which changed significantly. yi-0.2, hint-0.1: These both try to find ghc's libdir. The both could be significantly simplified by doing things in the 'proper' way which is to use the HookedBuildInfo stuff rather than writing little .ghc-libdir files. xmobar-0.3.1-0.7: The Setup.hs for this package completely re-implements the haddock command to customise the way docs are generated for executables. This is no longer necessary in Cabal-1.2 as it provides the features required. So the Setup.hs can be replaced with default and use build-type: Simple. ------------------------------ Packages for which Setup.hs compiles with a warning with Cabal-1.2: These three packages add a feature that was missing in Cabal-1.1.6 but is now present in Cabal-1.2. They add a --ghc-option= and --configure-option= flag to the configure command. Cabal-1.2 implements this generically for all programs that it knows about (and the programs it knows about can be extended by the Setup script). So again, these can use build-type: Simple and the trivial Setup script. cgi-3001.1.3 filepath-1.0 X11-1.2.2 One immediate cause of problems is Setup scripts importing Distribution.PreProcess, Distribution.Program which have moved under Distribution.Simple. I could add re-exports for both as I did for Distribution.Setup however both modules have changed significantly so any Script that actually uses these modules needs changing anyway, so theres no particular advantage to providing a module re-export crutch. I might make module Distribution.Simple.Utils export rawSystemVerbose again since some scripts use it. Though all those that do have other problems as well. So overall that's not too bad. Less than 10% of the hackage packages are affected by the significant internal changes in Cabal-1.2. Of those, only 9 packages need significant work to update their Setup scripts and 12 others can eliminate their custom Setup code completely using new features in Cabal-1.2. The remaining 3 need only minor changes. Duncan

1 0