October 2013 - ghc-devs

Re: [commit: packages/stm] master: Refactor & update `stm.cabal` to `cabal-version>=1.10` (aa4774b)
by Simon Marlow 18 Oct '13

18 Oct '13

I'm not keen on losing the changelog from the description. The idea of having the changelog in the description is: - it is prominent on the Hackage page for the package - it's next to the version in the .cabal file, so you're more likely to update it when updating the version. I don't mind splitting it into two - maybe the first few entries in the description and the rest in a separate file, with a link from the description. Cheers, Simon On 14/10/2013 22:38, git(a)git.haskell.org wrote: > Repository : ssh://git@git.haskell.org/stm > > On branch : master > Link : http://git.haskell.org/packages/stm.git/commitdiff/aa4774b7d5f65cbf007803ff… > >> --------------------------------------------------------------- > > commit aa4774b7d5f65cbf007803ff54995921a36fbaeb > Author: Herbert Valerio Riedel <hvr(a)gnu.org> > Date: Mon Oct 14 22:02:35 2013 +0200 > > Refactor & update `stm.cabal` to `cabal-version>=1.10` > > As the current code fails to build with GHC 6.10, I've updated the Cabal > meta-data to declare support for GHC>=6.12 and dropped support for > base3. This also moves the changelog from the Cabal description field > into a separate `changelog` file and adds a few entries. > > The code compiles warning-free for all tested GHC versions. > > Signed-off-by: Herbert Valerio Riedel <hvr(a)gnu.org> > > >> --------------------------------------------------------------- > > aa4774b7d5f65cbf007803ff54995921a36fbaeb > Control/Concurrent/STM/TVar.hs | 5 -- > Control/Sequential/STM.hs | 18 ------- > changelog | 38 +++++++++++++++ > stm.cabal | 103 ++++++++++++++++++---------------------- > 4 files changed, 83 insertions(+), 81 deletions(-) > > diff --git a/Control/Concurrent/STM/TVar.hs b/Control/Concurrent/STM/TVar.hs > index d15896b..6435e17 100644 > --- a/Control/Concurrent/STM/TVar.hs > +++ b/Control/Concurrent/STM/TVar.hs > @@ -43,11 +43,6 @@ import GHC.Weak > import Control.Sequential.STM > #endif > > -#if ! (MIN_VERSION_base(4,2,0)) > -readTVarIO = atomically . readTVar > -#endif > - > - > -- Like 'modifyIORef' but for 'TVar'. > -- | Mutate the contents of a 'TVar'. /N.B./, this version is > -- non-strict. > diff --git a/Control/Sequential/STM.hs b/Control/Sequential/STM.hs > index 468e7bd..a644e67 100644 > --- a/Control/Sequential/STM.hs > +++ b/Control/Sequential/STM.hs > @@ -40,35 +40,17 @@ instance Monad STM where > x <- m r > unSTM (k x) r > > -#ifdef BASE4 > atomically :: STM a -> IO a > atomically (STM m) = do > r <- newIORef (return ()) > m r `onException` do > rollback <- readIORef r > rollback > -#else > -atomically :: STM a -> IO a > -atomically (STM m) = do > - r <- newIORef (return ()) > - m r `catch` \ ex -> do > - rollback <- readIORef r > - rollback > - throw ex > -#endif > > -#ifdef BASE4 > throwSTM :: Exception e => e -> STM a > -#else > -throwSTM :: Exception -> STM a > -#endif > throwSTM = STM . const . throwIO > > -#ifdef BASE4 > catchSTM :: Exception e => STM a -> (e -> STM a) -> STM a > -#else > -catchSTM :: STM a -> (Exception -> STM a) -> STM a > -#endif > catchSTM (STM m) h = STM $ \ r -> do > old_rollback <- readIORef r > writeIORef r (return ()) > diff --git a/changelog b/changelog > new file mode 100644 > index 0000000..1296a41 > --- /dev/null > +++ b/changelog > @@ -0,0 +1,38 @@ > +-*-changelog-*- > + > +2.4.2.1 Oct 2013 > + > + * Updated behaviour of `newBroadcastTChanIO` to match > + `newBroadcastTChan` in causing an error on a read from > + the broadcast channel > + > + * Add `mkWeakTVar` > + > + * Add `isFullTBQueue` > + > + * Fix `TChan` created via `newBroadcastTChanIO` to throw same > + exception on a `readTChan` as when created via `newBroadcastTChan` > + > +2.4.2 Nov 2012 > + > + * Add "Control.Concurrent.STM.TSem" (transactional semaphore) > + > + * Add Applicative/Alternative instances of STM for GHC <7.0 > + > + * Throw proper exception when `readTChan` called on a broadcast > + `TChan` > + > +2.4 Jul 2012 > + > + * Add "Control.Concurrent.STM.TQueue" (a faster `TChan`) > + > + * Add "Control.Concurrent.STM.TBQueue" (a bounded channel based on > + `TQueue`) > + > + * Add `Eq` instance for `TChan` > + > + * Add `newBroadcastTChan` and `newBroadcastTChanIO` > + > + * Some performance improvements for `TChan` > + > + * Add `cloneTChan` > diff --git a/stm.cabal b/stm.cabal > index 568b8a3..998bb24 100644 > --- a/stm.cabal > +++ b/stm.cabal > @@ -1,68 +1,55 @@ > -name: stm > +name: stm > version: 2.4.2.1 > -license: BSD3 > -license-file: LICENSE > -maintainer: libraries(a)haskell.org > -synopsis: Software Transactional Memory > +license: BSD3 > +license-file: LICENSE > +maintainer: libraries(a)haskell.org > +bug-reports: http://ghc.haskell.org/trac/ghc/newticket?component=libraries%20%28other%29… > +synopsis: Software Transactional Memory > category: Concurrency > -description: > - A modular composable concurrency abstraction. > - . > - Changes in version 2.4.2.1 > - . > - * Updated behaviour of @newBroadcastTChanIO@ to match > - @newBroadcastTChan@ in causing an error on a read from > - the broadcast channel. > - . > - Changes in version 2.4.2 > - . > - * Added "Control.Concurrent.STM.TSem" (transactional semaphore) > - . > - Changes in version 2.4.1 > - . > - * Added Applicative/Alternative instances of STM for GHC <7.0 > - . > - Changes in version 2.4 > - . > - * Added "Control.Concurrent.STM.TQueue" (a faster @TChan@) > - . > - * Added "Control.Concurrent.STM.TBQueue" (a bounded channel based on @TQueue@) > - . > - * @TChan@ has an @Eq@ instances > - . > - * Added @newBroadcastTChan@ and @newBroadcastTChanIO@ > - . > - * Some performance improvements for @TChan@ > - . > - * Added @cloneTChan@ > - > +description: A modular composable concurrency abstraction. > build-type: Simple > -cabal-version: >=1.6 > +cabal-version: >=1.10 > +tested-with: GHC==7.6.3, GHC==7.6.2, GHC==7.6.1, GHC==7.4.2, GHC==7.4.1, GHC==7.2.2, GHC==7.2.1, GHC==7.0.4, GHC==7.0.3, GHC==7.0.2, GHC==7.0.1, GHC==6.12.3 > + > +extra-source-files: > + changelog > > source-repository head > type: git > location: http://git.haskell.org/packages/stm.git > > -flag base4 > +source-repository this > + type: git > + location: http://git.haskell.org/packages/stm.git > + tag: stm-2.4.2.1-release > > library > - exposed-modules: > - Control.Concurrent.STM > - Control.Concurrent.STM.TArray > - Control.Concurrent.STM.TVar > - Control.Concurrent.STM.TChan > - Control.Concurrent.STM.TMVar > - Control.Concurrent.STM.TQueue > - Control.Concurrent.STM.TBQueue > - Control.Concurrent.STM.TSem > - Control.Monad.STM > - other-modules: > - Control.Sequential.STM > - build-depends: base < 5, array > - if flag(base4) > - build-depends: base >=4 > - cpp-options: -DBASE4 > - else > - build-depends: base <4 > - if impl(ghc >= 6.10) > - build-depends: base >=4 > + default-language: Haskell98 > + other-extensions: > + CPP > + DeriveDataTypeable > + FlexibleInstances > + MagicHash > + MultiParamTypeClasses > + UnboxedTuples > + if impl(ghc >= 7.2) > + other-extensions: Trustworthy > + > + build-depends: > + base >= 4.2 && < 4.8, > + array >= 0.3 && < 0.6 > + > + exposed-modules: > + Control.Concurrent.STM > + Control.Concurrent.STM.TArray > + Control.Concurrent.STM.TVar > + Control.Concurrent.STM.TChan > + Control.Concurrent.STM.TMVar > + Control.Concurrent.STM.TQueue > + Control.Concurrent.STM.TBQueue > + Control.Concurrent.STM.TSem > + Control.Monad.STM > + other-modules: > + Control.Sequential.STM > + > + ghc-options: -Wall > \ No newline at end of file > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

