June 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

Trac/1417 - add pseudoterminal support to the unix library
by Bryan O'Sullivan 18 Sep '07

18 Sep '07

This is a very simple enhancement. openPseudoTerminal :: IO (Fd, Fd) getSlaveTerminalName :: Fd -> IO FilePath Here's the ticket: http://hackage.haskell.org/trac/ghc/ticket/1417 The code ought to work on Linux, Solaris, BSD, HP/UX, and Cygwin, too. I've compile-tested it on Linux, using both openpty and explicit open of /dev/ptmx. I propose a discussion period of one week. Thanks, <b

1 1

Adding IdentityT to mtl
by dons＠cse.unsw.edu.au 03 Sep '07

03 Sep '07

I wanted an IdentityT today, for extending xmonad. (The idea is to allower user-defined monad transformers, so users can plug in their own semantics easily). By default it would use IdentityT, which I note is not in mtl! Here's roughly what it would be: ----------------------------------------------------------------------------- -- | -- Module : Identity.hs -- License : BSD3-style (see LICENSE) -- module IdentityT where import Control.Monad.Trans -- -- IdentityT , a parameterisable identity monad, with an inner monad -- The user's default monad transformer -- newtype IdentityT m a = IdentityT { runIdentityT :: m a } instance (Functor m, Monad m) => Functor (IdentityT m) where fmap f = IdentityT . fmap f . runIdentityT instance (Monad m) => Monad (IdentityT m) where return = IdentityT . return m >>= k = IdentityT $ runIdentityT . k =<< runIdentityT m fail msg = IdentityT $ fail msg instance (MonadIO m) => MonadIO (IdentityT m) where liftIO = IdentityT . liftIO Any reasons why this shouldn't be in mtl? -- Don

3 5

darcs patch: s6_addr32 is undefined on darwin. Added an AC check a...
by Thomas Schilling 13 Jul '07

13 Jul '07

Fri Jun 22 18:58:52 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * s6_addr32 is undefined on darwin. Added an AC check and a definition taken from the NetBSD sources.

3 8

Proposal #1464: add dropPrefix to Data.List
by Ian Lynagh 06 Jul '07

06 Jul '07

Hi all, I seem to have a copy of this function in everything I write sooner or later, so I'd like to propose its addition to Data.List. It strips a prefix from a list and, if successful, returns the tail. I often use it with pattern guards: foo :: String -> IO () foo x | Just y <- dropPrefix "foo=" = putStrLn ("foo is " ++ show y) foo _ = putStrLn "Unknown" but you can of course achieve the same by using case etc. The definition is: dropPrefix :: Eq a => [a] -> [a] -> Maybe [a] dropPrefix [] ys = Just ys dropPrefix (x:xs) (y:ys) | x == y = dropPrefix xs ys dropPrefix _ _ = Nothing Let's try 11 July for a discussion deadline. Thanks Ian

20 26

Supported Windows versions (was: Re: unix package)
by Esa Ilari Vuokko 06 Jul '07

06 Jul '07

On 6/30/07, Ian Lynagh <igloo(a)earth.li> wrote: > On Sat, Jun 30, 2007 at 08:01:09PM +0300, Esa Ilari Vuokko wrote: > > > > Indeed. Also, as Win32 maintainer, I am unsure how far we are supporting > > old Windowses. When I tentavily asked some people about it, they thought > > we should continue to support old Windows versions. > > Our (GHC) plan is not to support Win 9x (and Me?) from 6.8 onwards, as > we don't have machines on which test it or debug problems. I don't think > the installers that we make now install a GHC that works on Win 9x, but > I could be wrong. Thanks for info! This also might mean that GHC could be made to exclusively use IO Completion Ports in Windows instead of hacks now in place. Maybe this is a good place to ask for opinions. Anyone have any or know of need to support old Windows versions? I am also curious if someone still writes software for pre-Windows 2000 NTs, as there's some nice API functions in Windows 2000. Thanks, Esa

3 4

unix package
by Ian Lynagh 01 Jul '07

01 Jul '07

