-
Notifications
You must be signed in to change notification settings - Fork 2
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
[#6] Add a switch for allowing comments #16
base: master
Are you sure you want to change the base?
Conversation
262a1c4
to
9958b29
Compare
Good, I see you are delving into the project quite well. One thing to note: to me it seems like we could handle comments skipping at parsing stage directly, this should be simpler. It is fine to pass |
9a1614f
to
3e2d1e1
Compare
You probably was thinking about whether to add this too: I would also skip |
Functionally this looks great 👍 Now you also need to update documentation. I would include the new switch description in Plus, in txt = [int||
My text
// comment
other text
|] would have ... result. And if we guarantee that in docs, we will also need a test on such case. |
@@ -223,6 +223,10 @@ The quoter will return concrete t'Builder'. | |||
|
|||
The quoter will return any type with t'FromBuilder' instance. | |||
|
|||
==== c ([c]omments handling) | |||
|
|||
Ignore line comments starting with @--@ and/or block comments enclosed in @{- ... -}@. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would use some different wording, as "ignore" may mean "ignore it in processing, do not treat it in a special way" and so "leave it intact".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, I've decided to go for Handle comments
and providing some clarifying examples. Hope it makes more sense now :)
BTW I've moved the lines upwards a little, now the section's before the ones about the return types.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh that's actually good that you moved this section above, right.
We are approaching the perfect solution, should be mostly it. One probably last concern that I have: the examples you provided in documentation make it fully evident that currently block comments handling has inconvenient spacing. Writing Let's make block comments ignore the space before them, if any? "Before" to make trailing block comments handled well too. |
Problem: We want the interpolator to support commentaries in arbitrary lines. Solution: Implement a switch to allow writing comments and add some tests against the implementation.
4ae43ac
to
fc4c8d2
Compare
Oh, right. That test actually didn't contain the evidence, sorry |
skipBlockComment' = asum | ||
[ skipBlockComment "{-" "-}" | ||
, try $ spaceChar *> skipBlockComment "{-" "-}" | ||
] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would rather write the clause with space removal as an extension of the "fast spacing" section above - to avoid extra rollbacks.
Generally, I find this approach good, you got the code grouped by the logic it is related to. But in our case performance matters (as we write a library), and the grammar is quite small, so we can afford some complication.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But in our case performance matters
Yup, totally agree
comments in the middle -} | ||
The end | ||
|] @?= "The beginning\nThe end\n" | ||
] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would also like tests on:
- Unusual space - e.g. tab;
- On several spaces before comment.
Behaviour in such cases should be fixed.
And documented (no need to mention edge cases, just write the rule in one-two sentences so that it is unambiguous in regard to these edge cases).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Behaviour in such cases should be fixed.
"My text (4 spaces) { - comments -} " -> do you mean that, in this case, the result should be "My text "? Do several spaces should get truncated to a single one?
And, aside from that, please consider this one:
{int|tc|
My text
-- comments
end
|]
results in " My text\n\n end" - the indentation becomes two spaces, since the line comment has two leading empty spaces. Intuitively, one might expect the indentation to be totally stripped, and since we now support extra spaces removal for block comments, shouldn't we handle this case too?
This implements a switch to allow having comments
Description
Related issue(s)
Resolves #6
✅ Checklist for your Pull Request
Related changes (conditional)
Tests
silently reappearing again.
Documentation
Public contracts
of Public Contracts policy.
and
Stylistic guide (mandatory)