Enabling TypeHoles by default

Krzysztof Gogolewski

13 Jan 2014 13 Jan '14

1:42 p.m.

Hello, As discussed on ghc-devs, I propose to enable -XTypeHoles in GHC by default. Rationale: (1) This way holes are far easier to use; just entering "_" allows to check type of a subexpression, no need of adding "-XTypeHoles". (2) This affects error messages only; i.e. the set of programs that compile stays the same - Haskell 2010. The only exception is that if you use -fdefer-type-errors, then a program with a hole compiles, but this seems fine with philosophy of -fdefer-type-errors. If so: would you like it to be in 7.8 or wait a cycle? My preference is 7.8, two people (John and Richard) suggested 7.10. -KG

Attachments:

attachment.html (text/html — 798 bytes)

Show replies by date

Edward Kmett

13 Jan 13 Jan

1:54 p.m.

I have to admit, I rather like this suggestion. -Edward On Mon, Jan 13, 2014 at 1:42 PM, Krzysztof Gogolewski < krz.gogolewski@gmail.com> wrote:

...

Hello,

As discussed on ghc-devs, I propose to enable -XTypeHoles in GHC by default. Rationale:

(1) This way holes are far easier to use; just entering "_" allows to check type of a subexpression, no need of adding "-XTypeHoles".

(2) This affects error messages only; i.e. the set of programs that compile stays the same - Haskell 2010. The only exception is that if you use -fdefer-type-errors, then a program with a hole compiles, but this seems fine with philosophy of -fdefer-type-errors.

If so: would you like it to be in 7.8 or wait a cycle? My preference is 7.8, two people (John and Richard) suggested 7.10.

-KG

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

migmit

2:03 p.m.

Agreed. Having it in 7.8 would be very nice, and yes, I don't see how it can break anything. Отправлено с iPad

...

13 янв. 2014 г., в 22:54, Edward Kmett написал(а):

I have to admit, I rather like this suggestion.

-Edward

...
On Mon, Jan 13, 2014 at 1:42 PM, Krzysztof Gogolewski wrote: Hello,

As discussed on ghc-devs, I propose to enable -XTypeHoles in GHC by default. Rationale:

(1) This way holes are far easier to use; just entering "_" allows to check type of a subexpression, no need of adding "-XTypeHoles".

(2) This affects error messages only; i.e. the set of programs that compile stays the same - Haskell 2010. The only exception is that if you use -fdefer-type-errors, then a program with a hole compiles, but this seems fine with philosophy of -fdefer-type-errors.

If so: would you like it to be in 7.8 or wait a cycle? My preference is 7.8, two people (John and Richard) suggested 7.10.

-KG

_______________________________________________ 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

Erik Hesselink

2:07 p.m.

I think that's a good idea. It was also suggested in a reddit thread [0] a year ago, and it doesn't seem like that thread has any arguments against it. Erik [0] http://www.reddit.com/r/haskell/comments/10u7xr/ghc_head_now_features_agdali... On Mon, Jan 13, 2014 at 8:03 PM, migmit wrote:

...

Agreed. Having it in 7.8 would be very nice, and yes, I don't see how it can break anything.

Отправлено с iPad

13 янв. 2014 г., в 22:54, Edward Kmett написал(а):

I have to admit, I rather like this suggestion.

-Edward

On Mon, Jan 13, 2014 at 1:42 PM, Krzysztof Gogolewski wrote:

...
Hello,

As discussed on ghc-devs, I propose to enable -XTypeHoles in GHC by default. Rationale:

(1) This way holes are far easier to use; just entering "_" allows to check type of a subexpression, no need of adding "-XTypeHoles".

(2) This affects error messages only; i.e. the set of programs that compile stays the same - Haskell 2010. The only exception is that if you use -fdefer-type-errors, then a program with a hole compiles, but this seems fine with philosophy of -fdefer-type-errors.

If so: would you like it to be in 7.8 or wait a cycle? My preference is 7.8, two people (John and Richard) suggested 7.10.

-KG

_______________________________________________ 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

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Carter Schonwald

2:11 p.m.

+1. Will any freevariable be considered a type hole? Or just _blah and _ ? On Mon, Jan 13, 2014 at 2:07 PM, Erik Hesselink wrote:

...

I think that's a good idea. It was also suggested in a reddit thread [0] a year ago, and it doesn't seem like that thread has any arguments against it.

Erik

[0] http://www.reddit.com/r/haskell/comments/10u7xr/ghc_head_now_features_agdali...

On Mon, Jan 13, 2014 at 8:03 PM, migmit wrote:

...
Agreed. Having it in 7.8 would be very nice, and yes, I don't see how it can break anything.

Отправлено с iPad