Hi all, Currently the unix package is a mishmash of different solutions to the portability problem. Here are all the ones I've found, along with what I think the best action would be. If this sounds reasonable then I'll start making patches and proposals as appropriate. (for POSIX/SUS, see http://www.opengroup.org/onlinepubs/009695399/) 1) Values outside of the scope of the package, conditionally available: * System.Posix.Signals.Exts.* Propose: Moving modules into a new package, unix-exts perhaps. 2) Things that fall back to probably-reasonable alternatives: * unsetEnv, setEnv * PATH_MAX Propose: Leave as they are. 3) Things falling back to functionality which can cause problems: * The Haskell usleep uses the C usleep (marked Obsolescent) if nanosleep (a Timer extension) isn't available. C's usleep interacts badly with GHC's threaded RTS. Propose: Leave as it is. 4) Things that raise errors at runtime if they are not available, but there is something we could fall back to: * getGroupEntryForID (getgrgid_r, thread-safe extension) * getGroupEntryForName (getgrnam_r, thread-safe extension) Propose: Write fallback code. 5) Things that raise errors at runtime if they are not available, but as far as I can see are required to be available anyway: * _PC_* in System/Posix/Files.hsc * getUserEntryForID (getpwuid) * getUserEntryForName (getpwnam) * grBufSize (sysconf, _SC_GETGR_R_SIZE_MAX) * pwBufSize (sysconf, _SC_GETPW_R_SIZE_MAX) * sysconfWithDefault (sysconf) Propose: Change to using them unconditionally and see if any platforms break. 6) Things depending on optional functionality, conditionally available: * setSymbolicLinkOwnerAndGroup depends on lchown, an XSI extension http://www.opengroup.org/onlinepubs/009695399/functions/lchown.html * RLIMIT_AS (ResourceTotalMemory), RLIM_SAVED_MAX, RLIM_SAVED_CUR (all of the rlimit stuff actually appears to be an XSI extension). Propose: Move to unix-xsi package. 7) Things that raise errors at runtime if they are not available: * getAllGroupEntries (getgrent, XSI extension) * getAllUserEntries (getpwent, setpwent, endpwent, XSI extensions) * Various in DynamicLinker.Prim Propose: Move to unix-xsi package. (for both 6 and 7, an alternative would be to just make them unconditionally used in the unix package; I'm not sure what platforms, if any, this would break on). 8) Things that are implemented only for certain compilers: * forkProcess (GHC-only) Propose: Write implementations for other compilers/interpreters. Thanks Ian

8 9

apfelmus' interface degustation - System.FilePath.Find
by apfelmus 01 Jul '07

01 Jul '07

Chers amis of functionaλ cooking, aujourd'hui, le maître de cuisine is going to criticize System.FilePath.Find http://darcs.serpentine.com/filemanip/dist/doc/html/ /FileManip/System-FilePath-Find.html Is it seasoned too much with Curry and Monads? Pure or diluée with side effects? Apfelmus will tell you! And like every serious cooking critic, le maître thinks no end of himself so he can judge the haddock without eating the compiled meal. Who did not yet have to scan the file buffet for data of his gusto? This is what System.FilePath.Find helps you to do. It basically offers a function find :: RecursionPredicate -> FilterPredicate -> FilePath -> IO [FilePath] to lazily traverse a directory tree filtering out files that do not match the FilterPredicate. The RecursionPredicate decides whether to recurse into or a sub-directory or not (it could be mentioned explicitly that the predicate is only invoked on directories). A variant of find includes user-defined error handling. How to define predicates? Mon dieu! They are to be obtained from a monad FindClause a type FilterPredicate = FindClause Bool which offers operations like extension :: FindClause FilePath (==?) :: Eq a => FindClause a -> a -> FindClause Bool (||?) = liftM2 (||) One example predicate would be (extension ==? ".hs") ||? (extension ==? ".lhs") Cette soupe is much too monadic! In particular, we have the isomorphism (FileInfo -> a) ≅ FindClause a witnessed by the function pair (f,g) = ((`liftM` fileInfo), evalClause) Of course, the encapsulation was made to allow a formulation like extension ==? ".hs" which does not mention the FileInfo parameter. But alas, this can also be achieved more naturally by appealing to the instance Control.Applicative ((->) a) Abstracting the concrete representation away into FindClause hinders reuse of already existing functionality from System.FilePath, although the name "extension" is arguably more succinct than "takeExtension". The monad could make sense if the predicate might involve not only the file status but also looking inside the file. Returning all files with a certain magic number would be such a use case but System.FilePath.Find currently does not offer zis possibilité. Un autre point is that the library offers a function fold that is almost a foldl' over all files in a directory tree, but not quite: here, the fold goes over FileInfos but the list is a simple list of FilePaths. One has to foldM over the latter and get the file infos again to achieve the same effect. Le maître de cuisine thinks that these quirks stem from the fact that the file system lacks a purely functional design. The observation is that given persistence, reading does not need to be monadic. In other words, directory tree traversal might well return a list of files data File = File { contents :: String, status :: FileStatus } with contents and status. More generally, the traversal could be a side-effect-free traversal of a pure data structure. Of course, a purely functional file system needs further research, also due to performance requirements. Another direction of généralisation is that XML data is in principle similar to a file system. Shouldn't both have a common traversal interface? Last but not least, every modern cooking critic includes a Rating: λλλ Le maître awards three λ since the library uses a monad where none should be, but acknowledges that this was for the ability to formulate queries without plumbing the FileInfo-parameter everywhere. Bon appetit, apfelmus

2 3

Data.Map.mapKeys documentation differs from the actual behavior
by Andriy Palamarchuk 30 Jun '07

30 Jun '07

I'm currently improving documentation for Data.Map. mapKeys documentation says: "The size of the result may be smaller if f maps two or more distinct keys to the same new key. In this case the value at the smallest of these keys is retained." However the implementation retains the value of the *largest* key: Prelude Data.Map> let map = fromList [(1,"b"), (2,"a"), (3,"d"), (4,"c")] Prelude Data.Map> mapKeys (\ _ -> 1) map {1:="c"} Prelude Data.Map> mapKeys (\ _ -> 3) map {3:="c"} See http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Map.html#v%… Should I fix the documentation to confirm to the actual function behavior? Thanks, Andriy ____________________________________________________________________________________Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. http://tv.yahoo.com/

2 1

Re: Patch - Control.Monad.Reader documentation
by Andriy Palamarchuk 28 Jun '07

28 Jun '07

Ian, thank you for the review. I fixed the problem and attached the patch to the ticket. The deadline is up and it's ready for commit. Thanks, Andriy ----- Original Message ---- > From: Ian Lynagh <igloo(a)earth.li> > > On Mon, Jun 04, 2007 at 09:10:47PM -0700, Andriy Palamarchuk wrote: > > > > See the ticket for details: > > http://hackage.haskell.org/trac/ghc/ticket/1410 > > Just a small point: > > It would be nice if the "runReader :: r -> a" was indented 4 spaces. > > > Thanks > Ian ____________________________________________________________________________________ Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow

2 1