- Libraries - Haskell.org

Re: Could iteratee depend on mtl instead of transformers?
by John Lato 19 Nov '09

19 Nov '09

> Date: Tue, 17 Nov 2009 11:59:56 +0100 (CET) > From: Henning Thielemann <lemming(a)henning-thielemann.de> > > On Tue, 17 Nov 2009, Valery V. Vorotyntsev wrote: > >> Thus, the question is: are there any transformers-specific features >> iteratee package needs, or can it just go with mtl? > > The question is, whether Iteratee needs functions of MTL that transformers > does not provide? 'Transformers' is the more basic package, entirely > Haskell 98, thus should be prefered. It is however sad, that Transformers > cannot easily be used with GHCi in parallel with MTL installed. I was > always against that ... Renaming Control.Monad.Trans and > Control.Monad.Identity to something else would solve the conflict. I'm > also not happy, that you have to choose between monads-fd and monads-tf. I > think it would be better to be able to have both type class approaches. Iteratee does not need any MTL functions that transformers does not provide. It does the following: 1) implement instances of MonadTrans and MonadIO 2) uses lift and liftIO (polymorphically) There's no technical reason iteratee couldn't use mtl, and as Erik mentions, if you change the dependency it works just fine. For myself, I can be swayed by user demand, although I'd like to see the outcome of this discussion before committing to any changes. In all honesty, I never thought iteratee would generate enough interest for this to matter. It's not a particularly popular package. Cheers, John

2 1

iteratee (was: Could iteratee depend on mtl instead of transformers?)
by Valery V. Vorotyntsev 18 Nov '09

18 Nov '09

>> Valery V. Vorotyntsev wrote: >> >>> Thus, the question is: are there any transformers-specific features >>> iteratee package needs, or can it just go with mtl? > Henning Thielemann wrote: > >> The question is, whether Iteratee needs functions of MTL that transformers >> does not provide? 'Transformers' is the more basic package, entirely >> Haskell 98, thus should be prefered. It is however sad, that Transformers >> cannot easily be used with GHCi in parallel with MTL installed. I was >> always against that ... Renaming Control.Monad.Trans and >> Control.Monad.Identity to something else would solve the conflict. I'm >> also not happy, that you have to choose between monads-fd and monads-tf. I >> think it would be better to be able to have both type class approaches. John Lato wrote: > Iteratee does not need any MTL functions that transformers does not > provide. It does the following: > > 1) implement instances of MonadTrans and MonadIO > 2) uses lift and liftIO (polymorphically) > > There's no technical reason iteratee couldn't use mtl, and as Erik > mentions, if you change the dependency it works just fine. For > myself, I can be swayed by user demand, although I'd like to see the > outcome of this discussion before committing to any changes. I for one have no demand any more. I'm doing fine with the following lines in module: {-# LANGUAGE PackageImports #-} -- ... import "transformers" Control.Monad.Trans > In all honesty, I never thought iteratee would generate enough > interest for this to matter. It's not a particularly popular > package. I thought it was. :) http://comonad.com/reader/2009/iteratees-parsec-and-monoid/ http://therning.org/magnus/archives/735 http://stackoverflow.com/questions/1319705 http://www.johantibell.com/Left_fold_enumerators.pdf -- vvv

1 0

Re: [patch] #562: cabal-install update fails going through a HTTP proxy
by Valery V. Vorotyntsev 16 Nov '09

16 Nov '09

> Valery V. Vorotyntsev wrote: >> Could you please notify me, if you make any commits tomorrow in day time? >> >> git port is not accessible for me in working hours: the proxied LAN allows >> outbound connection to 80 and 443 ports only. But when I know there are >> new commits, I'll establish GPRS connection and download 'em. Sigbjorn Finne wrote: > Certainly, but no immediate plans to do so -- you can see repo updates via > http://code.galois.com/ > (and subscribe to feeds to be notified that way.) Oh, I didn't know about these feeds. Thanks! > It'd be nice if code.galois allowed clone/pulls via http.. It would be, yes. Only few sites seem to care. I start to wonder, whether proxied [office] LANs are so rare nowadays? :) -- vvv

1 0

Re: Proposal: System.FilePath: current directory should be ".", not ""
by wren ng thornton 16 Nov '09

16 Nov '09

Ben Moseley wrote: > Duncan Coutts wrote: >> My intuition with file paths in Cabal, is that this distinction would >> catch more bugs. Ideally cabal's building code would be independent of >> the current directory, but the fact that relative paths get >> automagically completed to being relative to the current directory means >> that it's very easy to break this property. > > [...] > >> There are various other distinctions one could try to make, the question >> becomes which type distinctions are useful and when does it just become >> too much. > > I think this is a very important point. It's definitely a balancing > act. I have > ondered whether even capturing Abs/Rel was overkill, but my current > feeling > (not yet based on much real-world experience) is that it is worth it. Having done a lot of system administration and metaprogramming of system administration, I can certainly say that making the relative/absolute distinction is helpful for tracking down bugs. From the same set of experience I'd say that Duncan's incomplete/complete distinction would be even more helpful. With a lot of sysadmin metaprogramming (which includes package installers) what people are really working on is grafting different trees together. It's important to distinguish which paths/trees are being created and don't yet refer to an actual or potential file on the disk, from those paths/trees which refer to actual/potential files on the disk. To think about why this distinction is helpful, consider where all we may want to attach the paths/trees we're creating. The two obvious places are / and . but there are other options too. Most programs support some notion of a $PATH variable or allow flags to specify the target directory for reading or writing. With the complete/incomplete distinction we distinguish names which aren't yet grounded from names that refer to files, regardless of where they're mounted. With the relative/absolute distinction we don't know when a path is finished being constructed, and we also have no real vocabulary for expressing paths relative from some point other than the current directory. Most sysadmins don't seem to realize they're doing tree grafting when they mess with this stuff, so I can see why it might seem foreign, but viewing it that way really does help clean code up and find bugs. Tree grafting also forms a monad, which could be helpful for some folks. -- Live well, ~wren

3 2

Re: #562: cabal-install update fails going through a HTTP proxy
by Valery V. Vorotyntsev 16 Nov '09

16 Nov '09

On Mon, Nov 16, 2009 at 3:26 PM, Sigbjorn Finne <sigbjorn.finne(a)gmail.com> wrote: > Thanks - that's good, now we know :) I suspect tempering the notion of > close and doing > a socket shutdown is the way forward here. I'll see if I can play with this > some tonight. Good luck with that! :) -- vvv

1 0

Re: Advance warning to package authors of breakage
by Duncan Coutts 16 Nov '09

16 Nov '09

On Mon, 2009-11-16 at 12:28 +0100, Mikhail Glushenkov wrote: > Hi, > > On Mon, Nov 16, 2009 at 1:47 AM, Duncan Coutts > <duncan.coutts(a)googlemail.com> wrote: > > > > These packages all use "build-depends: base >= 3 && < 5" (except for > > ghc-core which cheekily uses "build-depends: base < 10" --- a practise > > we will ban if it becomes any more popular). > > I have one question. It looks like the recommended way to solve the > problem is to use something like: > > Flag separateSYB > Description: Data.Generics available in separate package. > > [...] > if flag(separateSYB) > build-Depends: base >= 3 && < 4 > else > build-Depends: base >= 4 && < 5, syb > > When the user types 'cabal install pointful' (without providing > -fseparateSYB), which version of base will be the executable built > against? It prefers the default value of the flag. If that's impossible then it tries with the non-default flag value. When you do not specify a default flag value, the default is True. So as you've written it, in the absence of any constraints it'll pick the separateSYB=True configuration, which as you've written it, will *not* use the separate syb package. I think you intended to write it the other way around. Duncan

1 0

Fwd: Advance warning to package authors of breakage
by Mikhail Glushenkov 16 Nov '09

16 Nov '09