13 янв. 2014 г., в 22:54, Edward Kmett написал(а):

I have to admit, I rather like this suggestion.

-Edward

On Mon, Jan 13, 2014 at 1:42 PM, Krzysztof Gogolewski wrote:

...
Hello,

As discussed on ghc-devs, I propose to enable -XTypeHoles in GHC by default. Rationale:

(1) This way holes are far easier to use; just entering "_" allows to check type of a subexpression, no need of adding "-XTypeHoles".

(2) This affects error messages only; i.e. the set of programs that compile stays the same - Haskell 2010. The only exception is that if

you use

...
-fdefer-type-errors, then a program with a hole compiles, but this seems fine with philosophy of -fdefer-type-errors.

If so: would you like it to be in 7.8 or wait a cycle? My preference is 7.8, two people (John and Richard) suggested 7.10.

-KG

_______________________________________________ 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

_______________________________________________ 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

Krzysztof Gogolewski

2:18 p.m.

...

Will any freevariable be considered a type hole? Or just _blah and _ ? -XTypeHoles makes holes only out of _blah (where _blah is not in scope) and _.

On Mon, Jan 13, 2014 at 8:11 PM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

+1. Will any freevariable be considered a type hole? Or just _blah and _ ?

On Mon, Jan 13, 2014 at 2:07 PM, Erik Hesselink wrote:

...
I think that's a good idea. It was also suggested in a reddit thread [0] a year ago, and it doesn't seem like that thread has any arguments against it.

Erik

[0] http://www.reddit.com/r/haskell/comments/10u7xr/ghc_head_now_features_agdali...

On Mon, Jan 13, 2014 at 8:03 PM, migmit wrote:

...
Agreed. Having it in 7.8 would be very nice, and yes, I don't see how it can break anything.

Отправлено с iPad

13 янв. 2014 г., в 22:54, Edward Kmett написал(а):

I have to admit, I rather like this suggestion.

-Edward

On Mon, Jan 13, 2014 at 1:42 PM, Krzysztof Gogolewski wrote:

...
Hello,

As discussed on ghc-devs, I propose to enable -XTypeHoles in GHC by default. Rationale:

(1) This way holes are far easier to use; just entering "_" allows to check type of a subexpression, no need of adding "-XTypeHoles".

(2) This affects error messages only; i.e. the set of programs that compile stays the same - Haskell 2010. The only exception is that if

you use

...
-fdefer-type-errors, then a program with a hole compiles, but this seems fine with philosophy of -fdefer-type-errors.

If so: would you like it to be in 7.8 or wait a cycle? My preference is 7.8, two people (John and Richard) suggested 7.10.

-KG

_______________________________________________ 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

_______________________________________________ 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

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Mateusz Kowalczyk

3:54 p.m.

On 13/01/14 18:42, Krzysztof Gogolewski wrote:

...

Hello,

As discussed on ghc-devs, I propose to enable -XTypeHoles in GHC by default. Rationale:

(1) This way holes are far easier to use; just entering "_" allows to check type of a subexpression, no need of adding "-XTypeHoles".

(2) This affects error messages only; i.e. the set of programs that compile stays the same - Haskell 2010. The only exception is that if you use -fdefer-type-errors, then a program with a hole compiles, but this seems fine with philosophy of -fdefer-type-errors.

If so: would you like it to be in 7.8 or wait a cycle? My preference is 7.8, two people (John and Richard) suggested 7.10.

-KG

Sounds good. Are there plans to allow TypeHoles to actually sit in place of types? In the past I did ``` data Hole hole :: Hole hole = undefined foo :: Integer -> Integer foo x = hole bar :: Integer -> Hole bar x y = x + y ``` to cause type errors that could guide me. I now don't have to resort to the first use in ‘foo’ but I still have to define my own Hole type in ‘bar’. -- Mateusz K.

Daniil Frumin

4:30 p.m.

On ghc-dev Dominique Devriese has actually proposed changing TypeHoles to TypedHoles or to something similar, because "TypeHoles" sounds like you can have holes in types, just like in your example. But what error message do you want to get if you have a hole in your type? GHC won't be able to tell you much On Tue, Jan 14, 2014 at 12:54 AM, Mateusz Kowalczyk wrote:

...

On 13/01/14 18:42, Krzysztof Gogolewski wrote:

...
Hello,

As discussed on ghc-devs, I propose to enable -XTypeHoles in GHC by default. Rationale:

(1) This way holes are far easier to use; just entering "_" allows to check type of a subexpression, no need of adding "-XTypeHoles".

(2) This affects error messages only; i.e. the set of programs that compile stays the same - Haskell 2010. The only exception is that if you use -fdefer-type-errors, then a program with a hole compiles, but this seems fine with philosophy of -fdefer-type-errors.