2 1

GHC October 2013 Status Report
by Austin Seipp 18 Oct '13

18 Oct '13

Hello friends, The new status report[1] is up. I've added to it over the past two weeks or so and I believe it is now rather complete. It's actually rather large, because we have a lot of new improvements! If you have 5 minutes, please take the time to read it over and let me know if I missed anything. Feel free to amend typos etc, should you be so inclined. :) [1] http://ghc.haskell.org/trac/ghc/wiki/Status/Oct13 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Non-escaping lets, join-points and binding updatability
by Jan Stolarek 17 Oct '13

17 Oct '13

Hi all, I'm trying to understand this: 1. Note [What is a non-escaping let] says that one of conditions of binding being a non-escaping let is non-updatability. 2. My understanding is that a if a binding has at least one parameter it is non-updatable, though I suspect that converse does not have to be true (lambdas) 3. Join-points are implemented using LNE bindings and I can imagine a join-points not having any parameters (and not being a lambda). Three points above seem inconsistent - where does my reasoning go wrong? I suspect that the Note might be wrong and an updatable binding can in fact be a LNE binding. Janek

4 5

Re: ghc-compete, a repository of fingerprints, and continuous integration
by Herbert Valerio Riedel 17 Oct '13

17 Oct '13

Hello Simon! On 2013-10-11 at 12:59:07 +0200, Simon Marlow wrote: [...] > This is great. With a bit of extra tool support for this we could > actually do without submodules and go back to individual > repos. Checking out a GHC revision in the past could consist of > querying your ghc-complete repo for the fingerprint and then running > the fingerprint tool. > > (unless you haven't guessed, I'm not a huge fan of submodules) What problems do you see with Git submodules specifically? I'm asking because I believe that we might be able address most of the concerns you have by tooling (e.g. by server-side hooks to enforce inter-repo invariants with respect to Git submodules, as well as client-side scripts to automate common developer tasks) so that the perceived pain of submodules can be reduced enough to make the change-function significantly more favorable for switching to Git submodules (+ folding some repos which are very tightly coupled/entangled to GHC into ghc.git itself, such as testsuite or nofib) Cheers, hvr

