Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Comment regarding comment ambiguity #186

Closed
pnathan opened this Issue · 6 comments

3 participants

@pnathan

Suppose:

[describe.number.#]
blathering = "here"   

But, consider these definitions - the comment one first:

They go from the symbol to the end of the line.

vs.

Name your key groups whatever crap you please, just don't use a dot. Dot is reserved. OBEY.

and:

Keys start with the first non-whitespace character and end with the last non-whitespace character before the equals sign.

This results in two correct parses: describe.number. or describe.number.#.

While ambiguity is good in poetry, it drives parsers mad.

@88Alex

The example you gave is syntactically incorrect, as there is no ] tag, but I think that the correct parse would be describe.number.

@pnathan

Alex, I don't understand what you mean. There is a ] character.

The spec indicates that I can either strip out # and everything following, or everything between [] is a valid keygroup.

@88Alex

Well, there is a ] character, but it's commented out.

If this answers your question, I believe # characters aren't allowed in keygroup names. If they were, it would lead to so much confusion.

@pnathan

The spec is ambiguous. As I point out in the filing of the issue, it can be read to both allow or disallow comment characters in the keygroup.

Name your key groups whatever crap you please, just don't use a dot. Dot is reserved. OBEY.
@88Alex

The specification should be updated to this:
"All characters are allowed in key-group names, except for these: = [ ] # ."

@BurntSushi
Owner

I've interpreted the spec to allow # in both table names and key names.

I think @pnathan is right here. This is an ambiguity. If we fix the wording in the spec, then it needs to be for both table names and key names. Or we could allow # in table names and key names. Either way, a clarification seems good.

@BurntSushi BurntSushi closed this issue from a commit
@BurntSushi BurntSushi Fix #186 by disallowing # in keys.
Also cleared up the wording of unordered key/values, as per parkr's
request.
e80e697
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.