If so: would you like it to be in 7.8 or wait a cycle? My preference is 7.8, two people (John and Richard) suggested 7.10.

-KG

Sounds good. Are there plans to allow TypeHoles to actually sit in place of types? In the past I did

``` data Hole

hole :: Hole hole = undefined

foo :: Integer -> Integer foo x = hole

bar :: Integer -> Hole bar x y = x + y ```

to cause type errors that could guide me. I now don't have to resort to the first use in ‘foo’ but I still have to define my own Hole type in ‘bar’.

-- Mateusz K. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

-- Sincerely yours, -- Daniil

Edward Kmett

4:32 p.m.

Heck if we wanted to bikeshed the name, even 'Holes' would do. ;) On Mon, Jan 13, 2014 at 4:30 PM, Daniil Frumin wrote:

...

On ghc-dev Dominique Devriese has actually proposed changing TypeHoles to TypedHoles or to something similar, because "TypeHoles" sounds like you can have holes in types, just like in your example.

But what error message do you want to get if you have a hole in your type? GHC won't be able to tell you much

On Tue, Jan 14, 2014 at 12:54 AM, Mateusz Kowalczyk wrote:

...
On 13/01/14 18:42, Krzysztof Gogolewski wrote:

...
Hello,

As discussed on ghc-devs, I propose to enable -XTypeHoles in GHC by default. Rationale:

(1) This way holes are far easier to use; just entering "_" allows to check type of a subexpression, no need of adding "-XTypeHoles".

(2) This affects error messages only; i.e. the set of programs that compile stays the same - Haskell 2010. The only exception is that if you use -fdefer-type-errors, then a program with a hole compiles, but this seems fine with philosophy of -fdefer-type-errors.

If so: would you like it to be in 7.8 or wait a cycle? My preference is 7.8, two people (John and Richard) suggested 7.10.

-KG

Sounds good. Are there plans to allow TypeHoles to actually sit in place of types? In the past I did

``` data Hole

hole :: Hole hole = undefined

foo :: Integer -> Integer foo x = hole

bar :: Integer -> Hole bar x y = x + y ```

to cause type errors that could guide me. I now don't have to resort to the first use in ‘foo’ but I still have to define my own Hole type in ‘bar’.

-- Mateusz K. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

-- Sincerely yours, -- Daniil _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Mateusz Kowalczyk

4:45 p.m.

On 13/01/14 21:30, Daniil Frumin wrote:

...

On ghc-dev Dominique Devriese has actually proposed changing TypeHoles to TypedHoles or to something similar, because "TypeHoles" sounds like you can have holes in types, just like in your example.

But what error message do you want to get if you have a hole in your type? GHC won't be able to tell you much

Indeed I have seen the ghc-devs post. Using Hole instead of stating a type is useful for me to me for two things: * Causing type errors for type of the expression, for example to specialise part of the signature and see what GHC infers for the rest of it * Easily checking types of the expressions I'm working on inside of the function. Sometimes one might lose track of types inside a larger expression and it is useful to cause a type error with a hole on one of the sub-expressions to see where we're at. GHCi doesn't provide a way to check type of subexpressions, only top-level definitions so this is particularly useful. While the second problem can be mitigated in simple situations where we have a single symbol expression such as foo :: Integer -> Integer foo x y = x + _y the ‘_’ does not work for larger expressions. For example, the following foo :: Integer -> Integer foo x y = x + _(y + 3) does not work as it actually gets translated to foo :: Integer -. Integer foo x y = x + _ (y + 3) and rather than get the type of (y + 3), we get the type of the function which takes that expression. Close but not quite. With _ for types I could do x + (y + 3 :: _) as opposed to data Hole x + (y + 3 :: Hole) It'd be great if I could spare myself defining Hole *and* get all the information about bindings that _ provides. -- Mateusz K.

Austin Seipp

14 Jan 14 Jan

11:07 a.m.

Hi all, As a follow up to these, Simon and I discussed it in a call today, and we're actually both in favor of enabling TypeHoles by default. The reasoning is as stated: it provides more useful error messages and doesn't cause any programs to fail to work. It's strictly a development aide when you have errors. 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. Unless anyone has any major objections, I'll probably implement this (as Krzysztof suggested in ghc-devs@) later today/tomorrow for the 7.8 branch. On Mon, Jan 13, 2014 at 3:45 PM, Mateusz Kowalczyk wrote:

...

On 13/01/14 21:30, Daniil Frumin wrote:

...
On ghc-dev Dominique Devriese has actually proposed changing TypeHoles to TypedHoles or to something similar, because "TypeHoles" sounds like you can have holes in types, just like in your example.

