- ghc-devs - Haskell.org

RE: [GHC] #9858: Typeable instances should be kind-aware
by Simon Peyton Jones 13 May '15

13 May '15

Heads-up: this one changes interface file formats, so you need a clean build. Simon | -----Original Message----- | From: GHC [mailto:ghc-devs@haskell.org] | Sent: 13 May 2015 09:02 | Cc: ghc-tickets(a)haskell.org | Subject: Re: [GHC] #9858: Typeable instances should be kind-aware | | #9858: Typeable instances should be kind-aware | -------------------------------------+-------------------------------- | -- | -------------------------------------+--- | Reporter: dreixel | Owner: | Type: bug | Status: | closed | Priority: highest | Milestone: | 7.10.2 | Component: Compiler | Version: 7.9 | Resolution: fixed | Keywords: | Operating System: Unknown/Multiple | Architecture: | Type of failure: None/Unknown | Unknown/Multiple | Blocked By: | Test Case: | Related Tickets: | | typecheck/should_fail/T9858a,b,c; | | should_run/T9858b | | Blocking: | | Differential Revisions: | Phab:D652 | -------------------------------------+-------------------------------- | -- | -------------------------------------+--- | | Comment (by Simon Peyton Jones <simonpj@…>): | | In [changeset:"130e93aab220bdf14d08028771f83df210da340b/ghc"]: | {{{ | #!CommitTicketReference repository="ghc" | revision="130e93aab220bdf14d08028771f83df210da340b" | Refactor tuple constraints | | Make tuple constraints be handled by a perfectly ordinary type | class, with the component constraints being the | superclasses: | class (c1, c2) => (c2, c2) | | This change was provoked by | | #10359 inability to re-use a given tuple | constraint as a whole | | #9858 confusion between term tuples | and constraint tuples | | but it's generally a very nice simplification. We get rid of | - In Type, the TuplePred constructor of PredTree, | and all the code that dealt with TuplePreds | - In TcEvidence, the constructors EvTupleMk, EvTupleSel | | See Note [How tuples work] in TysWiredIn. | | Of course, nothing is ever entirely simple. This one proved quite | fiddly. | | - I did quite a bit of renaming, which makes this patch | touch a lot of modules. In partiuclar tupleCon -> tupleDataCon. | | - I made constraint tuples known-key rather than wired-in. | This is different to boxed/unboxed tuples, but it proved | awkward to have all the superclass selectors wired-in. | Easier just to use the standard mechanims. | | - While I was fiddling with known-key names, I split the TH Name | definitions out of DsMeta into a new module THNames. That meant | that the known-key names can all be gathered in PrelInfo, without | causing module loops. | | - I found that the parser was parsing an import item like | T( .. ) | as a *data constructor* T, and then using setRdrNameSpace to | fix it. Stupid! So I changed the parser to parse a *type | constructor* T, which means less use of setRdrNameSpace. | | I also improved setRdrNameSpace to behave better on Exact Names. | Largely on priciple; I don't think it matters a lot. | | - When compiling a data type declaration for a wired-in thing like | tuples (,), or lists, we don't really need to look at the | declaration. We have the wired-in thing! And not doing so avoids | having to line up the uniques for data constructor workers etc. | See Note [Declarations for wired-in things] | | - I found that FunDeps.oclose wasn't taking superclasses into | account; easily fixed. | | - Some error message refactoring for invalid constraints in | TcValidity }}} | | -- | Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9858#comment:114> | GHC <http://www.haskell.org/ghc/> | The Glasgow Haskell Compiler

1 0

RE: QRE: Cabal and simultaneous installations of the same package
by Simon Peyton Jones 12 May '15

12 May '15

Vishal Just to reiterate: I think it would be incredibly helpful to have a wiki page in which the proposed design is fleshed out in detail. The above is a start, but clearly I’m confused about many things. Lacking a concrete, well-specified design we risk repeating the same conversations. (I’m sure I have repeated above stuff that is well worn territory.) I urge you strongly to begin your project by writing out your proposed design, and seeking feedback from the community. Simon From: Vishal Agrawal [mailto:vishal4556@gmail.com] Sent: 12 May 2015 18:54 To: Simon Peyton Jones Cc: Boespflug, Mathieu; Gershom B; Mikhail Glushenkov; Duncan Coutts (duncan(a)well-typed.com) Ryan Trinkle; haskell-infrastructure(a)community.galois.com; cabal-devel(a)haskell.org; ghc-devs(a)haskell.org; Haskell Libraries Subject: Re: QRE: Cabal and simultaneous installations of the same package Yes, consistency means allowing only a single instance of a package in a environment. A environment is very cheap to create than sandbox. Like every time a package is imported in ghci, a new environment is created which includes all the earlier package and new package. Multiple environment can give sandbox for free. Single database will have many benefits, although I don't think it is requirement. I plan to move to single database somewhat in middle. On Tue, May 12, 2015 at 7:09 PM, Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: Enforcing consistency does have implications for the user interface. There will be situations where one wants to install a new package, but it is impossible to add it to the current environment while keeping all of the existing packages. Let’s see if I understand this correctly. I believe that Duncan/you envisage the following scenario: • Package database: you can install any package, compiled against any dependencies, without breaking anything. So the package database can contain multiple instances of P-2.3, compiled against different dependencies. • Environment. The “environment” maps a package name, such as “P-2.3” to a particular package instance in the database. When you say “ghc –c Foo.hs –package P”, the “-package 2.3” consults the environment to determine which of the many P-2.3 instances you might mean. Mind you, GHC’s new –package flag takes a package key (which identifies a unique package instance in the database). So I’m hazy about exactly when the environment is used. • You can in principle have many environments (akin to sandboxes) but only one database. There is a UI issue about how you define and maintain environments. • Duncan argues that, for predictability, every environment should be consistent. o I’m not sure exactly what “consistent” means. Can I have P-2.3 and P-2.4 in the same environment, or only one P (for a given package name P)? o Intuitively, though, “consistent” means that all packages in the environment are compatible; they won’t give rise to the confusing “P-2.3:M.T does not match P-2.4:M.T” errors. • The environment is irrelevant when cabal is installing a package,. Cabal just computes a set of consistent dependencies, installs any missing dependencies, and installs the package. So the environment only matters for explicit user –package flags. I think it would be incredibly helpful to have a wiki page in which the proposed design is fleshed out in detail. The above is a start, but clearly I’m confused about many things. Lacking a concrete, well-specified design we risk repeating the same conversations. (I’m sure I have repeated above stuff that is well worn territory.) Thanks! Simon From: Vishal Agrawal [mailto:vishal4556@gmail.com<mailto:vishal4556@gmail.com>] Sent: 11 May 2015 23:02 To: Simon Peyton Jones Cc: Boespflug, Mathieu; Gershom B; Mikhail Glushenkov; Duncan Coutts (duncan(a)well-typed.com<mailto:duncan@well-typed.com>); Ryan Trinkle; haskell-infrastructure(a)community.galois.com<mailto:haskell-infrastructure@community.galois.com>; cabal-devel(a)haskell.org<mailto:cabal-devel@haskell.org>; ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org>; Haskell Libraries Subject: Re: QRE: Cabal and simultaneous installations of the same package Thanks. I will start working on it soon. Currently I am having a great mentorship by Ryan Trinkle. We have talked a few times, mostly about the plan of the project. The main problem that can arise by the project is by enforcing consistency. It is already well documented by Duncan Coutts in a blog post from which I took most of the ideas from. http://www.well-typed.com/blog/2015/01/how-we-might-abolish-cabal-hell-part… > Enforcing consistency does have implications for the user interface. There will be situations where one wants to install a new package, but it is impossible to add it to the current environment while keeping all of the existing packages. For example, suppose we have two different web stacks that have many packages in common but that require different versions of some common package. In that case we could not have a consistent environment that contains both. Thus the user interface will have to do something when the user asks to add the second web stack to an environment that already contains the first. The user interface could minimise the problem by encouraging a style of use where most environments are quite small, but it cannot be avoided in general. > While what I am suggesting for consistency is relatively strong, we cannot get away without enforcing some restrictions on the environment. For example if our environment did contain two instances of the same version of a package then which one would we get when we launch GHCi? So my view is that given that we cannot avoid the user interface issues with environment consistency, it is better to go for the stronger and more useful form. I am little unsure about what other community members think about it, but there is an acceptance from Duncan Coutts. If consistency is not enforced, errors like ‘bytestring is not bytestring’ can increase many times after implementing persistent package store as there will be a larger pool of packages. If enforced, there might be situation where developer will not be able load two package at the same time which can earlier work at the same time. My personal preference is to enforce consistency. On 11-May-2015, at 9:47 pm, Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: Exactly! It’s so close! GHC has all the necessary infrastructure. All we need is for Cabal to recognise that it’s possible to install two instances of A-2.0. My fingers can almost touch it. Go Vishal! Simon From: Boespflug, Mathieu [mailto:m@tweag.io] Sent: 11 May 2015 16:42 To: Simon Peyton Jones; Gershom B; Mikhail Glushenkov; Duncan Coutts (duncan(a)well-typed.com<mailto:duncan@well-typed.com>); Ryan Trinkle; haskell-infrastructure(a)community.galois.com<mailto:haskell-infrastructure@community.galois.com>; cabal-devel(a)haskell.org<mailto:cabal-devel@haskell.org>; ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org>; Vishal Agrawal; Haskell Libraries Subject: Re: QRE: Cabal and simultaneous installations of the same package As I think Simon was saying earlier, think of this feature as allowing strictly more installation plans to succeed, while still keeping to the exact same model that we use today of just one instance of a lib in any given binary. Currently, if you install B-0.1 and then install A-2.0 that has a constraint B>=0.1, then you can't build an app that depends on both A and B-0.2. That's counter intuitive because had you started from an empty sandbox, then you would be able to build the app! The reason is that currently you can only have a single instance of A-2.0 installed. The proposal is *not* to allow building an app against an A-2.0 built against B-0.1 and against B-0.2 simultaneously. It's to allow multiple instances of A-2.0 in the same package database, and teach Cabal to handle that, so that an app can ask for an A-2.0 that is built against the right version of B, no matter what, and link that in. In your example, an app wouldn't get both C 1.0 and 2.0. It would get whichever one of those fits the constraints of both A and B, or the build will fail if no such C exists. Since only one instance of a library ever makes it into a binary, as is the case currently, no particular problem arises with linking in external dependencies such as C code. On 11 May 2015 at 14:52, Daniel Trstenjak <daniel.trstenjak(a)gmail.com<mailto:daniel.trstenjak@gmail.com>> wrote: Hi Simon, On Mon, May 11, 2015 at 11:27:58AM +0000, Simon Peyton Jones wrote: > Well, no one is actually suggesting that! But you're just getting it automatically if you're depending e.g. on the libraries A and B, and A depends on C 1.0 and B depends on C 2.0. Currently you can't build this dependency graph, right? And with this proposed feature you will be getting C 1.0 and 2.0 into your binary. Perhaps a even more nasty case is, if you're using a haskell library which wraps a stateful c library, and now you're having multiple versions of the same haskell library operating on the same c library state. Greetings, Daniel _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

1 0

RE: QRE: Cabal and simultaneous installations of the same package
by Simon Peyton Jones 12 May '15

12 May '15

Enforcing consistency does have implications for the user interface. There will be situations where one wants to install a new package, but it is impossible to add it to the current environment while keeping all of the existing packages. Let’s see if I understand this correctly. I believe that Duncan/you envisage the following scenario: · Package database: you can install any package, compiled against any dependencies, without breaking anything. So the package database can contain multiple instances of P-2.3, compiled against different dependencies. · Environment. The “environment” maps a package name, such as “P-2.3” to a particular package instance in the database. When you say “ghc –c Foo.hs –package P”, the “-package 2.3” consults the environment to determine which of the many P-2.3 instances you might mean. Mind you, GHC’s new –package flag takes a package key (which identifies a unique package instance in the database). So I’m hazy about exactly when the environment is used. · You can in principle have many environments (akin to sandboxes) but only one database. There is a UI issue about how you define and maintain environments. · Duncan argues that, for predictability, every environment should be consistent. o I’m not sure exactly what “consistent” means. Can I have P-2.3 and P-2.4 in the same environment, or only one P (for a given package name P)? o Intuitively, though, “consistent” means that all packages in the environment are compatible; they won’t give rise to the confusing “P-2.3:M.T does not match P-2.4:M.T” errors. · The environment is irrelevant when cabal is installing a package,. Cabal just computes a set of consistent dependencies, installs any missing dependencies, and installs the package. So the environment only matters for explicit user –package flags. I think it would be incredibly helpful to have a wiki page in which the proposed design is fleshed out in detail. The above is a start, but clearly I’m confused about many things. Lacking a concrete, well-specified design we risk repeating the same conversations. (I’m sure I have repeated above stuff that is well worn territory.) Thanks! Simon From: Vishal Agrawal [mailto:vishal4556@gmail.com] Sent: 11 May 2015 23:02 To: Simon Peyton Jones Cc: Boespflug, Mathieu; Gershom B; Mikhail Glushenkov; Duncan Coutts (duncan(a)well-typed.com) Ryan Trinkle; haskell-infrastructure(a)community.galois.com; cabal-devel(a)haskell.org; ghc-devs(a)haskell.org; Haskell Libraries Subject: Re: QRE: Cabal and simultaneous installations of the same package Thanks. I will start working on it soon. Currently I am having a great mentorship by Ryan Trinkle. We have talked a few times, mostly about the plan of the project. The main problem that can arise by the project is by enforcing consistency. It is already well documented by Duncan Coutts in a blog post from which I took most of the ideas from. http://www.well-typed.com/blog/2015/01/how-we-might-abolish-cabal-hell-part… > Enforcing consistency does have implications for the user interface. There will be situations where one wants to install a new package, but it is impossible to add it to the current environment while keeping all of the existing packages. For example, suppose we have two different web stacks that have many packages in common but that require different versions of some common package. In that case we could not have a consistent environment that contains both. Thus the user interface will have to do something when the user asks to add the second web stack to an environment that already contains the first. The user interface could minimise the problem by encouraging a style of use where most environments are quite small, but it cannot be avoided in general. > While what I am suggesting for consistency is relatively strong, we cannot get away without enforcing some restrictions on the environment. For example if our environment did contain two instances of the same version of a package then which one would we get when we launch GHCi? So my view is that given that we cannot avoid the user interface issues with environment consistency, it is better to go for the stronger and more useful form. I am little unsure about what other community members think about it, but there is an acceptance from Duncan Coutts. If consistency is not enforced, errors like ‘bytestring is not bytestring’ can increase many times after implementing persistent package store as there will be a larger pool of packages. If enforced, there might be situation where developer will not be able load two package at the same time which can earlier work at the same time. My personal preference is to enforce consistency. On 11-May-2015, at 9:47 pm, Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: Exactly! It’s so close! GHC has all the necessary infrastructure. All we need is for Cabal to recognise that it’s possible to install two instances of A-2.0. My fingers can almost touch it. Go Vishal! Simon From: Boespflug, Mathieu [mailto:m@tweag.io] Sent: 11 May 2015 16:42 To: Simon Peyton Jones; Gershom B; Mikhail Glushenkov; Duncan Coutts (duncan(a)well-typed.com<mailto:duncan@well-typed.com>); Ryan Trinkle; haskell-infrastructure(a)community.galois.com<mailto:haskell-infrastructure@community.galois.com>; cabal-devel(a)haskell.org<mailto:cabal-devel@haskell.org>; ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org>; Vishal Agrawal; Haskell Libraries Subject: Re: QRE: Cabal and simultaneous installations of the same package As I think Simon was saying earlier, think of this feature as allowing strictly more installation plans to succeed, while still keeping to the exact same model that we use today of just one instance of a lib in any given binary. Currently, if you install B-0.1 and then install A-2.0 that has a constraint B>=0.1, then you can't build an app that depends on both A and B-0.2. That's counter intuitive because had you started from an empty sandbox, then you would be able to build the app! The reason is that currently you can only have a single instance of A-2.0 installed. The proposal is *not* to allow building an app against an A-2.0 built against B-0.1 and against B-0.2 simultaneously. It's to allow multiple instances of A-2.0 in the same package database, and teach Cabal to handle that, so that an app can ask for an A-2.0 that is built against the right version of B, no matter what, and link that in. In your example, an app wouldn't get both C 1.0 and 2.0. It would get whichever one of those fits the constraints of both A and B, or the build will fail if no such C exists. Since only one instance of a library ever makes it into a binary, as is the case currently, no particular problem arises with linking in external dependencies such as C code. On 11 May 2015 at 14:52, Daniel Trstenjak <daniel.trstenjak(a)gmail.com<mailto:daniel.trstenjak@gmail.com>> wrote: Hi Simon, On Mon, May 11, 2015 at 11:27:58AM +0000, Simon Peyton Jones wrote: > Well, no one is actually suggesting that! But you're just getting it automatically if you're depending e.g. on the libraries A and B, and A depends on C 1.0 and B depends on C 2.0. Currently you can't build this dependency graph, right? And with this proposed feature you will be getting C 1.0 and 2.0 into your binary. Perhaps a even more nasty case is, if you're using a haskell library which wraps a stateful c library, and now you're having multiple versions of the same haskell library operating on the same c library state. Greetings, Daniel _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

1 0

QRE: Cabal and simultaneous installations of the same package
by Simon Peyton Jones 11 May '15

11 May '15

| But if multiple versions of the same library can be linked into one | binary, then the binary sizes will increase and therefore the memory | usage might increase and even performance might decrease a bit if the | number of cache misses increase. Well, no one is actually suggesting that! The #1 issue is that installing package P1, which depends on Q-3.4, should not break other package P2 that also depends on Q-3.4. Today it can break P2. And re-installing P2 can break P1. How does that happen? Q-3.4 depends on R 1.4-3.8 P1 depends on R-1.4 P2 depends on R-2.8 Then P1 needs Q-3.4 compiled against R-1.4 P2 needs Q-3.4 compiled against R-2.8 So the two can only co-exist if both instances of Q-3.4 can be simultaneously installed. None of this means that both instances of Q-3.4 need be part of the same executable. (That would be necessary if you wanted P1 and P2 in the same program; but maybe you don't.) They certainly could be, but allowing it has the disadvantages you describe. Simon | -----Original Message----- | From: Daniel Trstenjak [mailto:daniel.trstenjak@gmail.com] | Sent: 11 May 2015 12:05 | To: Simon Peyton Jones | Cc: Gershom B; Mikhail Glushenkov; Duncan Coutts (duncan@well- | typed.com) Ryan Trinkle; haskell-infrastructure(a)community.galois.com; | cabal-devel(a)haskell.org; ghc-devs(a)haskell.org; Vishal Agrawal; Haskell | Libraries | Subject: Re: Cabal and simultaneous installations of the same package | | | Hi Simon, | | > It is tantalising to me that something so critical has been so long | delayed. | > It’d be fantastic if it was done this summer. | | I'm just wondering what kind of negative side effects it might have. | | Sure, it will - most likely - make installing of cabal packages a lot | easier, especially for all non expert Haskell users. | | But if multiple versions of the same library can be linked into one | binary, then the binary sizes will increase and therefore the memory | usage might increase and even performance might decrease a bit if the | number of cache misses increase. | | It's certainly annoying to keep up with library updates, but in a way | it also pushes everyone forward to update their code bases, so if | everything just "works" - respectively is easy buildable - then this | force might be quite reduced. | | I'm just thinking e.g. of a case where you want to use at least a | certain version of a library, because you know of major | performance/bug fixes in this version, but now a considerable part of | your code base might use an older version of this library, because the | dependencies of your project haven't been updated. | | | Greetings, | Daniel

