- Libraries - Haskell.org

Is traceIO unnecessarily specialised to the IO monad?
by Chris Seaton 25 Jan '13

25 Jan '13

I use printf-style debugging a lot, so I am always adding and removing applications of trace. There is the Debug.Trace.traceIO function that makes this easy to do in the IO monad (it just applies hPutStrLn stderr), but is that specialisation to IO unnecessary? I find myself always using this utility function: traceM :: (Monad m) => String -> m () traceM message = trace message $ return () Which can be used to implement traceIO. traceIO :: String -> IO () traceIO = traceM That way I can traceM in whatever monad I am in. It is easier to add and remove an application of trace, because I do not have to wrap it around something, and I do not have to remember the return. Of course, you are still subject to however your monad chooses to order the execution of these traces, but that is what people expect when using trace. Would traceM be a wanted addition to Debug.Trace? Regards, Chris Seaton

8 12

[PATCH] Re: HEADS UP (was Re: [commit: ghc] master: Tidy up cross-compiling (109a1e5))
by Sergei Trofimovich 25 Jan '13

25 Jan '13

On Thu, 17 Jan 2013 13:00:44 +0000 Simon Marlow <marlowsd(a)gmail.com> wrote: > Cross-compilers please take note: > > On 17/01/13 12:57, Simon Marlow wrote: > > > Before > > ------ > > > > To build a cross-compiler: > > ./configure --target=<..> > > > > To compile a foreign GHC: > > ./configure --host=<..> --target=<..> > > > > Now > > --- > > > > To build a cross-compiler: > > ./configure --target=<..> > > And set "Stage1Only=YES" in mk/build.mk > > > > To compile a foreign GHC: > > ./configure --target=<..> > > Cheers, > Simon Looks great! Tried a while ago with the following setup: * --tagret=ia64-unknown-linux-gnu * "Stage1Only=YES" * host compiler is ghc-7.6.1 (unregisterised build) to get real cross-compiler and found out the following issues: mkGmpDerivedConstants is built for target and ran on host [attached patches for it] make install fails as it 'forgets' to install proper ghc-pkg in $(${cross}-ghc --print-libdir)/bin/ But the resulting cross-compiler was able to build working hello world! -- Sergei

2 3

ANN: monad-bool 0.1
by John Wiegley 22 Jan '13

22 Jan '13

monad-bool implements a pair of Boolean monoids and monads, to support short-circuiting, value-returning computations similar to what Python and Ruby offer with their native && and || operators. For example, in Python you might see this: x = [1,2,3,0] print x[1] || x[3] -- prints "2" With this library, you can now mirror such code in Haskell: let x = [1,2,3,0] print $ (x !! 1) ||? (x !! 3) -- prints "Success 2" "Booleanness" is based on each type having an instance of the 'Control.Conditional.ToBool' type, for which only the basic types are covered (Bool, Int, Integer, Maybe a, Either a b, [a], Attempt a). If you wish to define a truth value for your own types, simply provide an instance for ToBool: instance ToBool MyType where toBool = ... The And/Or monoids use the Attempt library so that the actual type of the successful results depends on case analysis. It could be a list, a Maybe, an Either, or an exception in the IO Monad. The monad variants, AndM, AndMT, OrM and OrMT provide short-circuiting behavior in a Monad, which returns the last value returned before truth was determined. Here are two examples: Use 'onlyIf' with AndM and AndMT to guard later statements, which are only evaluated if every preceding 'onlyIf' evaluates to True. For example: foo :: AndM Int foo = do onlyIf (True == True) return 100 onlyIf (True == True) return 150 onlyIf (True == False) return 200 When run with `evalAndM foo (-1)` (where (-1) provides a default value), 'foo' returns 150. Use 'endIf' with OrM and OrMT to chain statements, which are only executed if every preceding 'endIf' evaluated to False. For example: bar :: OrM Int bar = do endIf (True == False) return 100 endIf (True == False) return 150 endIf (True == True) return 200 When run with `evalOrM bar (-1)` (where (-1) again provides a default value), 'bar' returns 150. And please, somebody let me know if this has already been done. A search for likely candidates did not turn up anything obvious in Hoogle, but as my knowledge of the whole of Hackage is minimal, I would appreciate any wiser minds that can inform me. Thank you, -- John Wiegley FP Complete Haskell tools, training and consulting http://fpcomplete.com johnw on #haskell/irc.freenode.net