3 4

RE: small improvement to roles mechanism
by Simon Peyton-Jones 16 Oct '13

16 Oct '13

I think perhaps we are going a bit overboard here! Some thoughts: * Coercible is an experimental feature. If you don't use it, it won't hurt you. I don't think there is anything wrong with having signposted experimental features in a released compiler. And there is some merit: we will get useful feedback about the design from people who go ahead and use it anyway. (We did this for type functions a couple of releases ago.) I don't really understand what the suggestion "disallow Coercible" below means. * The open design issue for GND and for Coercible is the same. It is simply this: if s is coercible to t, is (T s) coercible to (T t)? By "coercible" I mean representationally-equivalent, ~R. For GND we ask this question about the types of class methods; in Coercible, it arises when simplifying Coercible constraints. But it is the same question. * The current proposal, which I am happy with, is to express the answer to this question in T's role annotation. There is design wiggle-room here: o If there is no user-supplied annotation, what should the default be? The inferred (lease-restrictive) role, or the Nominal (most restrictive) role? o How expressive is the role annotation language, especially where type constructors are concerned? So the design is not fully stable here, but I think the principle, that T's role ascription answers the question, is sound. * The current, fairly inexpressive role annotation language makes three Hackage packages (a tiny number) fail to compile because their use of GND is rejected. They have fairly few dependencies, so in all 18 packages break. Each of the three can be fixed with very modest changes. This does not sound like a lot of pain to me. That said, if you think it best, I'd be perfectly happy to make GND failure into a warning for one release cycle. (I wouldn't do that myself, but I'm quite willing to be guided on this one.) In short: * Coercible is opt-in anyway * If you prefer, GND failure can be a warning What's not to like? Am I missing anything? Simon From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Richard Eisenberg Sent: 12 October 2013 03:20 To: Edward Kmett Cc: Stephanie Weirich; Joachim Breitner; ghc-devs(a)haskell.org Devs Subject: Re: small improvement to roles mechanism I tend to agree with the above remarks and have been silencing the little voice in the back of my head that has suggested we pull roles out of 7.8. Ever since the debate about default roles vis-a-vis abstract datatypes started, I've been wondering if we're being a little hasty here. As we think about how to proceed, I think it's worth teasing apart the two different strains in all of this: enforcing type safety and enforcing abstraction. Roles, as they are, do a quite good job of enforcing type safety. When compiling all of Hackage, the majority of the breakage from roles was due to real type goofs in programs. A total of 18 packages (out of the 3,234 that compile with 7.6.3) fail to compile because of deficiencies in the role system, including transitive breakage (i.e., packages that depend on broken packages). A small change in the GND check discussed in this forum would fix 11 of these, leaving only 7. Given that type systems are necessarily conservative, I'm not too displeased with this result -- the 3 packages that would need to be changed would require only a few lines of code. Given this result, I disagree with Edward's claim that roles will provide the biggest pain in upgrading from 7.6 to 7.8. That said, I of course would like to do better and would prefer to 0 broken packages due to deficiencies in the role system. On the other hand, roles as they are do a poor job of enforcing abstraction. But, before roles came along, there wasn't anything resembling a way of enforcing abstraction in the context of GND. So, this isn't exactly a new problem. The only thing (I think) exacerbating the problem is that Coercible now makes it easier than ever to break abstraction. That said, I of course would like to fix this problem, too. So, how to proceed? There are a few options: 1. I'll change the GND check to be a little more liberal, and we release roles in 7.8. I could notify the authors of the three packages that need to be updated because of the lack of role abstraction. 2. Like #1, but disallow Coercible. This way, the abstraction problem is no worse than it was before. (Apologies to Joachim if he minds this suggestion.) 3. Pull roles out of 7.8, giving us a little more time to Get It Right. It's a little hard for me to choose between these options, but I think it's good to be conservative in language design of a language in real use, so I lean slightly toward option #3. Doing this is very feasible from a technical standpoint -- it's easy to turn off the checks. If we go with #3, given the flux in the design, I'm even uncertain about the idea of warnings in 7.8. It would all feel a little silly if we issue these warnings and then change the design between 7.8 and 7.10 just enough to make the warnings wrong. I think warnings in 7.8.2 is a better idea. As for Johan's remark that the feature should have been vetted more thoroughly -- I completely agree, and I'll take responsibility for that decision. I did do some ad-hoc testing against packages on Hackage known to use GND, but the testing was not as thorough as it could have been. That said, I'm not sure anything would have played out too differently had I done more extensive testing; the results were about as I expected. I do greatly appreciate everyone's feedback and interest in this! Richard On Oct 11, 2013, at 7:55 PM, Edward Kmett wrote: I have to agree that I'm somewhat disturbed by the fact that we're pushing this out and we're still finding issues with it this close to release. =( It strikes me that the role machinery is going to be the cause of the majority of the pain users have upgrading to 7.8, and if I try to pretend to be Mark Lentczner for a bit, it makes it seem highly likely that it'd be the kind of thing that keeps 7.8 from going into a Haskell Platform, causing the groundhog to see his shadow, leaving us with another year of 7.4 or 7.6.x. I know we're at the 5 yard line, but to metaphorically throw a bunch of metaphors in a blender, if we had to make the uncomfortable decision to perform triage and ask if it should be put off (at least enforcing) the roles machinery to 7.10, so we can know we have it right, how much fallout would there be? Off the top of my head, of course Joachim's work on Coercible would be affected. What else? One option might be to pull the teeth of role inference for 7.8 with regards to GND, and turn bad roles use into a warning for a release cycle. That would give the community a year to get role annotations in place before generalized newtype deriving for their code just stopped working. If we ship with this the way it stands, I don't foresee the community reaction being good. With its teeth pulled, then GND could proceed as before, but with the added detailed warnings from the dictionary coercions helping to guide folks to make the change. By the time we'd be enforcing correct role annotations most folks would have them in place to silence the warnings. -Edward On Fri, Oct 11, 2013 at 7:15 PM, Johan Tibell <johan.tibell(a)gmail.com<mailto:johan.tibell@gmail.com>> wrote: Oh and let me add: it would have been nice to have the people actually making these change to have done an impact analysis on Hackage, instead of discovering potential issues a week or two before the release. Lets try to do that next time. On Fri, Oct 11, 2013 at 4:14 PM, Johan Tibell <johan.tibell(a)gmail.com<mailto:johan.tibell@gmail.com>> wrote: Let me start by saying that I'm happy we're trying to fix the GND problem. Thanks for working on that. That being said: is this ready for mainstream consumption? We're forcing this on everyone without any language pragma or flags to opt-in/out. That is bad if we're not sure we're doing the right thing in some cases or if we're causing spurious failures. At ICFP I got the impression that very few people will be affected, but Bryan's result suggests there are more people than I thought. On Thu, Oct 10, 2013 at 8:26 PM, Richard Eisenberg <eir(a)cis.upenn.edu<mailto:eir@cis.upenn.edu>> wrote: In Bryan's recent test of GHC 7.8 against all of Hackage, there were three spurious errors caused by lack of role abstraction. Here are the class definitions where a nominal parameter is inferred, probably against the wishes of the author: from logict-0.2.3/Control.Monad.Logic.Class: > class (MonadPlus m) => MonadLogic m where > msplit :: m a -> m (Maybe (a, m a)) from monadLib-3.5.2/MonadLib: > class (Monad m) => ReaderM m i | m -> i where > ask :: m i from base/Control.Arrow: > class Arrow a => ArrowApply a where > app :: a (a b c, b) c In each of these, the last parameter of the class is given a nominal role because it appears as the parameter of a type variable. However, in each case, it appears as the parameter of a *class* type variable. This means that, if we somehow knew that the class author wanted the class to be usable with GND, we could simply check every instance declaration for that class to make sure that the relevant concrete instantiation has the right role. For example, when the user writes, for example > instance ArrowApply Foo where ... we check that Foo's first parameter has a representational role. If it doesn't, then the instance is rejected. An alternative, somewhat heavier idea would be to represent roles as class constraints. We could have > class NextParamNominal (c :: k) > class NextParamRepresentational (c :: k) GHC could "generate" instances for every datatype definition. For example: > type role Map nominal representational > data Map k v = ... would induce > instance NextParamNominal Map > instance NextParamRepresentational (Map k) Users would not be able to write these instances -- they would have to be generated by GHC. (Alternatively, there could be no instances, just a little magic in the constraint solver. Somewhat like Coercible.) Then, the classes above would just have to add a superclass, like this: > class (Arrow a, NextParamRepresentational a) => ArrowApply a where > app :: a (a b c, b) c The role inference mechanism would be made aware of role constraints and use this one to derive that ArrowApply is OK for GND. This "heavier" approach has a similar upshot to the first idea of just checking at instance declarations, but it is more customizable and transparent to users (I think). I'm not sure I'm advocating for this change (or volunteering to implement before the release candidate), but I wanted to document the idea and get any feedback that is out there. This would fix the breakage we've seen without totally changing the kind system. Thanks, Richard PS: Due credit is to migmit for suggesting the type-class idea on glasgow-haskell-users. _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> http://www.haskell.org/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> http://www.haskell.org/mailman/listinfo/ghc-devs