3 4

GHC Weekly News - 2015/05/11
by Austin Seipp 11 May '15

11 May '15

(This post is available online at https://ghc.haskell.org/trac/ghc/blog/weekly20150511) Hi *, It's been a few weeks since the last news bulletin - this is the result of mostly quietness on behalf of the list and developers, and some sickness on behalf of your editor for several days there. But now there's actually some things to write here! The past few weeks, GHC HQ has been having some quiet meetings mostly about bugfixes for a 7.10.2 release - as well as noodling about compiler performance. Austin has begun compiling his preliminary notes on the wiki, under the [wiki:CompilerPerformance] page, where we'll be trying to keep track of the ongoing performance story. Hopefully, GHC 7.12.1 will boast a bit better performance numbers. There are a lot of users who are interested in this particular pain point, so please file tickets and CC yourself on bugs (like #10370), or feel free to help out! == 7.10.2 status == There's been a bit of chatter about the lists about something on many peoples mind: the release of GHC 7.10.2. Most prominently, Mark Lentczner popped in to ask when the next GHC release will happen - in particular, he'd like to make a Haskell Platform release in lockstep with it (see below for a link to Mark's email). Until recently, the actual desire for 7.10.2 wasn't totally clear, and at this point, GHC HQ hasn't firmly committed to the 7.10.2 release date. But if milestone:7.10.2 is any indicator, we've already closed over three dozen bugs, several of them high priority - and they keep coming in. So it seems likely people will want these fixes in their hands relatively soon. Just remember: '''if you need a fix for 7.10.2''', or have a bug you need us to look at, please email the `ghc-devs` list, file a ticket, and get our attention! Just be sure to set the milestone to 7.10.2. == List chatter == - Herbert Valerio Riedel opened an RFC about a regression in GHC 7.10 relating to the update to Unicode 7. Any input from users of international languages or unicode users would be appreciated! https://mail.haskell.org/pipermail/ghc-devs/2015-May/008930.html - Herbert Valerio Riedel also asked about a new C pre-processor implementation for GHC - but in particular, adopting the extant `cpphs` into the GHC codebase for this task itself. https://mail.haskell.org/pipermail/ghc-devs/2015-May/008934.html - Austin Seipp emailed `ghc-devs` about the HCAR report, for which the GHC entry is due May 17th! Developers should get their edits in quickly. https://mail.haskell.org/pipermail/ghc-devs/2015-May/008939.html - Joachim Breitner asks if the branchless implementation for our literal cases are worth it for their complexity. There were some interesting responses, including some remarks on the V8 JavaScript compiler. https://mail.haskell.org/pipermail/ghc-devs/2015-April/008852.html - Niklas Hambüchen announced that he's backported the recent lightweight stack-trace support in GHC HEAD to GHC 7.10 and GHC 7.8 - meaning that users of these stable release can have informative call stack traces, even without profiling! FP Complete was interested in this feature, so they'd probably love to hear user input. https://mail.haskell.org/pipermail/ghc-devs/2015-April/008862.html - David Terei has written up a proposal on reconciling the existence of Roles with Safe Haskell, which caused us a lot of problems during the 7.8 release cycle. In particular, concerning the ability to break module abstractions and requiring programmers to safeguard abstractions through careful use of roles - and David's written a proposal to address that. https://mail.haskell.org/pipermail/ghc-devs/2015-April/008902.html - Mark Lentczner started a thread about the 7.10.2 release schedule - because this time, he wants to do a concurrent Haskell Platform release! The thread ended up with a good amount of discussion concerning if 7.10.2 is even needed - but at this rate, it looks like it will ship sometime soon. https://mail.haskell.org/pipermail/ghc-devs/2015-May/008904.html - Mateusz Kowalczyk posted to `ghc-devs` hoping to get some help with a tricky, long-standing issue: #4012, which concerns the determinism of GHC binaries. It turns out GHC isn't entirely deterministic when it calculates package IDs, meaning things get really bad when you mix prebuilt binary packages for systems. This in particular has become a real problem for the Nix package manager and users of Haskell applications. Mateusz asks if anyone would be willing to help look into it - and a lot of people would appreciate the help! https://mail.haskell.org/pipermail/ghc-devs/2015-May/008992.html == Noteworthy commits == - Commit f2d1b7fcbbc55e33375a7321222a9f4ee189aa38 - Support unboxing for GADT product types. - Commit 51af102e5c6c56e0987432aa5a21fe10e24090e9 - Better hints when RTS options are not available. - Commit 524ddbdad5816f77b7b719cac0671eebd3473616 - Make sure `GHC.List.last` is memory-efficient. - Commit a1275a762ec04c1159ae37199b1c8f998a5c5499 - Improve improvement in the constraint solver. - Commit 4efa421327cf127ebefde59b2eece693e37dc3c6 - Permit empty closed type families. - Commit 477f514f6ebcf783810da93e2191e4b6ea65559b - rts: add "-no-rtsopts-suggestions" option - Commit cf7573b8207bbb17c58612f3345e0b17d74cfb58 - More accurate allocation stats for :set +s - Commit c4e8097ea8dd6e43eae7aadd6bae7e13272ba74d - Bump base version to `4.8.2.0` - Commit 0bbc2ac6dae9ce2838f23a75a6a989826c06f3f5 - Use the gold linker for aarch64/linux (#9673) - Commit 1e8c9b81a819da8eb54405a029fc33a9f5220321 - Enable SMP and GHCi support for AArch64 == Closed tickets == #10293, #10273, #10021, #10209, #10255, #10326, #9745, #10314, #8928, #8743, #10182, #10281, #10325, #10297, #10292, #10304, #10260, #9204, #10121, #10329, #9920, #10308, #10234, #10356, #10351, #10364, #9564, #10306, #10108, #9581, #10369, #9673, #10288, #10260, #10363, #10315, #10389, #9929, #10384, #10382, #10400, #10256, #10254, #10277, #10299, #10268, #10269, #10280, #10312, #10209, #10109, #10321, #10285, #9895, #10395, #10263, #10293, #10210, #10302, #10206, #9858, #10045, and #9840. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal
by Daniel Trstenjak 11 May '15

11 May '15

Hi Wren, > Incidentally, if we really want to pursue the "get rid of CPP by > building it into the GHC distro"... > > In recent years there've been a number of papers on "variational > lambda-calculi"[1] which essentially serve to embed flag-based > preprocessor conditionals directly into the language itself. One major > benefit of this approach is that the compiler can then typecheck *all* > variations of the code, rather than only checking whichever particular > variation we happen to be compiling at the time. This is extremely > useful for avoiding bitrot in the preprocessor conditionals. > > ...If we were to try and obviate the dependency on CPP, variational > typing seems like a far more solid approach than simply reinventing > the preprocessing wheel yet again. (The downside, of course, is making > the Haskell spec significantly more complex.) I think even more beneficial than type checking all cases is the easier support for any Haskell tooling operating with the Haskell source if all cases are part of the AST. Greetings, Daniel

1 0

Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal
by Brandon Allbery 09 May '15

09 May '15

On Fri, May 8, 2015 at 7:40 PM, Donn Cave <donn(a)avvanta.com> wrote: > But fatal if compilation is conditional on something that affects the > ability to type check, am I right? Such as different compilers or > versions of same compiler. > Not per the abstract (paper itself seems to be paywalled). They had an earlier work with that issue, the linked one is about how to be robust in the face of such conditionals. -- brandon s allbery kf8nh sine nomine associates allbery.b(a)gmail.com ballbery(a)sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

1 1

Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal
by Dan Doel 08 May '15

08 May '15

vector generates a considerable amount of code using CPP macros. And with regard to other mails, I'm not too eager (personally) to port that to template Haskell, even though I'm no fan of CPP. The code generation being done is so dumb that CPP is pretty much perfect for it, and TH would probably just be more work (and it's certainly more work to write it again now that it's already written). On Wed, May 6, 2015 at 10:21 AM, Bardur Arantsson <spam(a)scientician.net> wrote: > On 06-05-2015 15:05, Alan & Kim Zimmerman wrote: > > Perhaps it makes sense to scan hackage to find all the different CPP > idioms > > that are actually used in Haskell code, if it is a small/well-defined set > > it may be worth writing a simple custom preprocessor. > > > > +1, I'll wager that the vast majority of usages are just for version > range checks. > > If there are packages that require more, they could just keep using the > system-cpp or, I, guess cpphs if it gets baked into GHC. Like you, I'd > want to see real evidence that that's actually worth the > effort/complication. > > Regards, > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >

1 0

Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal
by Malcolm Wallace 08 May '15

08 May '15

On 8 May 2015, at 00:06, Richard A. O'Keefe wrote: > I think it's important that there be *one* > "cpp" used by Haskell. fpp is under 4 kSLOC > of C, and surely Haskell can do a lot better. FWIW, cpphs is about 1600 LoC today. Regards, Malcolm

7 9

RE: [GHC] #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler
by Simon Peyton Jones 08 May '15

08 May '15

Edward (Yang) I'm on a train so can't say this on Trac. I'm OK with enabling quotes (*not* quasiquotes) in stage1. Both typed and untyped quotes should work, correct? I'd rather it was done by using TemplateHaskell, and complaining if you use splices or quasi-quotes in stage1. (That is very much what happens now.) No new flags. Could the user manual briefly mention this? (Briefly because most users won't even know what a stage1 compiler is.) Could you add a Note somewhere appropriate to explain this? Perhaps mention the ticket, because Edward K's motivation is useful. Refer to the Note anywhere appropriate. Go for it. Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org] On Behalf Of | GHC | Sent: 05 May 2015 16:06 | Cc: ghc-tickets(a)haskell.org | Subject: Re: [GHC] #10382: Template Haskell (non-quasi) quotes should | work with stage 1 compiler | | #10382: Template Haskell (non-quasi) quotes should work with stage 1 | compiler | -------------------------------------+----------------------------------- | -- | Reporter: ezyang | Owner: ezyang | Type: feature request | Status: new | Priority: normal | Milestone: 7.12.1 | Component: Template Haskell | Version: 7.11 | Resolution: | Keywords: | Operating System: Unknown/Multiple | Architecture: | Type of failure: None/Unknown | Unknown/Multiple | Blocked By: | Test Case: | Related Tickets: | Blocking: | | Differential Revisions: | Phab:D876 | -------------------------------------+----------------------------------- | -- | | Comment (by ekmett): | | The current situation: | | On one hand I have a number of packages that provide `TemplateHaskell` | convenience functions for users, `lens` being the go-to example. But on | the other hand, I have a bunch of folks who maintain releases for my | packages on platforms where only a stage1 compiler is available, Joachim | Breitner and the Debian folks used to maintain patches and versions of | my | code that removed large chunks of the libraries to build on those | platforms. | | When i found out, I offered to support stage1 compilers myself more | directly. This ensured a more uniform API, and that different | distributions weren't crippling my code in different ways, making it so | certain combinators or modules just weren't available on certain | platforms. | | But then we ran into an issue, we needed to generate names that linked | to | the right places within our code. So we manually construct all of our | names ourselves, using the cabal-supplied version number or package key | when needed: | | | https://github.com/ekmett/lens/blob/9a247b52ed20e578d9c843d8cc6dad5433a1c | 186/src/Control/Lens/Internal/TH.hs#L104 | | Then we just don't use the TemplateHaskell extension ourselves, despite | linking against the `template-haskell` package and everything is good | enough for us to limp along. | | I would love to eventually be able to drop this set of hoops, but I have | few opinions on the best way to get there. That said, Edward's | suggestion | of making TemplateHaskell just bomb when you reach a splice site in | stage1 | rather than immediately would avoid introducing any new flags and sounds | pretty simple. | | -- | Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10382#comment:6> | GHC <http://www.haskell.org/ghc/> | The Glasgow Haskell Compiler | _______________________________________________ | ghc-tickets mailing list | ghc-tickets(a)haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets

1 0