[GH-ISSUE #569] Simplify the Backus-Naur notation slightly... #4658

New Issue

GiteaMirror · 2026-06-13T12:57:41-05:00

GiteaMirror commented

2026-06-13 12:57:41 -05:00

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,

<numeric identifier> ::= "0"
                       | <positive digit>
                       | <positive digit> <digits>

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

<numeric identifier> ::= <digit>
                       | <positive digit> <digits>

be equivalent?

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, ``` <numeric identifier> ::= "0" | <positive digit> | <positive digit> <digits> ``` 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 ``` <numeric identifier> ::= <digit> | <positive digit> <digits> ``` be equivalent?

GiteaMirror added the question waiting for PR labels 2026-06-13 12:57:41 -05:00

GiteaMirror commented

2026-06-13 12:57:43 -05:00

@runeimp commented on GitHub (Jun 9, 2020):

It is not the same. The <numeric identifier> needs to be 0, a positive digit, or two or more digits starting with a positive digit making the entire identifier positive. Essentially a uint vs an int. A <digit> can be any integer positive or negative so your variant would allow for negative number identifiers which is not allowed.

@runeimp commented on GitHub (Jun 9, 2020): It is not the same. The `<numeric identifier>` needs to be `0`, a positive digit, or two or more digits starting with a positive digit making the entire identifier positive. Essentially a `uint` vs an `int`. A `<digit>` can be any integer positive or negative so your variant would allow for negative number identifiers which is not allowed.

GiteaMirror commented

2026-06-13 12:57:43 -05:00

@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.

@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.

GiteaMirror commented

2026-06-13 12:57:44 -05:00

@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. 👼

@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. 👼

GiteaMirror commented

2026-06-13 12:57:45 -05:00

@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.

@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.

GiteaMirror commented

2026-06-13 12:57:46 -05:00

@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.

@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.

GiteaMirror commented

2026-06-13 12:57:47 -05:00

@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.

@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.

GiteaMirror commented

2026-06-13 12:57:47 -05:00

@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".

@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".

GiteaMirror commented

2026-06-13 12:57:48 -05:00

@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

@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

GiteaMirror commented

2026-06-13 12:57:49 -05:00

@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.

@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.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#4658