2 1

Re: Haskell Platform proposal: Add case-insensitive and Haskell 98/2010 compliance
by Gregory Collins 21 Jan '13

21 Jan '13

On Mon, Jan 14, 2013 at 11:29 AM, Ben Millwood <bm380(a)srcf.net> wrote: > This is easily fixed, although may be controversial: remove the ByteString > instances. The bytestring instances are what it's most often used for! The haddocks warn about this issue. And: yes, we do want an ASCII case fold. If we didn't, we'd be using Text. I've seen an Ascii newtype proposed (so that you have to work extra hard to have the obvious semantics), but IMO nerfing this particular library to make it harder for people to make beginner unicode mistakes is silly. They'll find a way to make them anyways. One thing the haddocks could maybe do better is to have a bigger, louder, and more informative disclaimer about the issue that points users towards the "modern default": use text, and encode/decode as UTF-8. G -- Gregory Collins <greg(a)gregorycollins.net>

4 4

Re: Simple addition to Control.Arrow
by Merijn Verstraaten 18 Jan '13

18 Jan '13

> Message: 2 > Date: Thu, 17 Jan 2013 22:32:14 +0100 > From: "dag.odenhall(a)gmail.com" <dag.odenhall(a)gmail.com> > Subject: Re: Simple addition to Control.Arrow > To: Daniel D?az Casanueva <dhelta.diaz(a)gmail.com> > Cc: Haskell-Libs <libraries(a)haskell.org> > Message-ID: > <CACsGukkRF4FhvSs-o0UrLiN29AK8Ru=LjoV94euhExm05ZMD3w(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Should perhaps be noted that this exists in the lens package as "over both" > and also for up to 9-tuples as "over each". This was also said by #haskell, but it's simply not true, unless you claim (->) is the only Arrow people use. over both :: (a -> b) -> (a, a) -> (b, b) whereas my suggestion: both :: Arrow a => a b c -> a (b, b) (c, c) Anyway, judging by the response from the list there (unfortunately) doesn't seem to be that much interest. Kind regards, Merijn

1 0

Simple addition to Control.Arrow
by Merijn Verstraaten 17 Jan '13

17 Jan '13

I keep finding myself needing to apply functions to both elements in a tuple and now that I've started playing around with AFRP libraries I find myself applying arrows to both sides of tuples there too. As a result I would like to propose the following addition to Control.Arrow: both :: Arrow a => a b c -> a (b, b) (c, c) both = join (***) -- or if importing join from Control.Monad is undesirable both f = f *** f Why not just write "f *** f" I hear you ask? Because when f is not a trivial expression then you need to either bind it to a new name and use "newName *** newName" (which I personally dislike, because I'm terrible at coming up with names) or write "join (***) f" which I don't find a particularly appealing notation either. Kind regards, Merijn Verstraaten

3 2

Re: Haskell Platform proposal: Add case-insensitive and Haskell 98/2010 compliance
by Henning Thielemann 14 Jan '13

14 Jan '13

On Mon, 14 Jan 2013, Ben Millwood wrote: > In response to this, I ask you: is compatibility with the platform really a > goal for your live-sequencer? Would the live-sequencer benefit particularly > from use of the case-insensitive package? Would making the case-insensitive > package Haskell2010 enable it to work with your interpreter immediately? My answer is no, and I think it is the wrong question. My point was, that case-insensitive can easily be made both Haskell98/2010 and thus improve - the same way the "split" package improved by removing the GADT when it was added to the platform. I had actual problems when trying to do something sensible with JHC. It meant that I had to inspect and "fix" a lot of packages at once before seeing anything running. Not very encouraging when you try a different compiler. FlexibleInstances are not necessary for defining instances on Strings and if a package enters the platform it is a good opportunity to fix that. Platform packages also play a role as packages where beginners look first when they want to learn how to program real-world Haskell. > That all said, I do have my own concerns with case-insensitive. Particularly, > it provides an instance FoldCase ByteString, implicitly treating ByteStrings > as text, which I believe should be discouraged. I think it should import ByteString.Char instead of ByteString.

3 4

Proposal: refactor Arrow class
by Ross Paterson 09 Jan '13

