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 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 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 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 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 <
hvr@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 up so that people can start using the new 'TypedHoles' token in .cabal files... so there's a bit of coordination required to make Am Dienstag, den 14.01.2014, 11:12 -0600 schrieb Austin Seipp:
pick it
their
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
mail@joachim-breitner.de • http://www.joachim-breitner.de/
Jabber: nomeata@joachim-breitner.de • GPG-Key: 0x4743206C
Debian Developer: nomeata@debian.org _______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users