Oops. Resending to list: ----------------------------------- Right, same goes for every type error in that case though. (We also ban -fdefer-type-errors in the hackage server, FYI, so it's not like it can affect released code very much anyway.)
In light of this discussion I've made this change in 235fd88a9: https://github.com/ghc/ghc/commit/235fd88a9a35a6ca1aed70ff71291d7b433e45e4 I'll submit a change to Cabal to remove its awareness of TypeHoles as an extension. P.S. As I wrote this, I realize I should probably change it to -fwarn-typed-holes, as everyone seemed to have wanted... On Tue, Jan 14, 2014 at 1:00 PM, Edward Kmett <ekm...@gmail.com> wrote: > It actually can affect what code compiles with -fdefer-type-errors, but I > don't feel terribly strongly about that. > > -Edward > > > > > On Tue, Jan 14, 2014 at 12:23 PM, Joachim Breitner > <m...@joachim-breitner.de> wrote: >> >> Hi, >> >> heh, I wanted to throw in the same argument: If its just more elaborate >> error messages, why do we need a flag for it? So count that as +1 from >> me. >> >> Greetings, >> Joachim >> >> >> Am Dienstag, den 14.01.2014, 11:12 -0600 schrieb Austin Seipp: >> > I'm actually more in favor of Richard's proposal of just removing the >> > flag to be honest, now that he mentioned it. And it's not like it's >> > much more code. >> > >> > In any case, as Duncan informed me we'll have a Cabal release anyway, >> > so I'll work on sorting this out and enabling it. >> > >> > On Tue, Jan 14, 2014 at 10:54 AM, Duncan Coutts <dun...@well-typed.com> >> > wrote: >> > > On Tue, 2014-01-14 at 17:44 +0100, Johan Tibell wrote: >> > >> I can make another cabal release if needed, if someone submits a pull >> > >> request with the right fix (i.e. add TypedHoles with TypeHoles as a >> > >> synonym.) >> > > >> > > Thanks Johan, or I'm happy to do it. >> > > >> > > Duncan >> > > >> > >> On Tue, Jan 14, 2014 at 5:33 PM, Austin Seipp <aus...@well-typed.com> >> > >> wrote: >> > >> >> > >> > At the very least, Type(d)Holes would never appear explicitly since >> > >> > it >> > >> > would be enabled by default. But it might be turned off (but I >> > >> > don't >> > >> > know who would do that for the most part.) Cabal at least might >> > >> > still >> > >> > need an update. >> > >> > >> > >> > In any case, Herbert basically summed it up: the time window is >> > >> > kind >> > >> > of close, and we would need to re-release/redeploy a few things >> > >> > most >> > >> > likely. I really think it mostly depends on the Cabal team and what >> > >> > their priorities are. I've CC'd Duncan and Johan for their >> > >> > opinions. >> > >> > >> > >> > On Tue, Jan 14, 2014 at 10:27 AM, Herbert Valerio Riedel >> > >> > <h...@gnu.org> >> > >> > wrote: >> > >> > > Hi, >> > >> > > >> > >> > > On 2014-01-14 at 17:14:51 +0100, David Luposchainsky wrote: >> > >> > >> On 14.01.2014 17:07, Austin Seipp wrote: >> > >> > >>> We probably won't change the name right now however. It's >> > >> > >>> already >> > >> > >>> been put into Cabal (as a recognized extension,) so the name >> > >> > >>> has >> > >> > >>> propagated a slight bit. We can however give it a new name and >> > >> > >>> deprecate the old -XTypeHoles in the future. Or, we could >> > >> > >>> change >> > >> > >>> it, but I'm afraid it's probably a bit too late in the cycle >> > >> > >>> for >> > >> > >>> other devs to change. >> > >> > >> >> > >> > >> Removing a name later on is more time-consuming, with or without >> > >> > >> deprecation. People get used to the "wrong" name and stop >> > >> > >> caring, but >> > >> > >> I can already picture the "type holes are really typed holes" >> > >> > >> discussions on IRC. I'm strongly in favour of introducing the >> > >> > >> new name >> > >> > >> (and the deprecation for the synonym) as early as possible. This >> > >> > >> change should not be very extensive anyway, so why not slip it >> > >> > >> in? >> > >> > > >> > >> > > Well, as Austin hinted at, this would also require a Cabal-1.18.x >> > >> > > release in time for the final 7.8, and a recompile of Hackage to >> > >> > > pick it >> > >> > > up so that people can start using the new 'TypedHoles' token in >> > >> > > their >> > >> > > .cabal files... so there's a bit of coordination required to make >> > >> > > this >> > >> > > happen in a timely manner... Or put differently, somebody has to >> > >> > > care >> > >> > > enough to invest some time and pull this through :-) >> > >> > > >> > >> > > Cheers, >> > >> > > hvr >> > >> > > >> > >> > >> > >> > >> > >> > >> > >> > -- >> > >> > Regards, >> > >> > >> > >> > Austin Seipp, Haskell Consultant >> > >> > Well-Typed LLP, http://www.well-typed.com/ >> > >> > >> > > >> > > >> > > -- >> > > Duncan Coutts, Haskell Consultant >> > > Well-Typed LLP, http://www.well-typed.com/ >> > > >> > > >> > >> > >> > >> >> -- >> Joachim “nomeata” Breitner >> m...@joachim-breitner.de • http://www.joachim-breitner.de/ >> Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C >> Debian Developer: nome...@debian.org >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users