Hi, On Mon, Nov 16, 2009 at 1:47 AM, Duncan Coutts <duncan.coutts(a)googlemail.com> wrote: > > These packages all use "build-depends: base >= 3 && < 5" (except for > ghc-core which cheekily uses "build-depends: base < 10" --- a practise > we will ban if it becomes any more popular). I have one question. It looks like the recommended way to solve the problem is to use something like: Flag separateSYB Description: Data.Generics available in separate package. [...] if flag(separateSYB) build-Depends: base >= 3 && < 4 else build-Depends: base >= 4 && < 5, syb When the user types 'cabal install pointful' (without providing -fseparateSYB), which version of base will be the executable built against? -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

1 0

Re: [patch] #562: cabal-install update fails going through a HTTP proxy
by Valery V. Vorotyntsev 16 Nov '09

16 Nov '09

On Sun, Nov 15, 2009 at 12:10 AM, Sigbjorn Finne <sigbjorn.finne(a)gmail.com> wrote: > > I've got a tentative fix in for this, not disabling closing altogether (that > wouldn't be compliant with Connection:close handling), but delaying > it until EOF is reached...at least that's the intent. It may not be lazy > enough, but I'm unable to verify either way right now. > > If anyone's interested in testing, the repo contains the changes made -- > > git://code.galois.com/HTTPbis.git/ Thanks, Sigbjorn! I'll test it this Monday (by running `cabal update' with new HTTP). -- vvv

1 1

Proposal: System.FilePath: current directory should be ".", not ""
by Simon Marlow 15 Nov '09

15 Nov '09

See http://hackage.haskell.org/trac/ghc/ticket/2034 to which I have attached a fairly simple patch. All the tests pass. The main change is that splitFileName "foo" = (".", "foo") and takeDirectory "foo" = "." and "." </> x = x Discussion period: 2 weeks (5 October) Cheers, Simon

12 18

Re: Data.Map/Data.IntMap additional features
by Louis Wasserman 12 Nov '09

12 Nov '09

> > but if it were a choice between findMax and > extractWithKey with some Applicative and Monoid and whatever else > magic, I'd use findMax every time :) I'd be wary of putting anything > difficult to describe in a default interface for a basic data type. > Okay, some restatement required here: I'm suggesting this method *only* for Data.Map and Data.IntMap -- not for anything more common -- and I'm not by any means suggesting that I'd use this in every case over findMin, but merely using findMin as an example application. I *do* think it's okay for a commonly used module to have some advanced methods for advanced users. > And of course creating, inserting, updating, and deleting. Rarely key > and value mapping. Any interface that provides those 9 functions will > satisfy all needs I can think of. If they can all be implemented with > extractWithKey, then great, put that in the class interface and define > the rest with defaulting methods. > Quite honestly, I use key and value mapping all the time, in most applications I need maps for, and extractWithKey generalizes (and makes more efficient) several applications use regularly. Here's one more example of an application that can't be done nicely or efficiently with application of the currently existing methods: extractMinPair :: Map k1 (Map k2 v) -> Maybe (((k1, k2), v), Map k1 (Map k2 v)) extractMinPair m = do ((k1, m1), m') <- minViewWithKey m ((k2, v), m1') <- minViewWithKey m1 return (((k1, k2), v), if null m1' then m' else insert k1 m1' m) (In particular, this is the extractMin implementation from the generalized trie on keys of type (k1, k2), which motivated the method in the first place.) Note that in most cases, we'll need to insert m1' back into m, which is really ugly, and definitely destroys the nicer recursive properties that I'm looking for. Rather, if I can extract information and modify a value from the map with a single use of extractWithKey, extractMinPair m = getFirst $ extractWithKey (\ k1 m1 -> fmap (\ ((k2, v), m1') -> (((k1, k2), v), guardNull m1')) (minViewWithKey m1)) m where guardNull m = if null m then Nothing else Just m In the list of methods you named as particularly critical, you talked about creating, inserting, updating, and deleting; you actually didn't mention looking up values, which I assume you meant to -- since what's the point of the map if you can't look up any values? extractWithKey is useful when I want to look up a value, and edit it, at the same time, without an exra O(log n) pass, and it specifically and elegantly takes care of the case where we want to simultaneously look up and edit the minimum or maximum value of a map. Louis Wasserman wasserman.louis(a)gmail.com http://profiles.google.com/wasserman.louis

2 1