January 2013 - Libraries

Re: [commit: base] master: fix negative numbers for * modifiers (#7457) (63202b9)
by Ian Lynagh 29 Jan '13

29 Jan '13

On Mon, Jan 28, 2013 at 02:06:48AM -0800, Simon Marlow wrote: > > commit 63202b9df64041e1c17603ad5f06fec3c51f357d > Author: Simon Marlow <marlowsd(a)gmail.com> > Date: Mon Jan 28 09:38:06 2013 +0000 > > fix negative numbers for * modifiers (#7457) > > >--------------------------------------------------------------- > > Text/Printf.hs | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/Text/Printf.hs b/Text/Printf.hs > index 0546e84..6028e16 100644 > --- a/Text/Printf.hs > +++ b/Text/Printf.hs > @@ -281,7 +281,7 @@ getSpecs l z s ('*':cs) us = > in ((p', r), us''') > '.':r -> (stoi 0 r, us') > _ -> ((-1, cs), us') > - in (n, p, l, z, s, cs'', us'') > + in (abs n, p, if n < 0 then not l else l, z, s, cs'', us'') > getSpecs l z s ('.':cs) us = > let ((p, cs'), us') = > case cs of Hmm, this works for minBound for Int8: > printf "%*sx\n" (-4 :: Int8) "hi" hi x > printf "%*sx\n" (minBound :: Int8) "hi" hi x but not Int: > printf "%*sx\n" (-4 :: Int) "hi" hi x > printf "%*sx\n" (minBound :: Int) "hi" hix (the last line should have a huge number of spaces between "hi" and "x". Actually, this matches what the printf commandline program does: $ printf "%*sx\n" -4 hi hi x $ printf "%*sx\n" -2147483648 hi hix and C just doesn't print anything: $ cat q.c #include <stdio.h> int main(void) { int i; i = -2147483648; printf("%*sx\n", -4, "hi"); printf("%*sx\n", i, "hi"); printf("Test\n"); return 0; } $ gcc q.c -o q $ ./q hi x Test $ This probably isn't important for printf, but it's a problem that seems to keep coming up. I wonder if there's something we should do. We could add methods like maybeAbs :: a -> Maybe a maybeAbs = Just . abs -- default method to Num, but div and friends are a little trickier, as they can return either divZeroError or overflowError, or even partially succeed in the case of (-1) `divMod` minBound == (overflowError, 0) Thanks Ian

1 0

Haskell Platform Package Guidelines
by Mark Lentczner 29 Jan '13

29 Jan '13

As promised... only a day late.... Here is a write up of some guidelines for Haskell Platform Packages: *HP Package Guildelines<https://docs.google.com/document/d/1Uf6hu65WDzQt4S4baa6K1jlonFgG_rIeCL36iB8…> * These are not hard and fast rules, nor an official requirements list. They are mostly what I've initially pulled together from my experience as release manager, and informal discussions with many of you over the last few months. I'm certain that these guidelines will evolve! This is just my first take. Let me know what you think. - Mark

3 2

suggestions for improving MonadWriter
by Petr P 29 Jan '13

29 Jan '13

Dear maintainers, I have two suggestions for MonadWriter: (1) Remove the "Monoid w" constraint from the definition. The constraints prevent creating new instances of the class that have only an implied monoid. For example, I needed to create a simple writer which always stores the last written element. I had to wrap it into Last, which was a nuisance for users of my library. Without the constraint, my instance would be quite simpler and still satisfying all the laws. There are many other similar use cases, like counting the number of written values (and disregarding their actual content) etc. The constraint is meant to ensure that instances of that class obey the monad laws. But it's not the responsibility of a type class that its instances satisfy the laws. They could violate them even without this constraints. Instead, this constraint should be specified (and it is) in the definition of their instances. It has been discussed in haskell-cafe <http://www.haskell.org/pipermail/ haskell-cafe/2012-December/thread.html#105088> with arguments for and against. (2) Add -- | @contained m@ executes the action @m@ in a contained environment and -- returns its value and its output. The current output is not modified. contained :: m a -> m (a, w) to MonadWriter. This generalizes "pass" and "listen" and has it's a sort of inverse to "writer" with these simple laws: writer <=< contained = id contained . writer = return It seems as a understandable set of laws that its instances should obey. It also expresses the same concept as "runWriterT" does, but inside the type class. In particular, for "WriterT" we have contained :: (Monoid w, Monad m) => WriterT w m a -> WriterT w m (a, w) contained = lift . runWriterT Current instances won't be affected as "contained" can be expressed using "pass" and "listen" (and vice versa). Full details available at https://github.com/ppetr/mtl/compare/9cc075cfaa40028a54f1dedf62af67e912f9fd… [There "contained" is expressed without the "Monoid w" constraint as suggested in (1). If we keep the constraint, "contained" can be expressed more simply as containde k = pass (listen k >>= \x -> return (x, const mempty)). Also, "contained" isn't probably a good name, I just couldn't think of anything better.] Best regards, Petr Pudlak

6 7

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

25 Jan '13

On Fri, 25 Jan 2013 11:00:23 +0100 Gabor Greif <ggreif(a)gmail.com> wrote: > Hio all! > > Just a piece of feedback, > > this patch is giving me (when 'perl boot') an error: > > Booting libraries/integer-gmp/ > configure.ac:70: error: possibly undefined macro: AC_COMPUTE_INT > If this token and others are legitimate, please use m4_pattern_allow. > See the Autoconf documentation. > autoreconf: /usr/bin/autoconf failed with exit status: 1 > > I have > > $ autoconf --version > autoconf (GNU Autoconf) 2.59 > Written by David J. MacKenzie and Akim Demaille. > > Copyright (C) 2003 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. How easy for you would be to update autoconf-2.61? It's rather old (from Nov 2006). I guess it should be present in repositories. Would AC_PREREQ be enough to report minimal requirement to a ghc's dev tree? Patch attached. -- Sergei

1 0

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