RE: Concrete syntax for open type kind?

2014-04-21 Thread Simon Peyton Jones
Is it possible to do so with any sort of concrete syntax? I’m afraid not. And I’m strongly disinclined to add it because we’d then just delete it again. Are you really really stuck? S From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Conal Elliott

Tightening up on inferred type signatures

2014-04-21 Thread Simon Peyton Jones
Friends GHC generally obeys this rule * If GHC infers a type f::type, then it's OK for you to add a type signature saying exactly that. For example, it rejects inferred types that are ambiguous. I think this is a good property; it was certainly the source of many bug reports before

Re: [core libraries] Tightening up on inferred type signatures

2014-04-21 Thread Edward Kmett
No objections here. The types involved really *do* have FlexibleContexts in them, so it makes sense to require the extension. The upgrade path for library authors is also clear. It'll complain to add the extension, and they'll fix it by adding the line of code suggested and perhaps realize

Re: Concrete syntax for open type kind?

2014-04-21 Thread Conal Elliott
Thanks, Simon. I wouldn’t say that I’m really really stuck yet, and I’d rather no one wasted time on a dead-end workaround. I like the plan you described using kind polymorphism instead of subkinding, because I think the relaxed kinds would naturally be inferred where I need them. The problem I’m

Re: Tightening up on inferred type signatures

2014-04-21 Thread adam vogt
] GHC generally obeys this rule ] ] · If GHC infers a type f::type, then it’s OK for you to add a type ] signature saying exactly that. That rule suggests that -XScopedTypeVariables should be on by default, and that you shouldn't need a forall to bring the type variables into scope. I