4 5

Back to explicit Coercible instances?
by Joachim Breitner 16 Oct '13

16 Oct '13

Hi, the recent discussion about roles and abstraction lets me wonder whether we should re-evaluate the question of where the Coercible instances come from. Currently, upon use of "coerce", GHC will create Coercible instances out of thin air, as long as the roles agree, and checking some constructor-in-scope invariants. This is troublesome WRT. abstraction. One alternative that was discussed before is explicit Coercible instances. That is, if I write a datatype datatype MyList a = Cons a (MyList a) | MyNil then I have to explicitly write either deriving Coercible to get instance Coercible a b => Coercible (MyList a) (MyList b) or – especially if I want to control which parameters are coercible – have to use standalone deriving and write deriving instance Coercible a b => Coercible (MyList a) (MyList b) For something like Set, the user would not use “deriving Coercible”, but would use deriving instance Coercible a b => Coercible (Set k a) (Set k b) Manual instances of Coercible would be prohibited. The instances are checked for things like: * do the roles allow the behaviour? * are the constructors in scope (for standalone deriving)? * are the arguments of the constructors coercible? The last check ensures that the user cannot break abstraction by wrapping an abstract datatype in a datatype of its own. But note that these instances (between the datacon argument types) are only checked, never actually used! Therefore we must sure that only sound instances exists, and that the user cannot bogus instances (e.g. one with all fields undefined). This would imply a few differences: * Already for syntactical reasons, there will be no instances for coercing constraints. As we have seen, this is a good thing. * Would be no way to use a coercion within the abstraction boundaries, but not outside, because you either have the instance, or you don’t. And assuming GND would simply implement its classes by passing each method through "coerce", this would hopefully also yield a sensible design for GND. Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata(a)debian.org

3 4

Re: Proposal: GHC.Generics marked UNSAFE for SafeHaskell
by José Pedro Magalhães 16 Oct '13

16 Oct '13

Hi, On Mon, Oct 7, 2013 at 10:32 AM, Dag Odenhall <dag.odenhall(a)gmail.com>wrote: > Here‘s a thought: doesn’t Generic already have an unused phantom type > that's only there “just in case we need to add something in the future”? > No, it doesn't. Just a thought: what if we had a type family type family Derives (t :: k1) (c :: k2) :: Bool which would automatically be instantiated by GHC appropriately? E.g., if the user had the following code: data MyData = MyData deriving (Eq, Generic) deriving instance Show MyData instance Ord MyData GHC would automatically instantiate: type instance Derives MyData Eq = True type instance Derives MyData Generic = True type instance Derives MyData Show = True type instance Derives MyData Ord = False Would this be something Ryan could use for detecting safe instances for LVish? Cheers, Pedro

5 7

Status update on overloaded records work?
by Johan Tibell 16 Oct '13

16 Oct '13

Hi, I'm curious about the current status of the overloaded records work. Is the design the same as when the project started? Did we manage to keep the types simple? -- Johan

4 8

Re: Status update on overloaded records work?
by Adam Gundry 16 Oct '13

