Skip to content

NoPat refactor#1077

Merged
robdockins merged 4 commits intomasterfrom
nopat-refactor
Feb 15, 2021
Merged

NoPat refactor#1077
robdockins merged 4 commits intomasterfrom
nopat-refactor

Conversation

@robdockins
Copy link
Contributor

Refactor NoPat to fix #567

The name binding structure that results from multi-parameter
functions with repeated names, and the interaction with pattern
desugaring is currently very counterintuitive.  See issue #567 for
more discussion.
Multi-argument functions are now desuguared into nested lambdas
in the `NoPat` phase instead of during typechecking.  This gives
more sensible results when the same variable is shadowed in the argument
list.  In particular, extra "where" bindings that are added for pattern
desugaring now have a scope that is outside patterns and variables
occuring further to the right.

Some programs that used to produce "overlapping symbols" errors are
now accepted with a shadowing warning instead.

The main downside of this refactoring is that the `checkFun` operation
no longer has access to function name or argument numbers for definitions,
as all functions have become single-argument lambdas by typechecking time.
This can be fixed by recording this information in the AST during the
NoPat desugaring instead.
This allows us to attach information to `EFun` nodes that describe
which named function the lambda belongs to, and which arguments
it handles.  This information is filled in by the `NoPat` pass
as it desugars multi-argument functions into a sequence of lambdas
and is used during typechecking to produce error messages.

There is an odd potential for the renamer to get things wrong here.
If a named function has an argument that shadows it's own name,
the renamer may incorrectly resolve the name in a function description
for later arguments.  The resulting error message will then point to
the wrong name (although it will be in the vicinity...).  It's hard
to fix this without folding the NoPat pass into the renamer (which
we should also do, but it's a nontrivial refactoring).
Reordering the where declarations in pattern desugaring caused
some minor changes in error message output, as well as
changes in the specializer.
Copy link
Contributor

@brianhuffman brianhuffman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks reasonable to me.

Copy link
Member

@yav yav left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure this is the right thing to do here, these are my thoughts:

  • I think there might be value in preserving the arity of functions, especially as we look more into generating code
  • it seems to me that \x x -> e should be an error, rather than a warning, just like \(x,x) -> e is an error
  • if you do think that's the right thing to do though, it looks like Bind now never has any parameters after NoPat so we should probably remove implementations for that from the following passes
  • I have a whole lot of changes to the renamer on my modules branch, and am about to start working on the type checker this week, so there's lot's of potential for merge conflicts, so we may want to hold off on simplifying the following passes for now

@robdockins
Copy link
Contributor Author

Well, the typechecker reduces the arity of all functions to 1 already, so I don't think we're losing anything here.

As to the error situations: I'm open to the idea that these should be errors instead, but I couldn't figure out a good way to do that without doing a much larger refactoring that merges the NoPat pass directly into the Renamer. I think that's a good idea, eventually, but I don't understand all the working pieces well enough to know how difficult that would be.

As to simplifying Bind: I'm starting to wonder if there are enough invariants we want to enforce here that it makes sense to have a separate AST (at least at the declarations level) for the results of the NoPat/Renamer pass (again, that's a larger refactoring, though).

@brianhuffman
Copy link
Contributor

I agree that duplicate variables like \x x -> x should be an error, and this PR does not yet make that an error; but I also think it is a step in the right direction. As @robdockins says, doing everything properly will probably require a much bigger refactoring.

@yav
Copy link
Member

yav commented Feb 15, 2021

I am fine with merging it, as it is fairly localized change. However, we should probably do some sort of larger refactoring too---I've cleaned up a bunch of stuff in the renamer on the submodules branch, but there is still a bunch of duplication in various places (e.g., Parser.Names) so maybe we can start thinking on how we'd like things to be. Maybe a good thing to consider for just after the release.

@robdockins robdockins merged commit 9c4e8fb into master Feb 15, 2021
brianhuffman added a commit to GaloisInc/saw-script that referenced this pull request Mar 3, 2021
The following included cryptol PRs required changes to saw-script:
- GaloisInc/cryptol#1077 "nopat-refactor"
- GaloisInc/cryptol#1075 "persist-solver"
brianhuffman added a commit to GaloisInc/saw-script that referenced this pull request Mar 3, 2021
The following included cryptol PRs required changes to saw-script:
- GaloisInc/cryptol#1077 "nopat-refactor"
- GaloisInc/cryptol#1075 "persist-solver"
brianhuffman added a commit to GaloisInc/saw-script that referenced this pull request Mar 4, 2021
The following included cryptol PRs required changes to saw-script:
- GaloisInc/cryptol#1077 "nopat-refactor"
- GaloisInc/cryptol#1075 "persist-solver"
brianhuffman added a commit to GaloisInc/saw-script that referenced this pull request Mar 8, 2021
The following included cryptol PRs required changes to saw-script:
- GaloisInc/cryptol#1077 "nopat-refactor"
- GaloisInc/cryptol#1075 "persist-solver"
brianhuffman added a commit to GaloisInc/saw-script that referenced this pull request Mar 8, 2021
The following included cryptol PRs required changes to saw-script:
- GaloisInc/cryptol#1077 "nopat-refactor"
- GaloisInc/cryptol#1075 "persist-solver"
@RyanGlScott RyanGlScott deleted the nopat-refactor branch March 22, 2024 14:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Shadowing in a lambda list gives an unexpected result

3 participants