Re: Enabling TypeHoles by default
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Enabling TypeHoles by default
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 fuuze...@fuuzetsu.co.uk 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/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Enabling TypeHoles by default
-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- ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Enabling TypeHoles by default
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Enabling TypeHoles by default
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/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Enabling TypeHoles by default
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 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/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Enabling TypeHoles by default
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/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Enabling TypeHoles by default
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/ -- 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
Re: Enabling TypeHoles by default
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 signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Enabling TypeHoles by default
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 m...@joachim-breitner.dewrote: 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
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 johan.tib...@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 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/
Re: Enabling TypeHoles by default
On Tue, Jan 14, 2014 at 12:14 PM, Austin Seipp aus...@well-typed.com 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/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Enabling TypeHoles by default
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
Re: Enabling TypeHoles by default
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
Re: Enabling TypeHoles by default
I have to admit, I rather like this suggestion. -Edward On Mon, Jan 13, 2014 at 1:42 PM, Krzysztof Gogolewski krz.gogolew...@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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Enabling TypeHoles by default
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 ekm...@gmail.com написал(а): I have to admit, I rather like this suggestion. -Edward On Mon, Jan 13, 2014 at 1:42 PM, Krzysztof Gogolewski krz.gogolew...@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 ___ 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
Re: Enabling TypeHoles by default
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_agdalike_holes/c6gvy0r On Mon, Jan 13, 2014 at 8:03 PM, migmit mig...@gmail.com 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 ekm...@gmail.com написал(а): I have to admit, I rather like this suggestion. -Edward On Mon, Jan 13, 2014 at 1:42 PM, Krzysztof Gogolewski krz.gogolew...@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 ___ 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
Re: Enabling TypeHoles by default
+1. Will any freevariable be considered a type hole? Or just _blah and _ ? On Mon, Jan 13, 2014 at 2:07 PM, Erik Hesselink hessel...@gmail.com 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_agdalike_holes/c6gvy0r On Mon, Jan 13, 2014 at 8:03 PM, migmit mig...@gmail.com 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 ekm...@gmail.com написал(а): I have to admit, I rather like this suggestion. -Edward On Mon, Jan 13, 2014 at 1:42 PM, Krzysztof Gogolewski krz.gogolew...@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 ___ 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
Re: Enabling TypeHoles by default
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.schonw...@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 hessel...@gmail.comwrote: 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_agdalike_holes/c6gvy0r On Mon, Jan 13, 2014 at 8:03 PM, migmit mig...@gmail.com 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 ekm...@gmail.com написал(а): I have to admit, I rather like this suggestion. -Edward On Mon, Jan 13, 2014 at 1:42 PM, Krzysztof Gogolewski krz.gogolew...@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 ___ 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
Re: Enabling TypeHoles by default
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
Re: Enabling TypeHoles by default
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 fuuze...@fuuzetsu.co.uk 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
Re: Enabling TypeHoles by default
Heck if we wanted to bikeshed the name, even 'Holes' would do. ;) On Mon, Jan 13, 2014 at 4:30 PM, Daniil Frumin difru...@gmail.com 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 fuuze...@fuuzetsu.co.uk 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Enabling TypeHoles by default
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
