- Libraries - Haskell.org

Re: Changes to Typeable
by Dan Burton 05 Oct '12

05 Oct '12

Whoops, sending this to the whole list. Sorry for the duplication, Simon. -- Dan Burton ---------- Forwarded message ---------- From: Dan Burton <danburton.email(a)gmail.com> Date: Fri, Oct 5, 2012 at 11:57 AM Subject: Re: Changes to Typeable To: Simon Peyton-Jones <simonpj(a)microsoft.com> I was alluding to what Brent Yorgey and others already said. If I annotate a function with the type signature (a -> Int) then that function should *not* have access to typeable operations on its input (because then we would lose our precious free theorems). If a function is not annotated, but uses typeable operations, then type inference should indicate the corresponding Typeable constraints in the inferred type. To steal Brent's example: foo x = case typeOf x of Int -> (3 :: Int) Char -> 4 _ -> 5 This function (ignoring the monomorphism restriction) should be inferred to have the type Typeable a => a -> Int In short, from the language user's perspective, Typeable should still be a regular old typeclass, that just happens to come with a distinct instance for every type. Another way to model the "danger" of accessing Typeable information is to use a monad, and consider access to Typeable information to be an "effect".[1] For backwards compatibility, I think it would be easier to just stick with the typeclass. [1] http://hpaste.org/75824 -- Dan Burton Another, simpler alternative (if we don't want to use the Typeable typeclass or the Monad idea) is to simply prefix "unsafe" to all of the Typeable methods, and then quarentine them to a "contaminated" module as we have done with unsafePerformIO. On Fri, Oct 5, 2012 at 10:12 AM, Simon Peyton-Jones <simonpj(a)microsoft.com>wrote: > To take advantage of Typeable, though, the user should still have to > annotate the necessary Typeable constraints.**** > > ** ** > > Can you say what you mean by this? Perhaps with an example.**** > > ** ** > > Simon**** > > **** > > *From:* Dan Burton [mailto:danburton.email@gmail.com] > *Sent:* 05 October 2012 17:05 > > *To:* Simon Peyton-Jones > *Cc:* libraries(a)haskell.org > *Subject:* Re: Changes to Typeable**** > > ** ** > > Allowing users to write instances leads to potential un-soundness when > doing dynamic type casts, so it has always been a Bad Idea.**** > > ** ** > > Related to this, I'm sure several of us remember Bob Harper's blog post[1] > regarding exceptions that uses a hand-written Typeable instance. The ideal > scenario would be for the compiler to automatically derive Typeable for all > types, and completely disallow the user from providing hand-written > instances. To take advantage of Typeable, though, the user should still > have to annotate the necessary Typeable constraints. Whether this is > special-cased in the compiler for optimization is an implementation detail > and is largely irrelevant to the Haskell programmer; I say let's follow the > common Haskell mentality of making it correct first and fast second.**** > > ** ** > > Most typeclasses come with some "laws" that make them useful; I don't see > any documented laws for Typeable, but presumably there are some (e.g. no > type should say it is another type), and the compiler can automatically > derive instances that are guaranteed to follow them.**** > > ** ** > > It would be nice to be able to enforce typeclass laws on instances at > compile time, but that's stepping into theorem prover territory.**** > > ** ** > > [1] > http://existentialtype.wordpress.com/2012/08/14/haskell-is-exceptionally-un… > **** > > ** ** > > -- Dan Burton**** >

1 0

cabal update retrieves broken index: warp-1.3.3.x.cabal not readable
by Andreas Abel 05 Oct '12

05 Oct '12

Hi, I pulled the new 00-index.tar from hackage an hour ago with cabal update, breaking cabal install. cabal: Couldn't read cabal file "warp/1.3.3/warp.cabal" cabal: Couldn't read cabal file "warp/1.3.3.1/warp.cabal" Fix is $ tar -f 00-index.tar --delete warp/1.3.3 $ tar -f 00-index.tar --delete warp/1.3.3.1 My system: $ cabal --version cabal-install version 0.10.2 using version 1.10.1.0 of the Cabal library $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.0.1 The cabal files for warp/1.3.3... need a fix, or be removed from hackage. Cheers, Andreas -- Andreas Abel <>< Du bist der geliebte Mensch. Theoretical Computer Science, University of Munich Oettingenstr. 67, D-80538 Munich, GERMANY andreas.abel(a)ifi.lmu.de http://www2.tcs.ifi.lmu.de/~abel/

4 3

Compilation of directory package on GHC 7.4
by Dominique Devriese 05 Oct '12

05 Oct '12

Dear maintainers, The directory package is currently not compiling on GHC 7.4, leading to a compile failure of packages that depend on it. Hackage has a build failure log for GHC 7.4. I propose the attached patch, although I have not tested it on GHC 7.6. Can this (or an alternative fix) please be considered? Thanks in advance, Dominique Devriese

4 4

package versions tacked down, buildin' time....
by Mark Lentczner 03 Oct '12

03 Oct '12

We've entered the build phase of the next Haskell Platform release, 2012.4.0.0: - *October 1st, 2012* - Proposals decided, Initial version list - *October 15th, 2012* - First candidates - *October 29th, 2012* - Open issues resolved, Second candidates - *November 5th, 2012* - Final release candidates - *November 12th, 2012* - Release, Party The* proposed package and version list<https://github.com/haskell/haskell-platform/blob/pre-release/haskell-platfo…> *has been pushed to the *pre-release<https://github.com/haskell/haskell-platform/tree/pre-release> * branch of the repo. *New packages:* - *async* - 2.0.1.3 - *split* - 0.2.1.1 - *vector* - 0.10 Note that vector will induce primitive 0.5, but we won't consider that part of the platform, letting it just be pulled in by cabal during the build. GHC already has several packages in this category (binary, ghc-prim), and I hope to have a more consistent method of treating such packages next time around. *If you are a packager or builder of HP releases:* Almost time to start building. There is now yet a new bug in the Build.hs script, (it is very sensitive to the exact version of cabal), and I'm working on it... - Mark "mzero" Lentczner, Chef de la Release

1 1

ANN: monadLib-3.7.1 on Hackage
by Iavor Diatchki 01 Oct '12

01 Oct '12

Hello, I am pleased to announce the availability of monadLib-3.7.1 on Hackage. MonadLib is a library intended to help programmers to quickly and easily construct various monads. The library has support for a wide range of effects: threading state, read-only variables, collecting output, exception handling, back-tracking computation, and working with explicit continuations. It provides similar functionality to libraries such as MTL, but it has a simpler interface and improved functionality for a number of the transformers. The main change in this version is improved support for working with continuations: now we support invoking the same continuation in contexts that have different types. Happy hacking! -Iavor

1 0

makeRelative
by Jon Fairbairn 30 Sep '12

30 Sep '12

I have an application where I want to use relative paths in symlinks (so that rsyncing to a different machine with a different root directory produces something with the same effect). So I want makeRelative "/var/www/this_server/foo/bar/" "/var/www/this_server/bob" to return "../../bob" (which would then be used to create a symlink) so that if I copy the tree below /var/www/this_server to /var/www/that_server (perhaps on a different machine, but copying the symlinks without rewriting them), the symlinks point to the same files. On posix at least, this would permit isRelative (makeRelative a b) always to be True, which is a pleasant property for it to have. Is there any reason that System.FilePath.Posix.makeRelative should not do this? I don’t know enough about non-posix filesystems to know whether it even makes sense elsewhere. -- Jón Fairbairn Jon.Fairbairn(a)cl.cam.ac.uk

6 7

Re: need package maintainer's input for Haskell Platform
by Mark Lentczner 29 Sep '12

29 Sep '12

For the upcoming HP 2012.4.0.0 release I'd like package maintainers to confirm of which version should go in the release. I have not received input on the following packages, listed with who I think the maintainer is (which might be wrong): - *cgi* — Anders Kaseorg - *html* — Don Stewart - *parsec* — Antoine Latter - *regex-base*, *regex-compat*, *regex-posix* — Christopher Kuklewicz If these are your packages, please see the message below and contact me directly ASAP. If you know these please please ping them gently for me. :-) If I don't hear from them, I'll use the same version that is in 2012.2.0.0, which will not be the latest version. (Except for html, so I suppose Don is off the hook... but I'd still like to hear confirmation!) I will release the version list on Monday, October 1st. - Mark On Fri, Sep 21, 2012 at 6:06 AM, Mark Lentczner wrote: > You are receiving this e-mail as hackage lists you as the maintain of one > or more packages that are part of Haskell Platform (or are being considered > in active proposals). The list I have is given below - you are all bcc'd so > that replies will go directly to me. > > I need your help to get the next release of Haskell Platform out: > > *1. **If you are not the current maintainer of the package(s)* I think > you are, please let me know immediately. If you are a mailing list, please > let me know the key individual contact for this sort of communication, as > it is going to happen with every HP release. > > 2*. **Which version of your package(s) should be in the next release of > HP?* In the past we always bumped to lastest on Hackage, but that has > caused some instability of the HP build, and stability is what it's all > about. So, please, let me know the exact version of your package that > should be in HP 2012.4.0.0. > > > At present it looks like HP 2012.4.0.0 will go out with GHC 7.4.2, so > versions should build against that. Please let me know if there would be a > difference if we shipped with GHC 7.6.x. > > — Mark >

