On Tue, May 3, 2016 at 2:12 AM, Andres Loeh <m...@andres-loeh.de> wrote: > 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 think they're feasible to specify in a sensible way. > > There are variations of these points (extensions that are perhaps > possible to specify, but ugly in their current form; extensions that > have subtle interactions with others; ...)
I agree that these two points are what we should really be focusing on (as well as things like ease of implementation), not just popularity. For example, much as I love GADTs and would be all for them being added in some future language report, I do not feel they should be added this time around. (Though I emphatically and wholeheartedly support adding GADTSyntax.) The primary reason being that while the semantics of the data types themselves is easy enough to define, there's no really sensible way of specifying how type inference should work for them. GHC has gone back and forth with a bunch of different inference methods over the years, and I don't think that's really stabilized yet; so basically we'd be stuck with (a) not giving any useful specification of what users can expect from inference / what implementors must provide to be considered "standards compliant", or (b) requiring some inference strategy that will stifle development rather than help it. Similarly, while TypeFamilies are fun to play with, I don't think they're ready for primetime either. While in theory they are equivalent to fundeps, in practice they're still playing catchup. Given the choice, I'd much rather see fundeps be added to the spec, where we make sure to phrase them in such a way that a viable implementation could consider fundep syntax to be syntactic sugar for some underlying story with TypeFamilies. —As for whether I'd actually be given that choice in the first place, I know there have been issues in the past about adding fundeps to the report. So far as I know, the main concern is that implementing them correctly is quite intricate (as also reflected in the intricacies of getting things like injectivity for TypeFamilies working). But, if we think it'd be a good idea to aim for getting some variant of type families into the standard in a future version, then the complexity of fundeps is already required (if we're to have a complete story for where TypeFamilies is currently headed). So adding fundeps now does help towards the eventual goal of adding type families; even if one day we think of fundeps as a funny syntactic sugar, like how some of us already consider the ADT syntax to be a funny syntactic sugar for the more straightforward GADTSyntax. > All this being said, I still have a personal list: > > BangPatterns > ConstrainedClassMethods > ConstraintKinds (?) > Derive* (?) > EmptyCase > ExistentialQuantification > ExplicitForAll > ExplicitNamespaces > ExtendedDefaultRules (?) > FlexibleContexts > FlexibleInstances > GADTSyntax > InstanceSigs > KindSignatures > NullaryTypeClasses > Overloaded* (?) > PartialTypeSignatures (?) > RankNTypes > ScopedTypeVariables > StandaloneDeriving (?) > TypeSynonymInstances > TypeOperators (?) > > I probably forgot a few. For the ones listed with (?), I am aware of > some problems, but I'd still be very happy to at least have some > discussions about them and make some progress in the direction of > future standardization, as I indicated above. Many of these are on my personal hit list as well. And most of the ones that aren't still seem fine to add; the exceptions being: TypeSynonymInstances — I'm not a fan of this extension since it means big warnings when teaching people Haskell (just getting them to recognize that type-synonyms are mere shorthands and not generative definitions is hard enough; any code using this extension requires them to recognize that sooner). Though it people really want it... ::shrug:: ExtendedDefaultRules — may be okay, but I haven't used/needed it so have never thought about it. FlexibleInstances — I like this and want something very much like it, but it's somewhat tricksy in practice so may need tweaking. In particular, I've typically found that non-linear use of type variables in the instance head is not in fact what people usually want/mean, and so when such instances are given it leads to usability issues re inference. Many times what is actually desired is to have a delayed unification constraint, e.g. @instance (i ~ j) => Monad (IContT i j m) where...@, where we first match the head (with only linear type variables) and then after we've committed to selecting this instance only then do we try to resolve the constraint. Even though the syntax here is suggestive, I think we should be able to get away with adding delayed unification constraints on instances without actually needing any other type equality stuff that GHC does. While the problems I've encountered with FlexibleInstances have mainly been due to non-linear type variables, I could also see these delayed unification constraints being helpful for the portion of FlexibleInstances which allows non-variables to occur in argument positions; again because matching on the top-level constructor of the instance head may be enough to help us ground out the arguments to that constuctor, and we really want to do that grounding after committing to using the instance rather than as part of deciding whether to use the instance or not. Overloaded* — If these are added I'd much rather have these as "standard language extensions", i.e., they would still need to be explicitly turned on, rather than being enabled everywhere. While it's nice to have these extensions available, I very seldom need them, and in light of that am a bit concerned about a backlash similar to the one with the FTP. Speaking of which, are things like the AMP and FTP under our purview or are they under the CLC? -- Live well, ~wren _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