But what error message do you want to get if you have a hole in your type? GHC won't be able to tell you much

Indeed I have seen the ghc-devs post. Using Hole instead of stating a type is useful for me to me for two things:

* Causing type errors for type of the expression, for example to specialise part of the signature and see what GHC infers for the rest of it

* Easily checking types of the expressions I'm working on inside of the function. Sometimes one might lose track of types inside a larger expression and it is useful to cause a type error with a hole on one of the sub-expressions to see where we're at. GHCi doesn't provide a way to check type of subexpressions, only top-level definitions so this is particularly useful.

While the second problem can be mitigated in simple situations where we have a single symbol expression such as

foo :: Integer -> Integer foo x y = x + _y

the ‘_’ does not work for larger expressions. For example, the following

foo :: Integer -> Integer foo x y = x + _(y + 3)

does not work as it actually gets translated to

foo :: Integer -. Integer foo x y = x + _ (y + 3)

and rather than get the type of (y + 3), we get the type of the function which takes that expression. Close but not quite. With _ for types I could do

x + (y + 3 :: _)

as opposed to

data Hole x + (y + 3 :: Hole)

It'd be great if I could spare myself defining Hole *and* get all the information about bindings that _ provides.

-- Mateusz K. _______________________________________________ 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/

David Luposchainsky

11:14 a.m.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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? Greetings, David/quchen PS: +1 in general of course -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS1WJ7AAoJELrQsaT5WQUsoeQH/0vSEnyYLcAPk36sBaxf9EMb CNZM84lfnP1cgx9r0joM07iW6eA71kOnuAo0JzEOfJWJygkpoARpIJsmD0cvZdHX jibIXoiP2i50IYyMlHIoxsfQ5E4WgIsQuGQ200L5DgZuWWcgP7dk0f/AqnBeY8Mw RWd60Y5vpAOqNy2l5pw869KfVMOECKi+N2eD2UyUhbBrvs93QnCpeVrSpPNRjaoG Z7Z+rRyEGNDqoX88goOzBoxtmG/Ua6wuE6wq/bkmubCI5JE/kT+0upKeB3BfKOd1 kN72gbtAVJ+MumxAkncCk582QmcirlrbqS1ewL4xxRIEgdIqBlmTNyy6NGxB2vM= =16TU -----END PGP SIGNATURE-----

Herbert Valerio Riedel

11:27 a.m.

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

Austin Seipp

11:33 a.m.

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/

Richard Eisenberg

11:40 a.m.

Perhaps I'm being silly, but if the extended errors are enabled by default, and they seem to cause no problems, does the feature even need a name? The release notes could say something like "extended type information is produced for out-of-scope variables beginning with an underscore" or similar. Is it very important that users can specify -XNoTypeHoles? Richard On Jan 14, 2014, at 11:33 AM, 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/ _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Johan Tibell

11:44 a.m.

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

11:54 a.m.

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/

Austin Seipp

12:12 p.m.

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/

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

Joachim Breitner

12:23 p.m.

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

Johan Tibell

1:04 p.m.

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

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

Austin Seipp

1:14 p.m.

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/

Austin Seipp

1:17 p.m.

On Tue, Jan 14, 2014 at 12:14 PM, Austin Seipp wrote:

...

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.

... which, I might add, is rather the same for *all* warnings, so it's really more of a bikeshed of a slightly different color than anything. :) -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

Edward Kmett

2 p.m.

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

Austin Seipp

9:24 p.m.

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

Herbert Valerio Riedel

15 Jan 15 Jan

5:46 a.m.

On 2014-01-15 at 03:24:29 +0100, Austin Seipp wrote:

...

I'll submit a change to Cabal to remove its awareness of TypeHoles as an extension.

...actually, I forgot that 'TypeHoles' actually never made into Cabal when we added missing language-extensions tokens, as Duncan noticed in [1], that | We didn't add TypeHoles on the theory that it would not be used in | released packages. However on reflection it would be better to add it | as a registered extension but to have an explicit check for it not | being used in distributed packages (e.g. like we complain about | -Werror). Luckily, this turns my comments regarding updating Cabal & Hackage into a non-issue :-) [1]: https://ghc.haskell.org/trac/ghc/ticket/8176#comment:6 Cheers, hvr

4143

Age (days ago)

4145

Last active (days ago)

List overview

Download

24 comments

14 participants

participants (14)

Austin Seipp
Carter Schonwald
Daniil Frumin
David Luposchainsky
Duncan Coutts
Edward Kmett
Erik Hesselink
Herbert Valerio Riedel
Joachim Breitner
Johan Tibell
Krzysztof Gogolewski
Mateusz Kowalczyk
migmit
Richard Eisenberg