On Thu, 2016-07-21 at 10:32 -0400, Gershom B wrote: > On July 21, 2016 at 8:51:15 AM, Yuras Shumovich (shumovi...@gmail.com > ) wrote: > > > > I think it is what the process should change. It makes sense to > > have > > two committees only if we have multiple language implementations, > > but > > it is not the case. Prime committee may accept or reject e.g. > > GADTs, > > but it will change nothing because people will continue using GADTs > > regardless, and any feature accepted by the Prime committee will > > necessary be compatible with GADTs extension. > > I disagree. By the stated goals of the H2020 Committee, if it is > successful, then by 2020 it will still for the most part have only > standardized ony a _portion_ of the extentions that now exist today.
Yes, I know. But don't you see how narrow the responsibility of the H2020 Committee is? GHC Committee makes all important decisions, and H2020 just collects some of GHC extensions into a set of "standard" ones. It is useful only when "nonstandard" extensions are not widely used (e.g. marked as experimental, and are not recommended for day-to- day use). > > There’s always been a barrier between implementation and standard in > the Haskell language, that’s precisely one of the things that _keeps_ > it from having become entirely implementation-defined despite the > prevelance of extensions. Unfortunately Haskell *is* implementation-defined language. You can't compile any nontrivial package from Hackage using Haskell2010 GHC. And the same will be true for Haskell2020. We rely on GHC-specific extensions everywhere, directly or indirectly. If the goal of the Haskell Prime is to change that, then the GHC-specific extensions should not be first class citizens in the ecosystem. Otherwise there is no sense in two committees. We can continue pretending that Haskell is standard-defined language, but it will not help to change the situation. > > Having two entirely different processes here (though obviously not > without communication between the individuals involved) helps > maintain that. > > —Gershom > > _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users