-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve 'raise' to introduce let bindings for newly out-of-scope vars #56
Comments
One testcase that may be useful if we want to use letType could be this diff (still commented out) [I am recording this here so I don't lose it when I tidy up my branch for implementing basic duplicate)
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is a placeholder for now, I will come back and fill this in later.
If we want to do this generically for copy/paste, we may want to use letType to deal with typevars. This would need us to fix #5.
However, we may not want to do this, for consistency with the type level copy/paste which has no lets.
It is also a bit pointless as it wouldn't be exposed to the user of(Well, you could doraise
, as you cannot hit this situation with that tool.? : ∀a . List a
, and try to lift theList a
to get? : List ?
. We could instead givelettype a = ? in ? : List a
, by introducing alettype
outside the annotation, but I suspect this is more confusing than it is worth!) Edit: scrap that, you could haveΛa . (? : List a)
, and raise this to get? : List ?
.We will want to consider how to make this non-annoying when lifting the body of a lambda etc (or worse, a let!). Going from
(λx.t)
tolet x = ? in t
doesn't seem all that useful forraise
!Description
This is a feature request.
<Include a brief description here.>
Dependencies
<Link to other GitHub Issues or PRs that must be completed before work can begin on this feature.>
Spec
<Describe what the feature will do, from a high-level perspective.>
Implementation details
<If there are any particularly tricky implementation bits that are worth discussing or you haven't quite figured out yet, describe the details here.>
Not in spec
<Describe any features that your implementation is explicitly avoiding, that a reasonable person might think should be in spec. For example, if you're adding a new action that operates on variables, but it only works with term variables and not type variables, you might want to mention it here so that the scope of the feature is clear.>
Discussion
<If there's a GitHub Discussions topic where this feature has been/is being discussed, link it here.>
Future work
<Describe ideas or additional features that might be useful once this feature has been implemented. This is a good place to link to other GitHub Issues or PRs that track this future work.>
The text was updated successfully, but these errors were encountered: