Skip to content

Conversation

@effectfully
Copy link
Contributor

This makes the parse recognize constants with extra parens in them as requested in #7383.

I don't feel like we want to make any of those extra parens mandatory, but there's no harm in being lenient and parsing them.

@carloskiki
Copy link

I'm not sure this is better. I would rather have an inconsistent syntax with a single way of doing things, than a partially consistent syntax with non-canonical ways of doing things.

@effectfully effectfully requested review from kwxm and zliu41 October 19, 2025 18:36
@effectfully
Copy link
Contributor Author

I don't care either way.

My justification is that for constants we mostly reuse Haskell syntax and there parsing of redundant parens is mostly supported:

>>> read "[(True),(False)]" :: [Bool]
[True,False]
>>> read "[((1,2)),((3,4))]" :: [(Int, Int)]
[(1,2),(3,4)]
>>> read "[((1,2),(3,4))]" :: [((Int, Int), (Int, Int))]
[((1,2),(3,4))]

If any of the reviewers don't like this PR, feel free to close it.


-- | Parser for constants of the given type.
constantOf :: ExpectParens -> DefaultUni (Esc a) -> Parser a
constantOf expectParens uni =
Copy link
Member

Choose a reason for hiding this comment

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

I think the expectParens parameter is useless now?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Nope, we still can't allow (con data I 42), it has to be (con data (I 42)).
While (con (list data) [I 42]) is fine.
So the distinction still exists.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants