- Libraries - Haskell.org

Re: MonadFail proposal (MFP): Moving fail out of Monad
by Dan Doel 11 Jun '15

11 Jun '15

This is all well defined in the Haskell 1.4 report. Back then Haskell had "unfailable" patterns for desugaring do notation, because there was no fail (it was introduced in H98). I believe a pattern is classified as unfailable there if it is irrefutable or refutable only by bottom. Which of course is the distinction here, (x,y) is unfailable, but not irrefutable. And of course, it seems that GHC never actually stopped implementing unfailable patterns, even though they were removed from the report (or someone added it back at some point). You just have to know how to observe this fact. -- Dan On Thu, Jun 11, 2015 at 12:11 PM, David Turner < dct25-561bs(a)mythic-beasts.com> wrote: > Quoting the Haskell 2010 Report section 3.17.2: Attempting to match a > pattern can have one of three results: it may fail; it may succeed > ...; or it may diverge. Then in paragraph 5: > > Matching the pattern con pat1 ... patn against a value, where con is a > constructor defined by data, depends on the value: > - If the value is of the form con v1 ... vn, sub-patterns are matched > left-to-right against the components of the data value; if all matches > succeed, the overall match succeeds; the first to fail or diverge > causes the overall match to fail or diverge, respectively. > - If the value is of the form con' v1 ... vm, where con is a different > constructor to con', the match fails. > - If the value is ⊥, the match diverges. > > In particular, matching (_,_) can only succeed or diverge: failure is > not an option! Desugaring 'do' handles match failure with a catch-all > case that calls 'fail' but doesn't handle ⊥. > > > > On 11 June 2015 at 16:28, Wolfgang Jeltsch <g9ks157k(a)acme.softbase.org> > wrote: > > Are you sure that desugaring works this way? If yes, this should be > > considered a bug and be fixed, I would say. It is very illogical. > > > > All the best, > > Wolfgang > > > > Am Donnerstag, den 11.06.2015, 16:23 +0100 schrieb David Turner: > >> AIUI the point about ⊥ and (⊥, ⊥) being different doesn't matter here: > >> a bind for a single-constructor datatype never desugars in a way that > >> uses fail (which isn't to say that it can't be undefined) > >> > >> For instance: > >> > >> runErrorT (do { (_,_) <- return undefined; return () } :: ErrorT String > IO ()) > >> > >> throws an exception, even though the bind is in ErrorT where fail just > >> returns left: > >> > >> runErrorT (do { fail "oops"; return () } :: ErrorT String IO ()) > >> > >> => Left "oops" > >> > >> Hope that helps, and hope I understand correctly! > >> > >> David > >> > >> > >> On 11 June 2015 at 16:08, Wolfgang Jeltsch <g9ks157k(a)acme.softbase.org> > wrote: > >> > Hi David, > >> > > >> > thank you very much for this proposal. I think having fail in Monad is > >> > just plain wrong, and I am therefore very happy to see it being moved > >> > out. > >> > > >> > I have some remarks, though: > >> > > >> >> A class of patterns that are conditionally failable are `newtype`s, > >> >> and single constructor `data` types, which are unfailable by > >> >> themselves, but may fail if matching on their fields is done with > >> >> failable paterns. > >> > > >> > The part about single-constructor data types is not true. A > >> > single-constructor data type has a value ⊥ that is different from > >> > applying the data constructor to ⊥’s. For example, ⊥ and (⊥, ⊥) are > two > >> > different values. Matching ⊥ against the pattern (_, _) fails, > matching > >> > (⊥, ⊥) against (_, _) succeeds. So single-constructor data types are > not > >> > different from all other data types in this respect. The dividing line > >> > really runs between data types and newtypes. So only matches against > >> > patterns C p where C is a newtype constructor and p is unfailable > should > >> > be considered unfailable. > >> > > >> >> - Applicative `do` notation is coming sooner or later, `fail` might > >> >> be useful in this more general scenario. Due to the AMP, it is > >> >> trivial to change the `MonadFail` superclass to `Applicative` > >> >> later. (The name will be a bit misleading, but it's a very small > >> >> price to pay.) > >> > > >> > I think it would be very misleading having a MonadFail class that > might > >> > have instances that are not monads, and that this is a price we should > >> > not pay. So we should not name the class MonadFail. Maybe, Fail would > be > >> > a good name. > >> > > >> >> I think we should keep the `Monad` superclass for three main reasons: > >> >> > >> >> - We don't want to see `(Monad m, MonadFail m) =>` all over the > place. > >> > > >> > But exactly this will happen if we change the superclass of > (Monad)Fail > >> > from Monad to Applicative. So it might be better to impose a more > >> > light-weight constraint in the first place. Functor m might be a good > >> > choice. > >> > > >> > All the best, > >> > Wolfgang > >> > > >> > _______________________________________________ > >> > ghc-devs mailing list > >> > ghc-devs(a)haskell.org > >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs(a)haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >

1 0

Re: MonadFail proposal (MFP): Moving fail out of Monad
by Wolfgang Jeltsch 11 Jun '15

11 Jun '15

Are you sure that desugaring works this way? If yes, this should be considered a bug and be fixed, I would say. It is very illogical. All the best, Wolfgang Am Donnerstag, den 11.06.2015, 16:23 +0100 schrieb David Turner: > AIUI the point about ⊥ and (⊥, ⊥) being different doesn't matter here: > a bind for a single-constructor datatype never desugars in a way that > uses fail (which isn't to say that it can't be undefined) > > For instance: > > runErrorT (do { (_,_) <- return undefined; return () } :: ErrorT String IO ()) > > throws an exception, even though the bind is in ErrorT where fail just > returns left: > > runErrorT (do { fail "oops"; return () } :: ErrorT String IO ()) > > => Left "oops" > > Hope that helps, and hope I understand correctly! > > David > > > On 11 June 2015 at 16:08, Wolfgang Jeltsch <g9ks157k(a)acme.softbase.org> wrote: > > Hi David, > > > > thank you very much for this proposal. I think having fail in Monad is > > just plain wrong, and I am therefore very happy to see it being moved > > out. > > > > I have some remarks, though: > > > >> A class of patterns that are conditionally failable are `newtype`s, > >> and single constructor `data` types, which are unfailable by > >> themselves, but may fail if matching on their fields is done with > >> failable paterns. > > > > The part about single-constructor data types is not true. A > > single-constructor data type has a value ⊥ that is different from > > applying the data constructor to ⊥’s. For example, ⊥ and (⊥, ⊥) are two > > different values. Matching ⊥ against the pattern (_, _) fails, matching > > (⊥, ⊥) against (_, _) succeeds. So single-constructor data types are not > > different from all other data types in this respect. The dividing line > > really runs between data types and newtypes. So only matches against > > patterns C p where C is a newtype constructor and p is unfailable should > > be considered unfailable. > > > >> - Applicative `do` notation is coming sooner or later, `fail` might > >> be useful in this more general scenario. Due to the AMP, it is > >> trivial to change the `MonadFail` superclass to `Applicative` > >> later. (The name will be a bit misleading, but it's a very small > >> price to pay.) > > > > I think it would be very misleading having a MonadFail class that might > > have instances that are not monads, and that this is a price we should > > not pay. So we should not name the class MonadFail. Maybe, Fail would be > > a good name. > > > >> I think we should keep the `Monad` superclass for three main reasons: > >> > >> - We don't want to see `(Monad m, MonadFail m) =>` all over the place. > > > > But exactly this will happen if we change the superclass of (Monad)Fail > > from Monad to Applicative. So it might be better to impose a more > > light-weight constraint in the first place. Functor m might be a good > > choice. > > > > All the best, > > Wolfgang > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs(a)haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

2 2

Re: Time files... and here's another alpha HP for 7.10
by Mark Lentczner 09 Jun '15

09 Jun '15

When you did the cabal install of haddock, which haddock did you get? Isn't 2.16.0 the latest? And that should be what is in the Platform. I guess I should check that the haddock in GHC is actually 2.16.0!

1 0

deepseq:NFData1 class
by Henning Thielemann 08 Jun '15

08 Jun '15

I have the type data NonEmpty f a = NonEmpty a (f a) and want to declare an NFData instance in Haskell 98. With the existing NFData class this is not possible because it requires a (NFData (f a)) constraint which needs FlexibleContexts. A solution would be an NFData1 class analogously to the classes in transformers:Data.Functor.Classes: class NFData1 f where rnf1 :: NFData a => f a -> () instance NFData1 [] where rnf1 = rnf instance (NFData1 f) => NFData1 (NonEmpty f) where rnf1 (NonEmpty x xs) = rnf (x, rnf1 xs) instance (NFData1 f, NFData a) => NFData (NonEmpty f a) where rnf = rnf1

1 0

ANN: bytestring-lexing 0.5.0
by wren romano 06 Jun '15

06 Jun '15

-------------------------------------------- -- bytestring-lexing 0.5.0 -------------------------------------------- The bytestring-lexing package offers extremely efficient bytestring parsers for some common lexemes: namely integral and fractional numbers. In addition, it provides efficient serializers for (some of) the formats it parses. As of version 0.3.0, bytestring-lexing offers the best-in-show parsers for integral values. (According to the Warp web server's benchmark of parsing the Content-Length field of HTTP headers.) And as of this version (0.5.0) it offers (to my knowledge) the best-in-show parser for fractional/floating numbers. -------------------------------------------- -- Changes since 0.4.3 (2013-03-21) -------------------------------------------- I've completely overhauled the parsers for fractional numbers. The old Data.ByteString.Lex.Double and Data.ByteString.Lex.Lazy.Double modules have been removed, as has their reliance on Alex as a build tool. I know some users were reluctant to use bytestring-lexing because of that dependency, and forked their own version of bytestring-lexing-0.3.0's integral parsers. This is no longer an issue, and those users are requested to switch over to using bytestring-lexing. The old modules are replaced by the new Data.ByteString.Lex.Fractional module. This module provides two variants of the primary parsers. The readDecimal and readExponential functions are very simple and should suffice for most users' needs. The readDecimalLimited and readExponentialLimited are variants which take an argument specifying the desired precision limit (in decimal digits). With care, the limited-precision parsers can perform far more efficiently than the unlimited-precision parsers. Performance aside, they can also be used to intentionally restrict the precision of your program's inputs. -------------------------------------------- -- Benchmarks -------------------------------------------- For the Criterion output of the benchmark discussed below, see <http://community.haskell.org/~wren/bytestring-lexing/bench/html/readExponen…>. The main competitors we compare against are the previous version of bytestring-lexing (which already surpassed text and attoparsec/scientific) and bytestring-read which was the previous best-in-show. The unlimited-precision parsers provide 3.3x to 3.9x speedup over the readDouble function from bytestring-lexing-0.4.3.3, as well as being polymorphic over all Fractional values. For Float/Double: these functions have essentially the same performance as bytestring-read on reasonable inputs (1.07x to 0.89x), but for inputs which have far more precision than Float/Double can handle these functions are much slower than bytestring-read (0.30x 'speedup'). However, for Rational: these functions provide 1.26x to 1.96x speedup compared to bytestring-read. The limited-precision parsers do even better, but require some care to use properly. For types with infinite precision (e.g., Rational) we can pass in an 'infinite' limit by passing the length of the input string plus one. For Rational: doing so provides 1.5x speedup over the unlimited-precision parsers (and 1.9x to 3x speedup over bytestring-read), because we can avoid intermediate renormalizations. Whether other unlimited precision types would see the same benefit remains an open question. For types with inherently limited precision (e.g., Float/Double), we could either pass in an 'infinite' limit or we could pass in the actual inherent limit. For types with inherently limited precision, passing in an 'infinite' limit degrades performance compared to the unlimited-precision parsers (0.51x to 0.8x 'speedup'). Whereas, passing in the actual inherent limit gives 1.3x to 4.5x speedup over the unlimited-precision parsers. They also provide 1.2x to 1.4x speedup over bytestring-read; for a total of 5.1x to 14.4x speedup over bytestring-lexing-0.4.3.3! -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/package/bytestring-lexing Darcs: http://community.haskell.org/~wren/bytestring-lexing Haddock (Darcs version): http://community.haskell.org/~wren/bytestring-lexing/dist/doc/html/bytestri… -- Live well, ~wren

1 0

Re: Time files... and here's another alpha HP for 7.10
by Mark Lentczner 02 Jun '15

02 Jun '15

On Tue, Jun 2, 2015 at 4:40 AM, George Colpitts <george.colpitts(a)gmail.com> wrote: > I guess I should file a haddock bug as I got the same error installing > threadscope Does ghc --print-libdir display the correct path? (That is, with the full version number.) - Mark

1 0

Time files... and here's another alpha HP for 7.10
by Mark Lentczner 02 Jun '15

02 Jun '15

So - I hear from a bird that 7.10.2 might be just around the corner. I'm getting ahead of the curve! I just did a fully hermetic and clean build of head of GHC 7.10 branch (what should become 7.10.2), and then brought HP up-to-date: - bootstrapped with 7.10.1 (so hptool needed fixes to build with that) - uses latest shake - built on a clean Debian Wheezy (7) install, (hence uses glibc 2.13 and should also run on Ubuntu 12.04 and later) The package versions are updated as follows: Cabal 1.22.2.0 --> 1.22.3.0 cabal-install 1.22.2.0 --> 1.22.4.0 attoparsec 0.12.1.4 --> 0.13.0.0 syb 0.4.4 --> 0.5.1 text 1.2.0.4 --> 1.2.1.1 cgi 3001.2.2.1 --> 3001.2.2.2 network 2.6.0.2 --> 2.6.2.0 network-uri 2.6.0.1 --> 2.6.0.3 QuickCheck 2.8 --> 2.8.1 hscolour 1.22 --> 1.23 GLUT 2.7.0.0 --> 2.7.0.1 GLURaw 1.5.0.0 --> 1.5.0.1 OpenGL 2.12.0.0 --> 2.12.0.1 OpenGLRaw 2.4.1.0 --> 2.5.0.0 Only package issue was: zlib 0.5.4.2 -- held back because cabal-install needs < 0.6 All the same caveats and notes from Alpha 2 still apply. All these changes are in the pre-release-2 branch on github -- I'll merge it all together later this week. There is a hp-bindist-tarball on my server: haskell-platform-7.10.1.20150528-x86_64-unknown-linux-deb7.tar.gz <http://www.ozonehouse.com/mark/platform/haskell-platform-7.10.1.20150528-x8…> SHA-256: b503c9e2c34c0865b5fee39444027667bb39b786fa7664029287e3bbf33379da I'll build and put up OS X version in a day or two. One last thing... I'm proposing that we name this release: Haskell Platform 7.10.2 ! - Mark

1 1

[directory] status of HsDirectory.h
by Phil Ruffwind 01 Jun '15

01 Jun '15

I noticed that there aren't many things left in the HsDirectory.h: - macros from autoconf - __hscore_long_path_size - __hscore_S_IRUSR/IWUSR/IXUSR/IFDIR Most of these could be done easily using hsc so I was tempted to remove them. Not to mention, the implementation of __hscore_long_path_size is rather dangerous on systems where PATH_MAX is not defined.[1] However, I wonder if the __hscore prefix has any significance. Are these functions by any chance used in GHC internals or some other libraries? For now I intend to leave them as is. But if no-one else uses them, then I think the header should be deprecated and made private in the future. [1]: http://pubs.opengroup.org/onlinepubs/9699919799 -- Phil

1 0

cabal-install: bug and quest for a workaround
by Wolfgang Jeltsch 01 Jun '15

01 Jun '15

Hi, I have just installed GHC 7.10.1 and cabal-install 1.22.4.0. The problem is that cabal-install often hangs when trying to download a package. With --verbose=3, I see that it gets a “301 Moved Permanently” from the server, tries to redirect, shows “Recovering connection to hackage.haskell.org”, and then hangs. Is there anything I can do to work around this issue? At the moment, I cannot work with my new GHC installation, since it is virtually impossible to install packages with cabal-install. All the best, Wolfgang

1 0

Template Haskell changes to names and package keys
by Edward Z. Yang 29 May '15

29 May '15

In GHC 7.10, we changed the internal representation of names to be based on package keys (base_XXXXXX) rather than package IDs (base-4.7.0.1), however, we forgot to update the Template Haskell API to track these changes. This lead to some bugs in TH code which was synthesizing names by using package name and version directly, e.g. https://ghc.haskell.org/trac/ghc/ticket/10279 We now propose the following changes to the TH API in order to track these changes: 1. Currently, a TH NameG contains a PkgName, defined as: newtype PkgName = PkgName String This is badly misleading, even in the old world order, since these needed version numbers as well. We propose that this be renamed to PkgKey: newtype PkgKey = PkgKey String mkPackageKey :: String -> PackageKey mkPackageKey = PkgKey 2. Package keys are somewhat hard to synthesize, so we also offer an API for querying the package database of the GHC which is compiling your code for information about packages. So, we introduce a new abstract data type: data Package packageKey :: Package -> PkgKey and some functions for getting packages: searchPackage :: String -- Package name -> String -- Version -> Q [Package] reifyPackage :: PkgKey -> Q Package We could add other functions (e.g., return all packages with a package name). 3. Commonly, a user wants to get the package key of the current package. Following Simon's suggestion, this will be done by augmenting ModuleInfo: data ModuleInfo = ModuleInfo { mi_this_mod :: Module -- new , mi_imports :: [Module] } We'll also add a function for accessing the module package key: modulePackageKey :: Module -> PkgKey And a convenience function for accessing the current module: thisPackageKey :: Q PkgKey thisPackageKey = fmap (modulePackageKey . mi_this_mod) qReifyModule thisPackage :: Q Package thisPackage = reifyPackage =<< thisPackageKey Discussion period: 1 month Thanks, Edward (apologies to cc'd folks, I sent from my wrong email address)

7 17