09 Jan '13

I propose to refactor the Arrow class, so that GHC's arrow notation can be a bit more general. (The module Control.Arrow itself would remain standard Haskell.) Please comment by 12th August. In detail, the proposal is to change the Arrow class from class Category a => Arrow a where arr :: (b -> c) -> a b c first :: a b c -> a (b,d) (c,d) -- various functions made methods to allow efficient specializations by introducing a new class -- | A binary type constructor that is contravariant in its first argument, -- that is, -- -- * @'premap' id a = a@ -- -- * @'premap' (f . g) a = 'premap' g ('premap' f a)@ -- class PreArrow a where premap :: (b -> b') -> a b' c -> a b c with instances instance PreArrow (->) where premap f g = g . f instance PreArrow (Kleisli m) where premap f (Kleisli g) = Kleisli (g . f) and redefining the Arrow class as class (Category a, PreArrow a) => Arrow a where arr :: (b -> c) -> a b c arr f = premap f id first :: a b c -> a (b,d) (c,d) -- rest unchanged The proposed PreArrow class has more instances than Arrow, in particular composing a PreArrow with a Functor yields another PreArrow. The principal client for the new class would be the arrow notation, as implemented in GHC. With this class, there would be a simple rule for determining which instances are needed, based on the keywords used: * all commands ("proc" and operator arguments) need PreArrow * "do" needs Arrow * "rec" needs ArrowLoop * "case" or "if" need ArrowChoice One might object that the second argument of the PreArrow class is superfluous, and this is just a complicated Contravariant class. That is true, and in semantic terms a covariant functor would be sufficient, but Haskell's type system makes it impossible to have commonality between a Contravariant class of unary type constructors and the Arrow class used by arrow notation.

6 16

Re: Proposal: splitting the network package
by Gabriel Gonzalez 09 Jan '13

09 Jan '13

I think the best action is to contact the maintainers. I imagine that most package naming disputes can be resolved this way. Forcefully renaming packages crosses a point of no return, so we should be a little bit more hesitant to invoke that option. If we do choose to rename package, though, then I think at a minimum the policy should be that: * The package authors are unreachable * There are no suitable alternative names Also, I consider a social rating system (ala Hackage 2) the proper solution to finding the "one true" package for something, not package name space conflicts.

3 2

Re: Fwd: kqueue benchmark
by Ian Lynagh 07 Jan '13

07 Jan '13

