Skip to content
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

Fix parser issue on type annotations in e.g. empty list type annotations #36

Merged
merged 2 commits into from
Apr 16, 2020

Conversation

travisbrown
Copy link
Owner

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:

empty-list-literal =
    "[" whsp [ "," whsp ] "]" whsp ":" whsp1 application-expression

And similarly toMap and merge have application-expression for their type annotations, but e.g. dhall-haskell is perfectly happy to parse []: List Natural: Type, where the type annotation doesn't match application-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 with expression in the grammar, and it makes the parser match dhall-haskell (apparently) without breaking anything else.

@travisbrown travisbrown merged commit 9812741 into master Apr 16, 2020
@travisbrown travisbrown deleted the fix/1 branch April 17, 2020 11:25
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.

Fix type annotation precedence issue
1 participant