Merged
Conversation
trefis
approved these changes
Jul 20, 2017
Contributor
trefis
left a comment
There was a problem hiding this comment.
Missing a Changes entry but apart from that looks good to me.
alainfrisch
approved these changes
Jul 20, 2017
Contributor
There was a problem hiding this comment.
This is a very good move. I think it was confusing to allow adding constructor to abstract types in signatures. Moreover, the proposed extension reuse an existing "impossible" form in the Parsetree, i.e. removes one invariant for a Parsetree to represent a parsable program.
I've reviewed the code and it looks ok.
Please add the new form to testsuite/tests/parsetree/source.ml (to check roundtrip between concrete and abstract syntax), and a Changelog entry.
Member
|
This work needs to be merged. @lpw25, would you include a Changes entry? |
45409c5 to
c74d638
Compare
Contributor
Author
|
Rebased and added changes entry. Good to merge once tests pass. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Currently, in signatures, extensible variant constructors can be declared for types of abstract kind:
This is a useful feature allowing constructors to be created by functors without exposing the underlying extensiblity. See the
msg.mlexample in the testsuite for a nice example of this. However, it also allows nonsensical signatures to be created:This doesn't cause any soundness issues but it does cause difficulties for the compiler. For example:
It also makes changes like #792 unnecessarily difficult. In general it is quite awkward to support having constructors available for arbitrary types.
This PR adds a notion of "private" extensible variant type:
which are visibly extensible but cannot actually be extended. This allows us to make it illegal to extend a type which is not known to be extensible:
and so avoid the various problems described above whilst still allowing the use cases previously supported with extensions to abstract types.
This change is not backwards compatible, however extending abstract types is a little used and undocumented feature so I doubt that there will be much disruption.