Thanks Andi! Johan, could you review and (all being well) apply please? Thanks Ian On Sat, Jan 05, 2013 at 02:16:20PM -0500, Andreas Voellmy wrote: > Hi Ian and Simon, > > As you may know, I've been working on an update to GHC's IO manager > component that substantially improves the performance and scalability (with > cores) of this component. For example, the attached graph shows the > performance of a highly simplified web server written in Haskell vs GHC 7.7 > HEAD and vs a C web server that was written to do essentially the same > thing as my Haskell web server, minus all the Haskell overhead. With my IO > manager update, we get about 2x the performance of GHC 7.7 HEAD with 1 > core, and over 20x the performance when use lots of cores. We also come > very close to the performance of the C web server. (I can give you much > more detail on the experiment if you like - just let me know). > > Actually, this Haskell web server with the IO manager update allowed me to > push linux hard enough to find an elusive bug in the linux kernel that has > existed since Linux 2.6! After finding some weird behavior with my Haskell > web server, I wrote the C web server (the one I mentioned above) to > simulate the Haskell code's use of the kernel, but only using C. After a > few weeks of work, the kernel developers found a missing memory barrier and > committed a patch to Linux: > https://github.com/torvalds/linux/commit/128dd1759d96ad36c379240f8b9463e8ac… > . > > Bryan O'Sullivan recently reviewed my commits and has suggested that I now > ask you to pull changes into GHC. My changes required two minor commits to > the main repository and lots of commits to the base library repository. > I've posted my work on github: > > main repository: > https://github.com/AndreasVoellmy/ghc-arv/tree/parallel-iomanager-reimp-2 > (last two commits) > > and base library repository: > https://github.com/AndreasVoellmy/ghc-base-arv/tree/parallel-iomanager-reim… > (all commits following 3fb1aac) > > You may not want to review all the commits in my base library repo, but it > would be great if you could look at the two commits in the main repo, > because they add a couple hooks from the RTS to the IO manager. > > Let me know if you need any more clarification or more revisions. I'm not > sure exactly what the correct protocol is for getting these changes in, so > let me know if I need to do something like open a ticket, etc. > > Cheers, > Andi > > ---------- Forwarded message ---------- > From: Bryan O'Sullivan <bos(a)serpentine.com> > Date: Fri, Jan 4, 2013 at 11:43 AM > Subject: Re: kqueue benchmark > To: Andreas Voellmy <andreas.voellmy(a)gmail.com> > Cc: Johan Tibell <johan.tibell(a)gmail.com>, Kazu Yamamoto <kazu(a)iij.ad.jp> > > > Thanks, Andi. At this point, I think you should just go ahead and ask Ian > or Simon to pull your work into the relevant ghc trees. It's looking great. > > > On Jan 4, 2013, at 8:39, Andreas Voellmy <andreas.voellmy(a)gmail.com> wrote: > > Bryan: thanks for the detailed review and comments! I've gone through all > of your comments and for almost all of them I made the change you suggested > (I.e. fixing the mistake in calling eventfd_write, improving comments, > reducing use of conditional compiles, etc.). The only exceptions were (1) > one minor tidying up change you suggested that became obsolete due to a > later change and (2) the comment on reducing the number of capabilities at > runtime. For this one, you asked whether the RTS supports it. It does > support it. You also mentioned that it seems a bit complex. I agree, but I > don't think it's too bad, so I've just left it alone. > > I also made a couple commits to address things with closeFdWith, closeFd, > and closeFd_ that I mentioned in my last email. > > I pushed a new branch here: > https://github.com/AndreasVoellmy/ghc-base-arv/tree/parallel-iomanager-reim… > > It has been rebased against the latest HEAD and includes the following new > commits: > > These address Bryan's comments: > f33364a Fix wrong type in FFI call to eventfd_write in GHC.Event.Control. > cd7e381 Avoid conditional compilation in GHC.Event.Manager. > 7af055c Undo recent change to the type of > GHC.Event.Thread.getSystemEventManager and update the commentary on this > function > > These are fixes to closeFdWith, closeFd, and closeFd_: > c925187 closeFdWith invokes callbacks only after the fd is closed. > bb015fe Tidy up GHC.Event.Thread.closeFdWith. > 879b0f1 closeFdWith closes fd after unregistering the fd with the backend. > b508e1a Update closeFd_ to avoid unnecessary backend modifications. > 44ed970 Change GHC.Event.Manager.closeFd to unregister interest in the file > with the backend. > 3622106 Avoid use of backend modifyFdOnce in Poll backend in unregisterFd_. > de608e5 Added missing wakeup in GHC.Event.Manager.closeFd_. > 639ee76 Improve comment on GHC.Event.Manager.closeFd_. > > > > On Mon, Dec 31, 2012 at 6:18 PM, Bryan O'Sullivan <bos(a)serpentine.com>wrote: > > > Last code review of 2012 finished :-) > > > > I've commented on all your commits on github. It's a very well put > > together patchset, and was easy to review. Thanks for going to the extra > > effort to make the patches small enough to be reviewable. > > > > There was only one obviously wrong commit, which I flagged. Apart from > > that, the only substantial comment I had was about the increased number of > > #ifdefs. I believe that many of those could be done away with, which would > > make the code both cleaner and more statically checkable on more platforms > > - I'll see if I can find time to confirm that theory. > > > > I'm sure you've seen that people are justifiedly rather excited about your > > work: https://twitter.com/bos31337/status/284701554458640384 > > > > Great work! > > B. > > > > On Fri, Dec 28, 2012 at 3:26 AM, Andreas Voellmy < > > andreas.voellmy(a)gmail.com> wrote: > > > >> The changes were almost entirely in the base package. You can find them > >> here: > >> > >> > >> https://github.com/AndreasVoellmy/ghc-base-arv/tree/parallel-iomanager-reim… > >> > >> I also had to add a couple of RTS hooks, so there are also two commits in > >> the main repo, which you can see here: > >> > >> https://github.com/AndreasVoellmy/ghc-arv/tree/parallel-iomanager-reimp-2 > >> > > > >

1 0