Hi.
Just to add a few general points. There are different dimensions to
evaluate GHC extensions for inclusion in the standard, and just making
lists does not really reflect that. The two most important ones, I
think, are:
1. Whether we think they're actually a good idea or not.
2. Whether we thi
On 02/05/2016, Cale Gibbard wrote:
> Are there extensions which ought to stop being extensions?
> It may also be best to leave the answer up to the implementations. It is much
> easier to argue for something like that once the extension has been on by
> default in GHC and all other implementation
This question implicitly has two parts:
1) Are there GHC extensions which the Report ought to describe in their
entirety? To this question, I would say "yes" - pretty much anything which
can be done in that direction will be productive, it's more a question of
what people are willing to put the wo
I agree that GHC extensions should be the starting point for new additions, as
changes to the report should be based on established implementations (to ensure
that changes are implementable and to ensure that they work out well for users).
1) background reading
There were a few interesting thre
IMO, the committee should not focus on most these at the moment,
because there are easier wins to be had - most of the open proposed
ones have problems that make the discussion veer from "Very Obvious"
to "Not so obvious". I know they're popular, but doing this is going
to require a lot more discus
Doh, left off MultiParamTypeClasses from the list in the email. Though, as
Richard mentions, apparently this should be carefully considered with
regards to coherence.
On Mon, May 2, 2016 at 7:41 PM, Michael Sloan wrote:
> In this issue on the hpack tracker, I describe my swing at coming up with
In this issue on the hpack tracker, I describe my swing at coming up with a
conservative set of extensions:
https://github.com/sol/hpack/issues/94
The list I ended up with is:
LambdaCase, GADTSyntax, ScopedTypeVariables, TupleSections, BangPatterns,
FlexibleInstances, FlexibleContexts, MultiWayI
Great questions. Here's my take:
For something to be incorporated into the standard, we'd need to be able to
give a concrete, precise description of how the extension changes the set of
correct Haskell programs. We also need to consider how the extension changes
properties of the language, like
One objective would be to compile the Haskel Platform with near zero
extensions.
On Monday, May 2, 2016 5:57 PM, John Wiegley wrote:
I wonder if there are GHC extensions we'd like to promote as features in the
next report, as a starting point for discussing new additions.
There are a f
I wonder if there are GHC extensions we'd like to promote as features in the
next report, as a starting point for discussing new additions.
There are a few GHC features that have become part of the regular Haskell
landscape, such that it's hard to imagine a modern Haskell without them. For
example
10 matches
Mail list logo
