- ghc-devs - Haskell.org

Re: Proposal: ValidateMonoLiterals - Initial bikeshed discussion
by Dan Doel 10 Feb '15

10 Feb '15

Assuming a separate syntax, I believe that the criterion would be as simple as ensuring that no ValidateFoo constraints are left outstanding. The syntax would add the relevant validate call, and type variables involved in a ValidateFoo constraint would not be generalizable, and would have to be defaulted or inferred from elsewhere, similar to the monomorphism restriction. I'm not sure how difficult that would be to implement. I'm not terribly gung ho on this, though. It feels very ad hoc. Making validation vs. non-validation syntactic rather than just based on polymorphism seems somewhat less so, though; so I'd prefer that direction. Finding unused syntax is always a problem, of course. On Fri, Feb 6, 2015 at 11:38 AM, Ryan Trinkle <ryan.trinkle(a)gmail.com> wrote: > My greatest concern here would be that, as an application is maintained, a > literal might go from monomorphic to polymorphic, or vice versa, without > anybody noticing. It sounds like this could result in a value silently > becoming partial, which would be a big problem for application stability; > in the opposite case - a partial value becoming a compile-time error - I am > somewhat less concerned, but it could still be confusing and disruptive. > > I would prefer that there be some syntactic indication that I want my > literal to be checked at compile time. This syntax could also add whatever > monomorphism requirement is needed, and then it would become a compile-time > error for the value to become polymorphic. I don't know nearly enough > about the type system to know whether this is possible. > > Also, it seems to me that it might not be so clean as "monomorphic" versus > "polymorphic". For example, suppose I have this: > > newtype PostgresTableName s = PostgresTableName String > > where 's' is a phantom type representing the DB schema that the name lives > in. The validation function is independent of the schema - it simply fails > if there are illegal characters in the name, or if the name is too long. > So, ideally, ("foo\0bar" :: forall s. PostgresTableName s) would fail at > compile time, despite being polymorphic. > > > Ryan > > On Fri, Feb 6, 2015 at 11:16 AM, Merijn Verstraaten < > merijn(a)inconsistent.nl> wrote: > >> Ryan, >> >> Unfortunately, yes, you are understanding that correctly. >> >> The reason I qualified it with "monomorphic only" is that, I want to >> avoid breakage that would render the extension practically unusable in real >> code. >> >> Let's say I right now have: >> >> foo :: Num a => [a] -> [a] >> foo = map (+1) >> >> I have two options 1) we compile this as currently using fromIntegral and >> it WILL break for Even or 2) we reject any polymorphic use of literals like >> this. Given the amount of numerical code relying on the polymorphism of >> Num, I think the option of not being able to compile Num polymorphic code >> is completely out of the question. Almost no application would work. >> >> I would advocate in favour of not requiring an IsList/IsString instance >> for the validation class, this would allow you to write a conversion that >> ONLY converts literals in a validated way and will never successfully >> convert literals without the extension, since with the extension disabled >> GHC would try to use the fromList/fromString from the IsString/IsList >> classes which do not exist. >> >> Unfortunately, given how deeply fromIntegral is tied to the Num class I >> don't see any way to achieve the same for Num. The only option would be to >> not make Even an instance of Num, that way the same trick as above could >> work. Removing fromIntegral from Num is obviously not going to happen and >> without doing that I don't see how we could prevent someone using >> fromIntegral manually to convert to Even in a way that won't break Num >> polymorphic functions. If you have any ideas on how to tackle this, I'm all >> open to hearing them! >> >> I agree with you that this is ugly, but I console myself with the thought >> that being able to check all monomorphic literals is already a drastic >> improvement over the current state. And in the case of lists and strings we >> could actually ensure that things work well, since almost no one writes >> "IsString polymorphic" code. >> >> Cheers, >> Merijn >> >> > On 6 Feb 2015, at 16:59, Ryan Trinkle <ryan.trinkle(a)gmail.com> wrote: >> > >> > I think the idea of compile-time validation for overloaded literals is >> fantastic, and doing it with nicer syntax than quasiquoting would really >> improve things. However, I'm a bit confused about specifically how the >> requirement that it be monomorphic will play into this. For example, if I >> have: >> > >> > x = 1 >> > >> > Presumably this will compile, and give a run-time error if I ever >> instantiate its type to Even. However, if I have: >> > >> > x :: Even >> > x = 1 >> > >> > it will fail to compile? Furthermore, if I have the former, and type >> inference determines that its type is Even, it sounds like that will also >> fail to compile, but if type inference determines that its type is forall >> a. Nat a => a, then it will successfully compile and then fail at runtime. >> > >> > Am I understanding this correctly? >> > >> > >> > Ryan >> > >> > On Fri, Feb 6, 2015 at 8:55 AM, Erik Hesselink <hesselink(a)gmail.com> >> wrote: >> > On Fri, Feb 6, 2015 at 2:49 PM, Dominique Devriese >> > <dominique.devriese(a)cs.kuleuven.be> wrote: >> > > Agreed. For the idea to scale, good support for type-level >> > > programming with Integers/Strings/... is essential. Something else >> > > that would be useful is an unsatisfiable primitive constraint >> > > constructor `UnsatisfiableConstraint :: String -> Constraint` that can >> > > be used to generate custom error messages. Then one could write >> > > something like >> > > >> > > type family MustBeTrue (t :: Bool) (error :: String) :: Constraint >> > > type family MustBeTrue True _ = () >> > > type family MustBeTrue False error = UnsatisfiableConstraint error >> > > >> > > type family MustBeEven (n :: Nat) :: Constraint >> > > type family MustBeEven n = MustBeTrue (IsEven n) ("Error in Even >> > > literal :'" ++ show n ++ "' is not even!") >> > > >> > > instance (KnownNat n, MustBeEven n) => HasIntegerLiteral Even n >> where ... >> > >> > Note that there is a trick to fake this with current GHC: you can >> > write an equality constraint that is false, involving the type level >> > string: >> > >> > > type family MustBeTrue False error = (() ~ error) >> > >> > Erik >> > _______________________________________________ >> > Glasgow-haskell-users mailing list >> > Glasgow-haskell-users(a)haskell.org >> > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users(a)haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > >

3 4

Question about implementing `Typeable` (with kinds)
by Iavor Diatchki 09 Feb '15

09 Feb '15

Hello, I started adding custom solving for `Typeable` constraints, to work around the problem where kind parameters were missing from the representation of types. The idea is as follows: 1. Add a new filed to `TypeRep` that remembers _kind_ parameters: TypeRep Fingerprint TyCon [TypeRep]{-kinds-} [TypeRep]{-types-} 2. Modify the constraint solver, to solve constraints like this: - Kind-polymorphic type constructors don't get `Typeable` instances on their own - GHC can solve `Typeable` constraints on _*concrete uses*_ of polymorphic type constructors. More precisely, GHC can solve constraints of the form `Typeable k (TC @ ks)`, as long as: (1) `k` is not a forall kind, (2) the `ks` are all concrete kinds (i.e., they have no free kind variables). This all seems fairly straight-forward, but I got stuck on the actual implementation, in particular: *what `EvTerm` should I use when discharging a `Typeable` constraint?* I can create a an `HsSyn` value for the required method (i.e., a function of type `Proxy# t -> TypeRep`). I can also cast this into a `Typeable` dictionary value. The issue is that I am left with an `HsSyn` expression, and not an `EvTerm`. So is there a way to treat an arbitrary expression as an `EvTerm`? In the implementation of the type-lits, I just added custom evidence, but this does not scale well (also, in that case the evidence is just a simple value, while here it is a bit more complex). Suggestions would be most appreciated! -Iavor

4 5

Re: Proposal: ValidateMonoLiterals - Initial bikeshed discussion
by Gershom B 09 Feb '15

09 Feb '15

