- Haskell-Cafe - Haskell.org

Dealing with GHC 7.10 prelude imports
by Brendan Hay 13 Apr '15

13 Apr '15

Hi, I've run into a couple of cases when attempting to support multiple GHC versions in my libraries (7.6.3 -> 7.10) where I've repeatedly made mistakes due to being warned about unused imports for various modules that are now part of the Prelude such as Data.Monoid, Data.Foldable, etc. which I subsequently remove either manually or via editor automation sufficiently indistinguishable from magic. This then results in successful compilation on 7.10 and failure on earlier versions of GHC due to missing imports (ie. Data.Monoid (mappend, mempty)), which prior to my current workflow of manually building on multiple versions of GHC before releasing a new version, manifested once or twice only after uploading to Hackage. Now this is all user/workflow error on my part, but I wondered if others have some kind of trick up their sleeve for avoiding these kind of issues? I could attempt to tailor the compiler's warning flags appropriately, but it bodes ill for spotting genuinely unused imports. Cheers, Brendan

5 5

Re: [Haskell-cafe] Generalized Newtype Deriving not allowed in Safe Haskell
by Richard Eisenberg 12 Apr '15

12 Apr '15

On Apr 12, 2015, at 9:51 AM, David Terei <dave.terei(a)gmail.com> wrote: > > Ideally I'd like to find a way forward that works for everyone and > isn't just a Safe Haskell mode setting. Agreed. I'm not convinced this can be done, but it's certainly worth trying. > > I think the first question is, are there situations where you'd want > to use `coerce` internally to a module but disallow it externally? The > role mechanism is a little awkward as it doesn't allow this (although > it does for newtype's). If yes, then I think we should start there. Yes, the ability to use `coerce` within one module but not elsewhere would be nice. This can currently be simulated (without too much difficulty) with newtypes. A datatype D can have a more permissive role signature than an equivalent newtype N (where `newtype N = MkN D`). The package then exports N (without its constructor). This effectively allows local uses of `coerce`, even for datatypes. A more direct mechanism would be better, but I don't think we should bend over backwards for it. > > If it seems we don't need external vs internal control, then we could > simply change the default to be that GHC sets referential type > parameters to nominal and allows them to be weakened to referential > through role annotations. We could use hackage to test how much > breakage this would cause. I worry that the breakage would be significant. But, now that authors have had a chance to put in role annotations, maybe it wouldn't be so bad. The change to GHC to make this happen is trivial: just change default_role in TcTyDecls.initialRoleEnv1. I don't have the infrastructure around to make an all-of-Hackage test, but I'm happy to support someone else who does. Richard

1 0

Re: [Haskell-cafe] Generalized Newtype Deriving not allowed in Safe Haskell
by Richard Eisenberg 10 Apr '15

10 Apr '15

Here's an idea: For a module to be Safe, then for each exported datatype, one of the following must hold: 1) The datatype comes with a role annotation. 2) The module exports all of the datatype's constructors. 3) If the datatype is defined in a place other than the current module, the current module exports no fewer data constructors than are exported in the datatype's defining module. Why? 1) The role annotation, even if it has no effect, shows that the programmer has considered roles. Any mistake here is clearly the programmer's fault. 2) This datatype is clearly meant not to be abstract. `Coercible` then gives clients no more power than they already have. 3) This is subtler. It is a common idiom to export a datatype's constructors from a package-internal module, but then never to export the constructors beyond the package. If such a datatype has a role annotation (in its defining module, of course), then we're fine, even if it is exported abstractly later. However, suppose we are abstractly re-exporting a datatype that exports its constructors from its defining module. If there is no role annotation on the datatype, we're in trouble and should fail. BUT, if the datatype were exported abstractly in its defining module, then we don't need to fail on re-export, because nothing has changed. Actually, we could simplify the conditions. Change (2) to: 2') The module exports all of the datatype's visible constructors. I think explaining in terms of separate rules (2) and (3) is a little clearer, because the re-export case is slightly subtle, and this subtlety can be lost in (2'). This proposal would require tracking (in interface files, too) whether or not a datatype comes with a role annotation. This isn't hard, though. It might even help in pretty-printing. An alternative would be to have a way of setting roles differently on export than internally. I don't think this breaks the type system, but it's yet another thing to specify and support. And we'd have to consider the possibility that some module will import a datatype from multiple re-exporting modules, each with different ascribed role annotations. Is this an error? Does GHC take some sort of least upper bound? I prefer not to go here, but there's nothing terribly wrong with this approach. Richard On Apr 10, 2015, at 9:37 AM, David Terei <dave.terei(a)gmail.com> wrote: > I'll prepare a patch for the userguide soon. > > As for something better, yes I think we can and should. It's on my > todo list :) Basically, the new-GND design has all the mechanisms to > be safe, but sadly the defaults are rather worrying. Without explicit > annotations from the user, module abstractions are broken. This is why > we left GND out of Safe Haskell for the moment as it is a subtle and > easy mistake to make. > > If the module contained explicit role annotations then it could be > allowed. The discussion in > https://ghc.haskell.org/trac/ghc/ticket/8827 has other solutions that > I prefer, such as only exporting the Coerce instance if all the > constructors are exported, it seems that the ship sailed on these > bigger changes sadly. > > Cheers, > David > > On 9 April 2015 at 00:56, Simon Peyton Jones <simonpj(a)microsoft.com> wrote: >> There is a long discussion on https://ghc.haskell.org/trac/ghc/ticket/8827 >> about whether the new Coercible story makes GND ok for Safe Haskell. At a >> type-soundness level, definitely yes. But there are other less-clear-cut >> issues like “breaking abstractions” to consider. The decision on the ticket >> (comment:36) seems to be: GND stays out of Safe Haskell for now, but there >> is room for a better proposal. >> >> >> >> I don’t have an opinion myself. David Terei and David Mazieres are in the >> driving seat, but I’m sure they’ll be responsive to user input. >> >> >> >> However, I think the user manual may not have kept up with #8827. The >> sentence “GeneralizedNewtypeDeriving — It can be used to violate constructor >> access control, by allowing untrusted code to manipulate protected data >> types in ways the data type author did not intend, breaking invariants they >> have established.” vanished from the 7.8 user manual (links below). Maybe >> it should be restored. >> >> >> >> Safe Haskell aficionados, would you like to offer a patch for the manual? >> And maybe also a less drastic remedy than omitting GND altogether? >> >> >> >> Simon >> >> >> >> From: Omari Norman [mailto:omari@smileystation.com] >> Sent: 09 April 2015 02:44 >> To: haskell Cafe >> Subject: Generalized Newtype Deriving not allowed in Safe Haskell >> >> >> >> When compiling code with Generalized Newtype Deriving and the -fwarn-unsafe >> flag, I get >> >> >> >> -XGeneralizedNewtypeDeriving is not allowed in Safe Haskell >> >> >> >> This happens both in GHC 7.8 and GHC 7.10. >> >> >> >> I thought I remembered reading somewhere that GNTD is now part of the safe >> language? The GHC manual used to state that GNTD is not allowed in Safe >> Haskell: >> >> >> >> https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/safe-haskell… >> >> >> >> But this language on GNTD not being part of the safe language was removed in >> the 7.8 manual: >> >> >> >> https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_guide/safe-haskell… >> >> >> >> The GHC release notes don't say anything about this one way or the other. >> Thoughts? >> >> >> _______________________________________________ >> 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 >

3 2

indexed writer monad
by Nicholls, Mark 10 Apr '15

10 Apr '15

Anyone? I can handle monads, but I have something (actually in F#) that feels like it should be something like a indexed writer monad (which F# probably wouldn't support). So I thought I'd do some research in Haskell. I know little or nothing about indexed monad (though I have built the indexed state monad in C#). So I would assume there would be an indexed monoid (that looks at bit like a tuple?)... e.g. (a,b) ++ (c,d) = (a,b,c,d) (a,b,c,d) ++ (e) = (a,b,c,d,e) ? There seems to be some stuff about "update monads", but it doesn't really look like a writer. I could do with playing around with an indexed writer, in order to get my head around what I'm doing....then try and capture what I'm doing...then try (and fail) to port it back. CONFIDENTIALITY NOTICE This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT.

3 12

Haskell on BBC Radio 4
by Colin Adams 10 Apr '15

10 Apr '15

Haskell featured strongly today in the last Episode of Radio 4's "Codes that changed the world": http://www.bbc.co.uk/programmes/b05prkh7

2 1

Re: [Haskell-cafe] PrimMonad for Control.Monad.ST.Lazy?
by oleg＠okmij.org 10 Apr '15

10 Apr '15

Ken Takusagawa II wrote: > What I Am Really Trying To Do: get a purely lazy stream of random values Streams of random data is actually somewhat popular structure, and has been asked about before. What was also found out that such lazy streams are fraught with problems. Some are described on this page: http://okmij.org/ftp/continuations/PPYield/index.html#randoms The page also shows two solutions, which are robust and easy to reason about. Lazy evaluation does promote compositionality on one hand, and it also inhibits compositionality. Reasoning about lazy programs is inherently non-compositional, breaking abstraction boundaries, as the page demonstrates. Overall, lazy evaluation has not worked out as it was originally hoped for. There are alternatives that are more compositional and easier to reason about, including reasoning about performance.

4 4

Re: [Haskell-cafe] Generalized Newtype Deriving not allowed in Safe Haskell
by Simon Peyton Jones 10 Apr '15

10 Apr '15

| prefer, such as only exporting the Coerce instance if all the | constructors are exported, it seems that the ship sailed on these Coercible is relatively recent; I don't think we should regard it as cast in stone. But yes, the Coerbible instance of a newtype is only available when the data constructor for the newtype is lexically in scope. Simon | -----Original Message----- | From: davidterei(a)gmail.com [mailto:davidterei@gmail.com] On Behalf Of | David Terei | Sent: 10 April 2015 09:38 | To: Simon Peyton Jones | Cc: Omari Norman; haskell Cafe; ghc-devs(a)haskell.org | Subject: Re: Generalized Newtype Deriving not allowed in Safe Haskell | | I'll prepare a patch for the userguide soon. | | As for something better, yes I think we can and should. It's on my todo | list :) Basically, the new-GND design has all the mechanisms to be | safe, but sadly the defaults are rather worrying. Without explicit | annotations from the user, module abstractions are broken. This is why | we left GND out of Safe Haskell for the moment as it is a subtle and | easy mistake to make. | | If the module contained explicit role annotations then it could be | allowed. The discussion in | https://ghc.haskell.org/trac/ghc/ticket/8827 has other solutions that I | prefer, such as only exporting the Coerce instance if all the | constructors are exported, it seems that the ship sailed on these | bigger changes sadly. | | Cheers, | David | | On 9 April 2015 at 00:56, Simon Peyton Jones <simonpj(a)microsoft.com> | wrote: | > There is a long discussion on | > https://ghc.haskell.org/trac/ghc/ticket/8827 | > about whether the new Coercible story makes GND ok for Safe Haskell. | > At a type-soundness level, definitely yes. But there are other | > less-clear-cut issues like “breaking abstractions” to consider. The | > decision on the ticket | > (comment:36) seems to be: GND stays out of Safe Haskell for now, but | > there is room for a better proposal. | > | > | > | > I don’t have an opinion myself. David Terei and David Mazieres are in | > the driving seat, but I’m sure they’ll be responsive to user input. | > | > | > | > However, I think the user manual may not have kept up with #8827. | The | > sentence “GeneralizedNewtypeDeriving — It can be used to violate | > constructor access control, by allowing untrusted code to manipulate | > protected data types in ways the data type author did not intend, | > breaking invariants they have established.” vanished from the 7.8 | > user manual (links below). Maybe it should be restored. | > | > | > | > Safe Haskell aficionados, would you like to offer a patch for the | manual? | > And maybe also a less drastic remedy than omitting GND altogether? | > | > | > | > Simon | > | > | > | > From: Omari Norman [mailto:omari@smileystation.com] | > Sent: 09 April 2015 02:44 | > To: haskell Cafe | > Subject: Generalized Newtype Deriving not allowed in Safe Haskell | > | > | > | > When compiling code with Generalized Newtype Deriving and the | > -fwarn-unsafe flag, I get | > | > | > | > -XGeneralizedNewtypeDeriving is not allowed in Safe Haskell | > | > | > | > This happens both in GHC 7.8 and GHC 7.10. | > | > | > | > I thought I remembered reading somewhere that GNTD is now part of the | > safe language? The GHC manual used to state that GNTD is not allowed | > in Safe | > Haskell: | > | > | > | > https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/safe- | ha | > skell.html#safe-language | > | > | > | > But this language on GNTD not being part of the safe language was | > removed in the 7.8 manual: | > | > | > | > https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_guide/safe- | ha | > skell.html#safe-language | > | > | > | > The GHC release notes don't say anything about this one way or the | other. | > Thoughts? | > | > | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs(a)haskell.org | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | >

1 0

ANN: exact-pi 0.1
by Douglas McClean 10 Apr '15

10 Apr '15

I'm announcing the release of the new exact-pi package. It provides a type that exactly represents all rational multiples of integer powers of pi. Because it's closed under multiplication and taking of reciprocals, it's useful for computing exact conversion factors between physical units. In order to provide full Num and Floating instances there is also a representation for approximate values. I'm not sure if this will be of use to anyone else, but it is nice and self-contained so I thought I would put it out there. -Doug McClean

3 3

PrimMonad for Control.Monad.ST.Lazy?
by Ken Takusagawa II 10 Apr '15

10 Apr '15

I notice that the strict ST monad has an instance for PrimMonad but the lazy ST monad does not. Is there a reason why, or is merely an oversight? (What I Am Really Trying To Do: get a purely lazy stream of random values out of mwc-random.) --ken

3 2

Cabal hell
by Patrick Redmond 09 Apr '15

09 Apr '15

Since learning Haskell I've had the pleasure of finding my way out of a cabal hell or two. I've developed some knowledge to cope with it [1], but mostly concluded that if I can avoid burdening my projects with dependencies that have many of their own dependencies, then cabal hell can be averted. This puts somewhat of a damper on the joy of haskell's composability. With the new release of GHC I've observed a flurry of discussion on haskell mailing lists and from Linux distro maintainers about all the fixing and patching required to keep the haskell ecosystem going. Meanwhile I've learned other languages and used other tools that don't seem to have this problem that haskell does. For example, in the elm-lang community the package management tool enforces strict api-versioning, and in the clojure ecosystem people talk about "repeatability" and achieve it by using mostly exact-version requirements, even including the language (the language version is a dependency of a project, rather than a constraint of the environment). I guess I'm wondering why we don't try something simpler to solve the haskell cabal hell problem. How about using minimum version dependencies only, not ranges, since we can't accurately guess about the future compatibility of our projects. How about automatic api-versioning of our projects to give the version numbers some rigid semantics with regard to package compatibility? [1] http://f06code.com/post/90205977959/cabal-usage-notes

3 5