Sync ABNF and Specification

[pradyunsg]

Fixes #485
Fixes #464
Closes #472
Closes #458
Closes #484

I've made a first pass on the ABNF and README. I think this is close to complete.

Obviously, I'm open to comments and suggestions. :)

[pradyunsg]

/ping @BurntSushi

Pretty sure you got a notification but a mention can't hurt. ;)

[ChristianSi]

Looks good to me (though I didn't check the ABNF in detail).

[pradyunsg]

It might be a good idea to put the ABNF in the README itself. That way, anyone reading the specification can also see the relevant ABNF. Further, the abnf code snippet will make more sense with context. It might mean a script that does sanity checks on the READMe though -- like is the given grammar valid -- but that is no more effort than it is currently to validate the grammar IMO.

Here's a tiny preview of what I'm suggesting. I'm using the details tag to hide the ABNF. You can click on it and it'll show. :)

---

Integer

Integers are whole numbers. Positive numbers may be prefixed with a plus sign. Negative numbers are prefixed with a minus sign.

int1 = +99
int2 = 42
int3 = 0
int4 = -17

For large numbers, you may use underscores between digits to enhance readability. Each underscore must be surrounded by at least one digit.

int5 = 1_000
int6 = 5_349_221
int7 = 1_2_3_4_5     # VALID but discouraged

Leading zeros are not allowed. Hex, octal, and binary forms are not allowed. Values such as "infinity" and "not a number" that cannot be expressed as a series of digits are not allowed.

64 bit (signed long) range expected (−9,223,372,036,854,775,808 to 9,223,372,036,854,775,807).

ABNF

integer = [ minus / plus ] int

minus = %x2D                       ; -
plus = %x2B                        ; +

int = DIGIT / digit1-9 1*( DIGIT / underscore DIGIT )
digit1-9 = %x31-39                 ; 1-9
underscore = %x5F                  ; _

[mojombo]

These changes all look good, thanks!

It might be a good idea to put the ABNF in the README itself. That way, anyone reading the specification can also see the relevant ABNF. Further, the abnf code snippet will make more sense with context.

This is an interesting idea, and the JSON RFC relies heavily on inlined ABNF. It's possible that once we have the ABNF nailed down, we should attempt a rewrite of the TOML spec prose to do the same, which would probably reduce a lot of the tortured (and contentious) descriptions of the technical nuances. Let's tackle that in a separate issue or PR.

[pradyunsg]

Thanks @mojombo! Great to see you around! ^>^

Lemme know if there's anything I can help with. :)