I recall having some discussions with Mathieu Boespflug regarding how the static pointers work could be of use here. (And also Richard Eisenberg?) In particular, we want to demand a special property of our validation functions -- that they can safely be used at compile-time without necessarily "linking in the world" and invoking the whole of template haskell. A function that is "static" should in a sense have this sort of property? And so requiring that our validation functions be static seems like a useful thing from an implementation standpoint. Static semantics might also help "force the thunk" on what the correct relationship to polymorphism is. I guess the remaining question is then where to add them. I suppose we could stick them with special semantics on Num and IsString or the like and do it by magic? Alternately we could maybe have a whole class of "compile-time static functions" that we just explicitly use, and all have the property that they have type "a -> a" for some concrete "a", and that the value they are applied to is static. These functions are then applied at compile time, and forced to whnf. If they toss an error it is a compile error, otherwise they are not present in the generated code. There are other design variations possible, but that one feels pretty neat to me, if feasible. So then I could write foo :: Even foo = even 6 for example, and get errors at compile-time. On top of this we could add a special way to augment Num, IsString, etc with such methods to yield the desired: foo :: Even foo = 6 -gershom

3 2

ghc-7.8 in Fedora Rawhide
by Jens Petersen 07 Feb '15

07 Feb '15

The Fedora Haskell SIG is pleased to announce the arrival of GHC 7.8 in the Fedora 22 Rawhide development tree. - the GHC version is 7.8.4: we are no longer following haskell-platform strictly, - over 120 Haskell packages have been updated to their latest versions, including pandoc-1.13.2. There are currently still a few issues in Rawhide: - a few packages have not yet been rebuilt/updated with ghc-7.8.4: - errors: bustle, ghc-ForSyde, ghc-type-level, ghc-parameterized-data - new deps needed: hledger, Agda, leksah, cab - also on ARMv7 the RTS seems to have some strange problems leading to crashes which is under investagation: no idris build on armv7: < https://ghc.haskell.org/trac/ghc/ticket/10029>. Thanks, Jens

1 0

Proposal: ValidateMonoLiterals - Initial bikeshed discussion
by Merijn Verstraaten 06 Feb '15

06 Feb '15

I've been repeatedly running into problems with overloaded literals and partial conversion functions, so I wrote up an initial proposal (https://ghc.haskell.org/trac/ghc/wiki/ValidateMonoLiterals) and I'd like to commence with the bikeshedding and hearing other opinions :) Cheers, Merijn

6 10

Re: Proposal: ValidateMonoLiterals - Initial bikeshed discussion
by Carter Schonwald 06 Feb '15

06 Feb '15

