Re: Enabling TypeHoles by default

The program is still rejected with an error if _ occurs on the RHS, it's just a matter of what the compiler says in this specific case. $ cat test.hs module Main (main) where test :: a -> a test a = _ main = print $ test (10 :: Int) $ ./inplace/bin/ghc-stage2 test.hs [1 of 1] Compiling Main ( test.hs, test.o ) test.hs:4:10: Pattern syntax in expression context: _ $ ./inplace/bin/ghc-stage2 test.hs -XTypeHoles [1 of 1] Compiling Main ( test.hs, test.o ) test.hs:4:10: Found hole ‛_’ with type: a Where: ‛a’ is a rigid type variable bound by the type signature for test :: a -> a at test.hs:3:9 Relevant bindings include a :: a (bound at test.hs:4:6) test :: a -> a (bound at test.hs:4:1) In the expression: _ In an equation for ‛test’: test a = _ Named holes only occur when the name on the RHS is unbound and prefixed with _, as opposed to giving an undeclared identifier error. As Krzysztof mentioned originally, I find the first case to be pretty unlikely to occur regularly, even for newbies since wildcard patterns are 'de facto' on the LHS. Although perhaps it's an odd exception. If it's turned into a 'warning', my idea was just to turn -XTypeHoles to -Wtype-holes and turn it on by default, so this can be switched off. On Tue, Jan 14, 2014 at 12:04 PM, Johan Tibell wrote:

Stupid question: is it really only better error messages? What about being allowed to use _ on the RHS?

On Tue, Jan 14, 2014 at 6: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

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 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 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 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 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

_______________________________________________ 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/