Enabling TypeHoles by default
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
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: TypeHoles behaviour
I have also seen this behaviour and support the change. -KG 2013/8/27 Austin Seipp ase...@pobox.com I'm +1 on changing the behavior. I find it probably the most confusing aspect of using TypeHoles, which is otherwise great. On Tue, Aug 27, 2013 at 3:17 AM, Simon Peyton-Jones simo...@microsoft.com wrote: I'm sympathetic to Andres's point here. Easy to implement. Any objections? Simon | -Original Message- | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- | boun...@haskell.org] On Behalf Of Andres Löh | Sent: 23 August 2013 21:02 | To: glasgow-haskell-users@haskell.org | Subject: TypeHoles behaviour | | Hi. | | I've just started playing with TypeHoles. (I'm writing some Haskell | course | materials and would like to use them from the very beginning once they | become | available.) | | However, I must say that I don't understand the current notion of | relevance | that seems to determine whether local bindings are included or not. | | The current rule seems to be that bindings are included only if the | intersection between the type variables their types involve and the type | variables in the whole is non-empty. However, I think this is confusing. | | Let's look at a number of examples: | | f1 :: Int - Int - Int | f1 x y = _ | | Found hole '_' with type: Int | In the expression: _ | In an equation for 'f1': f1 x y = _ | | No bindings are shown. | | f2 :: a - a - a | f2 x y = _ | | Found hole '_' with type: a | Where: 'a' is a rigid type variable bound by |the type signature for f2 :: a - a - a at List.hs:6:7 | Relevant bindings include | f2 :: a - a - a (bound at List.hs:7:1) | x :: a (bound at List.hs:7:4) | y :: a (bound at List.hs:7:6) | In the expression: _ | In an equation for 'f2': f2 x y = _ | | Both x and y (and f2) are shown. Why should this be treated differently | from f1? | | f3 :: Int - (Int - a) - a | f3 x y = _ | | Found hole '_' with type: a | Where: 'a' is a rigid type variable bound by |the type signature for f3 :: Int - (Int - a) - a at | List.hs:9:7 | Relevant bindings include | f3 :: Int - (Int - a) - a (bound at List.hs:10:1) | y :: Int - a (bound at List.hs:10:6) | In the expression: _ | In an equation for 'f3': f3 x y = _ | | Here, y is shown, but x isn't, even though y has to be applied to an Int | in order to produce an a. Of course, it's possible to obtain an Int from | elsewhere ... | | f4 :: a - (a - b) - b | f4 x y = _ | | Found hole '_' with type: b | Where: 'b' is a rigid type variable bound by |the type signature for f4 :: a - (a - b) - b at | List.hs:12:7 | Relevant bindings include | f4 :: a - (a - b) - b (bound at List.hs:13:1) | y :: a - b (bound at List.hs:13:6) | In the expression: _ | In an equation for 'f4': f4 x y = _ | | Again, only y is shown, and x isn't. But here, the only sane way of | filling | the hole is by applying y to x. Why is one more relevant than the | other? | | f5 x y = _ | | Found hole '_' with type: t2 | Where: 't2' is a rigid type variable bound by | the inferred type of f5 :: t - t1 - t2 at List.hs:15:1 | Relevant bindings include | f5 :: t - t1 - t2 (bound at List.hs:15:1) | In the expression: _ | In an equation for 'f5': f5 x y = _ | | Neither x and y are included without a type signature. Even though all | of | the above types are admissible, which would convince GHC that one or | even | all may be relevant. | | IMHO, this isn't worth it. It's a confusing rule. Just include all local | bindings | in the output, always. That's potentially verbose, but easy to | understand. It's | also potentially really helpful, because it trains beginning programmers | to see | what types local variables get, and it's a way to obtain complex types | of locally | bound variables for expert programmers. It's also much easier to | explain. It | should be easier to implement, too :) | | Could we please change it? | | Cheers, | Andres | | -- | Andres Löh, 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Regards, Austin - PGP: 4096R/0x91384671 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org
Re: implicit params in instance contexts
GHC ticket:
http://ghc.haskell.org/trac/ghc/ticket/7624
2013/7/16 Ganesh Sittampalam gan...@earth.li
Hi,
It seems that from GHC 7.4, the prohibition on implicit parameter
constraints in instance declarations has been relaxed. The program below
gives the error Illegal constraint ?fooRev::Bool in GHC 7.2.1 but
loads fine in GHC 7.4.2 and GHC 7.6.2.
I can't spot anything about this in the release notes, and the
documentation
(
http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/other-type-extensions.html#idp49069584
)
still says You can't have an implicit parameter in the context of a
class or instance declaration.
So I wonder if this happened by accident, perhaps as part of the
ConstraintKinds work or similar?
I've wanted this feature a few times so if it's going to stay I might
start using it. However it is a bit dangerous, so if it was added by
accident it might warrant some discussion before deciding to keep it.
For example as the value set2 below shows, it can be used to violate
datatype invariants.
Cheers,
Ganesh
{-# LANGUAGE ImplicitParams #-}
module Ord where
import Data.Set ( Set )
import qualified Data.Set as Set
newtype Foo = Foo Int
deriving (Eq, Show)
instance (?fooRev :: Bool) = Ord Foo where
Foo a `compare` Foo b =
if ?fooRev then b `compare` a else a `compare` b
set1 = let ?fooRev = False in Set.fromList [Foo 1, Foo 3]
set2 = let ?fooRev = True in Set.insert (Foo 2) set1
-- Ord set2
-- fromList [Foo 2,Foo 1,Foo 3]
___
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
