mirror of
https://github.com/semver/semver.git
synced 2026-07-11 08:02:23 -05:00
[GH-ISSUE #569] Simplify the Backus-Naur notation slightly... #3129
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#3129
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @jameskregar on GitHub (May 26, 2020).
Original GitHub issue: https://github.com/semver/semver/issues/569
Looking at the BNF for numeric identifier,
it appears to me that you could simplify it by combining the first 2 alternates. Since <digit> would allow either "0" or <positive digit>, shouldn't
be equivalent?
@runeimp commented on GitHub (Jun 9, 2020):
It is not the same. The
<numeric identifier>needs to be0, a positive digit, or two or more digits starting with a positive digit making the entire identifier positive. Essentially auintvs anint. A<digit>can be any integer positive or negative so your variant would allow for negative number identifiers which is not allowed.@jameskregar commented on GitHub (Jun 9, 2020):
If
<digit>could be a negative integer, I would agree with you, but it is defined in the same document as:<digit> ::= "0" | <positive digit>The only real difference between
<digit>and<positive digit>is that the<digit>class allows for 0 while<positive digit>does not. So for any multidigit number, as it must not start with a '0',<digit>cannot be used as the first character. Instead a multidigit number must start with a<positive digit>, after which any single digit number can be use, and so<digits>(which is a collection of one or more of the<digit>class) is appropriate.If I am not understanding this correctly, then I would ask for an example of a number that would be allowed under one form but not the other.
@runeimp commented on GitHub (Jun 9, 2020):
Doh! My bad. You are correct on all counts. Knew I should have reviewed the BNF again before answering. 👼
@jwdonahue commented on GitHub (Jun 9, 2020):
@jameskregar, is the longer form difficult to understand? The current form follows the descriptive text of the standard. It might be true that it can be simplified, but then the reader has to think harder about the implications. That fact probably saved us at least one round of explanations when we were working up the Regex last year, and the year before that.
@jameskregar commented on GitHub (Jun 9, 2020):
With BNF, I generally expect that a literal will only be used when it is impossible (or very awkward) to define an element with other elements alone. When I looked at it and looked at the definitions of
<digit>and<postiive digit>, I immediately wondered why it could not be just<digit>. As such, I did spend some extra time trying to figure out what I was missing when reading this BNF.So, is it difficult to understand: no, but it did cause me to re-read the digit definition 2 or 3 times to make sure I wasn't missing something. If I was referencing the BNF while reading the descriptive text, then yes, maybe the current way would make more sense.
My vote is usually with the simplest form for BNF, and having only 2 options instead of 3 would be slightly simpler. But in the end, either method is technically correct, and this could be more of a style judgement.
If the decision is to keep it as is, then I will close the issue, with no hard feelings.
@jwdonahue commented on GitHub (Jun 9, 2020):
Ya, I think my inclination would be to fix it as well. Given the definition of
<digit>as"0" | <positive digit>, I think my rationale above may have been spurious. It really doesn't seem like too much abstraction to simplify it. But given how difficult it is to push these kinds of changes through, I think that it should be tagged "Needs a PR" and then closed if you aren't willing to champion the PR. I don't think I'll have the time for it.@jameskregar commented on GitHub (Jun 9, 2020):
Well, I am completely new to Github and have never actually used Git, so I don't know how to PR (I assume PR = Pull Request). If someone wants to point me towards a basic tutorial, I'll give it a shot, otherwise I will close it as "Needs a PR".
@jwdonahue commented on GitHub (Jun 10, 2020):
It's easy, first you fork the repo, then when you're ready with the changes, you start a PR. Here's some links that might be useful:
https://gist.github.com/MarcDiethelm/7303312
https://github.com/semver/semver/blob/master/CONTRIBUTING.md
https://github.com/firstcontributions/first-contributions
@Vampire commented on GitHub (Aug 21, 2020):
This is basically a duplicate of parts of #258, that were pulled out separately too as #575 where already suggestions for simplifications are included that only wait for decision by maintainers to become a PR.