Instantiating a type with fresh, flexi type variables

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Instantiating a type with fresh, flexi type variables

Dr. ERDI Gergo
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



Reply | Threaded
Open this post in threaded view
|

Instantiating a type with fresh, flexi type variables

Simon Peyton Jones
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:ghc-devs-bounces at haskell.org] On Behalf Of Dr. ERDI
|  Gergo
|  Sent: 08 August 2013 18:37
|  To: ghc-devs at haskell.org
|  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
|  ghc-devs at haskell.org
|  http://www.haskell.org/mailman/listinfo/ghc-devs




Reply | Threaded
Open this post in threaded view
|

Instantiating a type with fresh, flexi type variables

Dr. ERDI Gergo
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" <simonpj at microsoft.com> 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:ghc-devs-bounces at haskell.org] On Behalf Of Dr.
> ERDI
> |  Gergo
> |  Sent: 08 August 2013 18:37
> |  To: ghc-devs at haskell.org
> |  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
> |  ghc-devs at haskell.org
> |  http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130820/f8bc8c79/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

Instantiating a type with fresh, flexi type variables

Simon Peyton Jones
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:gergo at erdi.hu]
Sent: 20 August 2013 03:09
To: Simon Peyton-Jones
Cc: ghc-devs at haskell.org
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" <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> 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:ghc-devs-bounces at haskell.org<mailto:ghc-devs-bounces at haskell.org>] On Behalf Of Dr. ERDI
|  Gergo
|  Sent: 08 August 2013 18:37
|  To: ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
|  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
|  ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
|  http://www.haskell.org/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130820/4708aa84/attachment.htm>