2 2

Data.Foldable.foldr1 too strict
by Henning Thielemann 27 Sep '12

27 Sep '12

I found that the default implementation of foldr1 in Data.Foldable is too strict (and foldl1, too). It always evaluates the complete spine of an input list: -- taken from base-4.6:Data.Foldable.foldr1 foldr2 f xs = fromMaybe (P.error "foldr1: empty structure") (Fold.foldr mf Nothing xs) where mf x Nothing = Just x mf x (Just y) = Just (f x y) -- lazier version, only evaluates one item ahead foldr3 f xs = fromMaybe (P.error "foldr1: empty structure") (Fold.foldr mf Nothing xs) where mf x = Just . maybe x (f x) *Data.NonEmpty> foldr2 (P.++) $ "abc" : "def" : P.undefined "*** Exception: Prelude.undefined *Data.NonEmpty> foldr3 (P.++) $ "abc" : "def" : P.undefined "abc*** Exception: Prelude.undefined

6 5

Hackage2 server testing
by Ian Lynagh 25 Sep '12

25 Sep '12

Dear Haskellers, I am pleased to announce that a test instance of the Hackage 2 server is now running at http://new-hackage.haskell.org/ The plan is to test the new server for 3 weeks (until Monday 24 September), before switching over to Hackage 2 for real. The server has a mirror of Hackage from about a month ago, but more recent uploads are not automatically mirrored. In order to upload packages to it, you will need to sign up for an account and then mail the Hackage admins (hackage-admin(a)haskell.org) telling them your username and asking to be added to the 'uploaders' group. If you run into any problems, please either file a ticket tagged 'hackage2' at https://github.com/haskell/cabal/issues or send an e-mail to the cabal-devel(a)haskell.org mailing list. A few more details about the plan: Assuming no major issues are found, the plan for after Monday is to disable uploads to the current Hackage server, to make an up-to-date mirror of it, and then to switch over to Hackage 2. Finally, I would like to thank the Industrial Haskell Group (http://industry.haskell.org/) for funding this work. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

6 17

Proposal: Adding generics-based rnf-helper to `deepseq`
by Herbert Valerio Riedel 25 Sep '12

25 Sep '12

Hello Simon (et al.), Some time ago, the `generic-deepseq` package was announced to the haskell-cafe list, and some discussion took place[1], and the suggestion came up that it might useful to be included to `deepseq` somehow. IMHO, a least introduing way (which I've been using myself) would be to add something along the code below to the `Control.DeepSeq` module (only `genericsRnf` shall be exported, thus avoiding a PVP-major-bump): -- | Generics-based 'rnf' implementation genericsRnf :: (Generic a, GNFData (Rep a)) => a -> () genericsRnf = grnf_ . from {-# INLINE genericRnf #-} -- | Hidden type-class, /not/ exported class GNFData f where grnf_ :: f a -> () instance GNFData U1 where grnf_ !U1 = () {-# INLINE grnf_ #-} instance NFData a => GNFData (K1 i a) where grnf_ = rnf . unK1 {-# INLINE grnf_ #-} instance GNFData a => GNFData (M1 i c a) where grnf_ = grnf_ . unM1 {-# INLINE grnf_ #-} instance (GNFData a, GNFData b) => GNFData (a :*: b) where grnf_ (x :*: y) = grnf_ x `seq` grnf_ y {-# INLINE grnf_ #-} instance (GNFData a, GNFData b) => GNFData (a :+: b) where grnf_ (L1 x) = grnf_ x grnf_ (R1 x) = grnf_ x {-# INLINE grnf_ #-} this way, the client code can then chose to use a Generics-derived `rnf` implementation expliclity by simply declaring: instance NFData FooBar where rnf = genericsRnf ...does this sound sensible? cheers, hvr [1]: http://www.haskell.org/pipermail/haskell-cafe/2012-February/099551.html --

6 13