Its worth pointing out that when / if luites out of process TH design happens for ghc, TH will be usable in cross compile builds of ghc as well. So we shouldn't let that constraint we have for now dictate future tooling ideas. On Feb 6, 2015 3:50 PM, "Evan Laforge" <qdunkan(a)gmail.com> wrote: > Would it be feasible to make a lighter-weight mode for quasiquotes > that doesn't require the whole "load the module in ghci" runaround? > If it didn't need to do that, there wouldn't be much downside to > turning it on everywhere. And it would enable lots of QQ conveniences > that at least I don't think its worth enabling TH for, due to the ghci > hassle. > > Greg Weber recently asked for input on the idea of restricted TH > modes, this seems related. > > If a splice was pure and had no non-Prelude dependencies, could it be > run without ghci loading and stage restrictions? > > I think it's really awkward how numeric literals use fromInteger and > fromRational, and those functions are grouped into Num and Fractional. > So if you want to use (+), you also have to accept literals, which > means you have to accept anything anyone might type. Has there been > any kind of proposal to split fromInteger and fromRational into their > own typeclasses analogous to IsString? > > On Fri, Feb 6, 2015 at 9:24 AM, Dan Doel <dan.doel(a)gmail.com> wrote: > > Assuming a separate syntax, I believe that the criterion would be as > simple > > as ensuring that no ValidateFoo constraints are left outstanding. The > syntax > > would add the relevant validate call, and type variables involved in a > > ValidateFoo constraint would not be generalizable, and would have to be > > defaulted or inferred from elsewhere, similar to the monomorphism > > restriction. I'm not sure how difficult that would be to implement. > > > > I'm not terribly gung ho on this, though. It feels very ad hoc. Making > > validation vs. non-validation syntactic rather than just based on > > polymorphism seems somewhat less so, though; so I'd prefer that > direction. > > Finding unused syntax is always a problem, of course. > > > > On Fri, Feb 6, 2015 at 11:38 AM, Ryan Trinkle <ryan.trinkle(a)gmail.com> > > wrote: > >> > >> My greatest concern here would be that, as an application is > maintained, a > >> literal might go from monomorphic to polymorphic, or vice versa, without > >> anybody noticing. It sounds like this could result in a value silently > >> becoming partial, which would be a big problem for application > stability; in > >> the opposite case - a partial value becoming a compile-time error - I am > >> somewhat less concerned, but it could still be confusing and disruptive. > >> > >> I would prefer that there be some syntactic indication that I want my > >> literal to be checked at compile time. This syntax could also add > whatever > >> monomorphism requirement is needed, and then it would become a > compile-time > >> error for the value to become polymorphic. I don't know nearly enough > about > >> the type system to know whether this is possible. > >> > >> Also, it seems to me that it might not be so clean as "monomorphic" > versus > >> "polymorphic". For example, suppose I have this: > >> > >> newtype PostgresTableName s = PostgresTableName String > >> > >> where 's' is a phantom type representing the DB schema that the name > lives > >> in. The validation function is independent of the schema - it simply > fails > >> if there are illegal characters in the name, or if the name is too long. > >> So, ideally, ("foo\0bar" :: forall s. PostgresTableName s) would fail at > >> compile time, despite being polymorphic. > >> > >> > >> Ryan > >> > >> On Fri, Feb 6, 2015 at 11:16 AM, Merijn Verstraaten > >> <merijn(a)inconsistent.nl> wrote: > >>> > >>> Ryan, > >>> > >>> Unfortunately, yes, you are understanding that correctly. > >>> > >>> The reason I qualified it with "monomorphic only" is that, I want to > >>> avoid breakage that would render the extension practically unusable in > real > >>> code. > >>> > >>> Let's say I right now have: > >>> > >>> foo :: Num a => [a] -> [a] > >>> foo = map (+1) > >>> > >>> I have two options 1) we compile this as currently using fromIntegral > and > >>> it WILL break for Even or 2) we reject any polymorphic use of literals > like > >>> this. Given the amount of numerical code relying on the polymorphism > of Num, > >>> I think the option of not being able to compile Num polymorphic code is > >>> completely out of the question. Almost no application would work. > >>> > >>> I would advocate in favour of not requiring an IsList/IsString instance > >>> for the validation class, this would allow you to write a conversion > that > >>> ONLY converts literals in a validated way and will never successfully > >>> convert literals without the extension, since with the extension > disabled > >>> GHC would try to use the fromList/fromString from the IsString/IsList > >>> classes which do not exist. > >>> > >>> Unfortunately, given how deeply fromIntegral is tied to the Num class I > >>> don't see any way to achieve the same for Num. The only option would > be to > >>> not make Even an instance of Num, that way the same trick as above > could > >>> work. Removing fromIntegral from Num is obviously not going to happen > and > >>> without doing that I don't see how we could prevent someone using > >>> fromIntegral manually to convert to Even in a way that won't break Num > >>> polymorphic functions. If you have any ideas on how to tackle this, > I'm all > >>> open to hearing them! > >>> > >>> I agree with you that this is ugly, but I console myself with the > thought > >>> that being able to check all monomorphic literals is already a drastic > >>> improvement over the current state. And in the case of lists and > strings we > >>> could actually ensure that things work well, since almost no one writes > >>> "IsString polymorphic" code. > >>> > >>> Cheers, > >>> Merijn > >>> > >>> > On 6 Feb 2015, at 16:59, Ryan Trinkle <ryan.trinkle(a)gmail.com> > wrote: > >>> > > >>> > I think the idea of compile-time validation for overloaded literals > is > >>> > fantastic, and doing it with nicer syntax than quasiquoting would > really > >>> > improve things. However, I'm a bit confused about specifically how > the > >>> > requirement that it be monomorphic will play into this. For > example, if I > >>> > have: > >>> > > >>> > x = 1 > >>> > > >>> > Presumably this will compile, and give a run-time error if I ever > >>> > instantiate its type to Even. However, if I have: > >>> > > >>> > x :: Even > >>> > x = 1 > >>> > > >>> > it will fail to compile? Furthermore, if I have the former, and type > >>> > inference determines that its type is Even, it sounds like that will > also > >>> > fail to compile, but if type inference determines that its type is > forall a. > >>> > Nat a => a, then it will successfully compile and then fail at > runtime. > >>> > > >>> > Am I understanding this correctly? > >>> > > >>> > > >>> > Ryan > >>> > > >>> > On Fri, Feb 6, 2015 at 8:55 AM, Erik Hesselink <hesselink(a)gmail.com> > >>> > wrote: > >>> > On Fri, Feb 6, 2015 at 2:49 PM, Dominique Devriese > >>> > <dominique.devriese(a)cs.kuleuven.be> wrote: > >>> > > Agreed. For the idea to scale, good support for type-level > >>> > > programming with Integers/Strings/... is essential. Something else > >>> > > that would be useful is an unsatisfiable primitive constraint > >>> > > constructor `UnsatisfiableConstraint :: String -> Constraint` that > >>> > > can > >>> > > be used to generate custom error messages. Then one could write > >>> > > something like > >>> > > > >>> > > type family MustBeTrue (t :: Bool) (error :: String) :: > Constraint > >>> > > type family MustBeTrue True _ = () > >>> > > type family MustBeTrue False error = UnsatisfiableConstraint > error > >>> > > > >>> > > type family MustBeEven (n :: Nat) :: Constraint > >>> > > type family MustBeEven n = MustBeTrue (IsEven n) ("Error in Even > >>> > > literal :'" ++ show n ++ "' is not even!") > >>> > > > >>> > > instance (KnownNat n, MustBeEven n) => HasIntegerLiteral Even n > >>> > > where ... > >>> > > >>> > Note that there is a trick to fake this with current GHC: you can > >>> > write an equality constraint that is false, involving the type level > >>> > string: > >>> > > >>> > > type family MustBeTrue False error = (() ~ error) > >>> > > >>> > Erik > >>> > _______________________________________________ > >>> > Glasgow-haskell-users mailing list > >>> > Glasgow-haskell-users(a)haskell.org > >>> > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > >>> > >>> _______________________________________________ > >>> Glasgow-haskell-users mailing list > >>> Glasgow-haskell-users(a)haskell.org > >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > >>> > >> > >> > >> _______________________________________________ > >> Glasgow-haskell-users mailing list > >> Glasgow-haskell-users(a)haskell.org > >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > >> > > > > > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users(a)haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >

1 0

Can't install packages with my inplace compiler
by Simon Peyton Jones 06 Feb '15

06 Feb '15

When I say cabal install --with-ghc=/home/simonpj/5builds/HEAD-2/inplace/bin/ghc-stage2 I get this ghc-stage2: ghc no longer supports single-file style package databases (dist/package.conf.inplace) use 'ghc-pkg init' to create the database with the correct format. Now, this is an old build tree, and I could blow it away entirely, but maybe there is something else going on. What should I do? Thanks (all on Linux) Simon

5 8

Re: Proposal: ValidateMonoLiterals - Initial bikeshed discussion
by Merijn Verstraaten 06 Feb '15

06 Feb '15

Ryan, Unfortunately, yes, you are understanding that correctly. The reason I qualified it with "monomorphic only" is that, I want to avoid breakage that would render the extension practically unusable in real code. Let's say I right now have: foo :: Num a => [a] -> [a] foo = map (+1) I have two options 1) we compile this as currently using fromIntegral and it WILL break for Even or 2) we reject any polymorphic use of literals like this. Given the amount of numerical code relying on the polymorphism of Num, I think the option of not being able to compile Num polymorphic code is completely out of the question. Almost no application would work. I would advocate in favour of not requiring an IsList/IsString instance for the validation class, this would allow you to write a conversion that ONLY converts literals in a validated way and will never successfully convert literals without the extension, since with the extension disabled GHC would try to use the fromList/fromString from the IsString/IsList classes which do not exist. Unfortunately, given how deeply fromIntegral is tied to the Num class I don't see any way to achieve the same for Num. The only option would be to not make Even an instance of Num, that way the same trick as above could work. Removing fromIntegral from Num is obviously not going to happen and without doing that I don't see how we could prevent someone using fromIntegral manually to convert to Even in a way that won't break Num polymorphic functions. If you have any ideas on how to tackle this, I'm all open to hearing them! I agree with you that this is ugly, but I console myself with the thought that being able to check all monomorphic literals is already a drastic improvement over the current state. And in the case of lists and strings we could actually ensure that things work well, since almost no one writes "IsString polymorphic" code. Cheers, Merijn > On 6 Feb 2015, at 16:59, Ryan Trinkle <ryan.trinkle(a)gmail.com> wrote: > > I think the idea of compile-time validation for overloaded literals is fantastic, and doing it with nicer syntax than quasiquoting would really improve things. However, I'm a bit confused about specifically how the requirement that it be monomorphic will play into this. For example, if I have: > > x = 1 > > Presumably this will compile, and give a run-time error if I ever instantiate its type to Even. However, if I have: > > x :: Even > x = 1 > > it will fail to compile? Furthermore, if I have the former, and type inference determines that its type is Even, it sounds like that will also fail to compile, but if type inference determines that its type is forall a. Nat a => a, then it will successfully compile and then fail at runtime. > > Am I understanding this correctly? > > > Ryan > > On Fri, Feb 6, 2015 at 8:55 AM, Erik Hesselink <hesselink(a)gmail.com> wrote: > On Fri, Feb 6, 2015 at 2:49 PM, Dominique Devriese > <dominique.devriese(a)cs.kuleuven.be> wrote: > > Agreed. For the idea to scale, good support for type-level > > programming with Integers/Strings/... is essential. Something else > > that would be useful is an unsatisfiable primitive constraint > > constructor `UnsatisfiableConstraint :: String -> Constraint` that can > > be used to generate custom error messages. Then one could write > > something like > > > > type family MustBeTrue (t :: Bool) (error :: String) :: Constraint > > type family MustBeTrue True _ = () > > type family MustBeTrue False error = UnsatisfiableConstraint error > > > > type family MustBeEven (n :: Nat) :: Constraint > > type family MustBeEven n = MustBeTrue (IsEven n) ("Error in Even > > literal :'" ++ show n ++ "' is not even!") > > > > instance (KnownNat n, MustBeEven n) => HasIntegerLiteral Even n where ... > > Note that there is a trick to fake this with current GHC: you can > write an equality constraint that is false, involving the type level > string: > > > type family MustBeTrue False error = (() ~ error) > > Erik > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