16 Oct '13

Hi Johan, all, Thanks for the interest in OverloadedRecordFields! I've been meaning to write a blog post on the current status, but you've beaten me to it. The extension is essentially finished, modulo a few minor issues that I need to work through, and should hit HEAD soon after 7.8 is cut. That will give us time to experiment with the feature before it goes public in 7.10. As AntC says, the wiki has more detail on the design. I've just updated it with some recent tweaks (thanks to Edward and Simon brainstorming at ICFP). You can also try out the prototype (which works in 7.6.3): https://github.com/adamgundry/records-prototype/blob/master/RecordsPrototyp… Adam On 16/10/13 07:19, Simon Peyton-Jones wrote: > Looping in Adam Gundry, who did the work! > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of AntC > | Sent: 15 October 2013 22:42 > | To: ghc-devs(a)haskell.org > | Subject: Re: Status update on overloaded records work? > | > | > Johan Tibell <johan.tibell@...> writes: > | > > | > I'm curious about the current status of the overloaded records work. > | > | Hi Johan, I think Adam has documented as he's gone along: > | http://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Pla > | n > | (And that points to implementation notes.) > | > | I'll leave Adam/Simon to comment more fully, but from my point of view > | as > | an observer with some 'skin in the game' ... > | > | > Is the design the same as when the project started? > | > | No: > | - Higher-Ranked types can't be supported > | -- and SPJ's initial proposal put a lot of weight on them. > | There's an easy (IMO) work-round; > | but it does compromise backward compatibility. > | + Type changing update _is_ supported (with limits) > | I think that was a justified trade-off for H-R types. > | + Adam has been able to support Lenses. > | > | - (What I was hoping for but didn't get.) > | No compiler flag to suppress creating selector functions. > | This would have allowed records to be declared re-using the same > | name; > | but left it entirely to the developer as to how to access them. > | (I was trying to promote the TH and/or Lenses cottage industries.) > | > | > Did we manage to keep the types simple? > | > | I guess simplicity is in the eye of the beholder ;-) > | For 'gettable' fields, the sugar is as per SPJ's suggestion. > | There isn't sugar for updating. > | > | The un-sugared types are pretty gnarly. > | I suspect that'll mean obscure and confusing error messages. > | > | > | AntC -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Cabal-1.18.1.1 released
by Johan Tibell 16 Oct '13

16 Oct '13

I've released Cabal-1.18.1.1, which requires the fixes needed for the GHC 7.8 release. Please update the submodule to point to the Cabal-v1.18.1.1 tag. -- Johan

2 1