Yes I suspect that patSynSig should return three results: the quantified tyvars, the lhs types and the rhs type
Simon From: Dr. ÉRDI Gergő [mailto:[email protected]] Sent: 20 August 2013 03:09 To: Simon Peyton-Jones Cc: [email protected] Subject: RE: Instantiating a type with fresh, flexi type variables Hi Simon, Here's what I wrote earlier about this to someone who contacted me in private (name withheld because I don't know why he contacted me off-list): """ So the code in question is this: https://github.com/gergoerdi/ghc/commit/f874f8#L5R749 and the part that feels fishy to me is tcInstTypes, both the implementation and the fact that I have to take care of this manually. I guess the right solution would involve doing something differently in https://github.com/gergoerdi/ghc/commit/244b9#L3R43 so that the types in "rhs_ty" and "args" are correctly generalized. But I haven't been able to find out how that would be done. """ I'm replying to your other questions in a separate, private mail. Thanks, Gergo On Aug 20, 2013 6:14 AM, "Simon Peyton-Jones" <[email protected]<mailto:[email protected]>> wrote: I'm a bit puzzled that you don't have a *quantified* type, something like forall abc. ty1 -> ... -> tyn -> ty to instantiate. I'm a bit suspicious about instantiating all the random free variables of a type (or types). We should talk now I'm back in circulation. What time zone are you in? What's your skype id? (Mine is simonpj0) simon | -----Original Message----- | From: ghc-devs [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Dr. ERDI | Gergo | Sent: 08 August 2013 18:37 | To: [email protected]<mailto:[email protected]> | Subject: Instantiating a type with fresh, flexi type variables | | For my pattern-synonyms branch (see prev. email) I had to write the | following function, incl. making TcValidity.fvTypes public: | | tcInstTypes :: [TcType] -> TcM [TcType] | tcInstTypes tys | = do { let tvs = fvTypes tys | ; (_, _, subst) <- tcInstTyVars tvs | ; return $ map (substTy subst) tys } | | I'm surprised I had to write this myself, and this made me wonder if | there's a much better way to handle cases where I have some kind of | definition which has some inferred type, and then various use sites | of that definition must all have types that can be unified with this | original inferred type. | Is there? | | Thanks, | Gergo | | _______________________________________________ | ghc-devs mailing list | [email protected]<mailto:[email protected]> | http://www.haskell.org/mailman/listinfo/ghc-devs
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
