Substitutions

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

Substitutions

Simon Peyton Jones

Bartosz

How are you getting on with tidying up substitutions.

I’ve done a bit in that direction myself:

commit 1c6d70c2121fd1126fcc2458bdbcc856e19598c2

Author: Simon Peyton Jones <[hidden email]>

Date:   Tue Jan 26 09:37:06 2016 +0000

 

    Kill off zipTopTCvSubst in favour of zipOpenTCvSubst

But there is more to do.

In particular, I note that substTys is not checked – but neither is it called substTysUnchecked.  It should be!  That will show up a bunch more cases, I think.

Another particular thing, arising from my patch, is that we can now do some renaming

·         zipOpenTCvSubst  -> zipTvSubst   (It only deals with tyvars)

·         zipOpenTCvSubstCoVars -> zipCvSubst   (it only deals with covars)

·         zipOpenTCvSubstBinders ->  zipTyBinderSubst  (it only deals with TyBinders, not covars)

I guess you’ll want to do similar things for the “mk” variants.

Anyway: good for you!  Let me know if you need help.

Simon

 

 


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Substitutions

Bartosz Nitka
Hello Simon,

I was about to send an improved version of D1801, I will do that once I rebase past your patch (there's a small overlap with what I've done). D1820 is ready for review.
I have a patch coming for piResultTys [1] where the FVs of ty are not in the in_scope set. I've also looked at a similar problem in lint_app [2], but the fix I have is a bit awkward, so I will probably need some input from you. Both of them are blocking #11360 and I want to get it unblocked as soon as possible to continue determinism work.

I'm aware of substTys being currently unchecked, I didn't want to introduce substTysUnchecked just yet, as there already are more than 30 occurrences of substTyUnchecked. But maybe I should push uncheckedness as far up as possible, do you think it's worth to do it now? 

Do you want me to do the renaming?
 
Cheers,
Bartosz


2016-01-26 10:55 GMT+00:00 Simon Peyton Jones <[hidden email]>:

Bartosz

How are you getting on with tidying up substitutions.

I’ve done a bit in that direction myself:

commit 1c6d70c2121fd1126fcc2458bdbcc856e19598c2

Author: Simon Peyton Jones <[hidden email]>

Date:   Tue Jan 26 09:37:06 2016 +0000

 

    Kill off zipTopTCvSubst in favour of zipOpenTCvSubst

But there is more to do.

In particular, I note that substTys is not checked – but neither is it called substTysUnchecked.  It should be!  That will show up a bunch more cases, I think.

Another particular thing, arising from my patch, is that we can now do some renaming

·         zipOpenTCvSubst  -> zipTvSubst   (It only deals with tyvars)

·         zipOpenTCvSubstCoVars -> zipCvSubst   (it only deals with covars)

·         zipOpenTCvSubstBinders ->  zipTyBinderSubst  (it only deals with TyBinders, not covars)

I guess you’ll want to do similar things for the “mk” variants.

Anyway: good for you!  Let me know if you need help.

Simon

 

 



_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: Substitutions

Simon Peyton Jones

I'm aware of substTys being currently unchecked, I didn't want to introduce substTysUnchecked just yet, as there already are more than 30 occurrences of substTyUnchecked. But maybe I should push uncheckedness as far up as possible, do you think it's worth to do it now? 

Well, it’s just as much a source of potential bugs as substTy.  So yes, I’d make all the calls to substTysUnchecked, and then work through getting rid of them.  Many of them will be simple.

 

Do you want me to do the renaming?

 

yes please

 

Pls yell specifically when you need help; don’t rely on me seeing Phab patches

 

S

 

From: Bartosz Nitka [mailto:[hidden email]]
Sent: 26 January 2016 11:15
To: Simon Peyton Jones <[hidden email]>
Cc: [hidden email]
Subject: Re: Substitutions

 

Hello Simon,

 

I was about to send an improved version of D1801, I will do that once I rebase past your patch (there's a small overlap with what I've done). D1820 is ready for review.

I have a patch coming for piResultTys [1] where the FVs of ty are not in the in_scope set. I've also looked at a similar problem in lint_app [2], but the fix I have is a bit awkward, so I will probably need some input from you. Both of them are blocking #11360 and I want to get it unblocked as soon as possible to continue determinism work.

 

I'm aware of substTys being currently unchecked, I didn't want to introduce substTysUnchecked just yet, as there already are more than 30 occurrences of substTyUnchecked. But maybe I should push uncheckedness as far up as possible, do you think it's worth to do it now? 

 

Do you want me to do the renaming?

 

Cheers,

Bartosz

 

 

2016-01-26 10:55 GMT+00:00 Simon Peyton Jones <[hidden email]>:

Bartosz

How are you getting on with tidying up substitutions.

I’ve done a bit in that direction myself:

commit 1c6d70c2121fd1126fcc2458bdbcc856e19598c2

Author: Simon Peyton Jones <[hidden email]>

Date:   Tue Jan 26 09:37:06 2016 +0000

 

    Kill off zipTopTCvSubst in favour of zipOpenTCvSubst

But there is more to do.

In particular, I note that substTys is not checked – but neither is it called substTysUnchecked.  It should be!  That will show up a bunch more cases, I think.

Another particular thing, arising from my patch, is that we can now do some renaming

·         zipOpenTCvSubst  -> zipTvSubst   (It only deals with tyvars)

·         zipOpenTCvSubstCoVars -> zipCvSubst   (it only deals with covars)

·         zipOpenTCvSubstBinders ->  zipTyBinderSubst  (it only deals with TyBinders, not covars)

I guess you’ll want to do similar things for the “mk” variants.

Anyway: good for you!  Let me know if you need help.

Simon

 

 

 


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs