Fix parser issue on type annotations in e.g. empty list type annotations #36
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.
Fixes #1, and I don't think it breaks anything else. That turned out to be extremely easy.
I was following the spec in my initial implementation, and I think there might be a bug there. For example:
And similarly
toMap
andmerge
haveapplication-expression
for their type annotations, but e.g. dhall-haskell is perfectly happy to parse[]: List Natural: Type
, where the type annotation doesn't matchapplication-expression
. If I'm reading the ABNF correctly and what dhall-haskell is doing doesn't match it, it seems to me like dhall-haskell is doing the right thing, and I think we should follow it here (I could just be confusing myself, though).The change in this PR just replaces my JavaCC equivalents of
application-expression
withexpression
in the grammar, and it makes the parser match dhall-haskell (apparently) without breaking anything else.