Enabling TypeHoles by default

Tue Jan 14 18:14:26 UTC 2014

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 <johan.tibell at gmail.com> 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 <mail at 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 <duncan at 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 <austin at 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
>> > >> > <hvr at 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
>>   mail at joachim-breitner.de • http://www.joachim-breitner.de/
>>   Jabber: nomeata at joachim-breitner.de  • GPG-Key: 0x4743206C
>>   Debian Developer: nomeata at debian.org
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/