Generic instances for GHC AST
by Alan & Kim Zimmerman 06 Feb '15

06 Feb '15

At the moment every part of the GHC AST derives instances of Data and Typeable. There are no instances of Generic. If I try to standalone derive these, the derivation eventually fails for deriving instance Generic (Name) because the constructors are not all in scope. So, does it make sense in GHC to at least derive Generic for the items that are opaque, and at most to do so for the whole AST. I know there were some concerns earlier about too many instances being derived, and its impact on compilation time and memory, so the minimal version may be best. This will allow the new generation libraries built around Generics to perform on GHC data structures too. Alan

2 3

Partial type sigs
by Simon Peyton Jones 06 Feb '15

06 Feb '15

Thomas I was looking at Trac #10045<http://ghc.haskell.org/trac/ghc/ticket/10045>. I know exactly what is going on, but my investigation triggered several questions. 1. What is the state of the ToDos on https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures? 2. Is a named wildcard supposed to have any scope? For example: f :: _a -> b -> _a f x y = x :: _a The _a in the signature is not supposed to have any lexical scope over the binding is it? That would be entirely inconsistent with the treatment of ordinary type variables (such as 'b' in the example) which only scope if you have an explicit 'forall b'. Assuming the answer is "no" (and I really think it should be no), what is the call to tcExtendTyVarEnv2 tvsAndNcs doing in TcBinds.tcRhs? I'm pretty certain it bring into scope only the sig_tvs, and NOT the sig_nwcs. 3. If that is true, I think we may not need the sig_nwcs field of TcSigInfo at all. 4. A TcSigInfo has a sig_id field, which is intended to give the fixed, fully-known polymorphic type of the function. This is used: * for polymorphic recursion * as the type of the function to use in the body of the let, even if typechecking the function itself fails. Neither of these makes sense for partial type sigs. (And in fact, using sig_id for a partial type sig is what gives rise to #10045.) So I'm pretty convinced that we should replace sig_id and sig_partial with a single field sig_id :: Maybe Id, which is Nothing for partial sigs, and (Just ty) for total sigs. I wanted to check with you before blundering in and doing this. Or you could. RSVP Thanks Simon

4 6