Allow spaces in type specifiers

[pingiun]

Disallowing spaces in certain places inhibits tokenisation. Of course a parser that doesn't tokenise the input beforehand doesn't suffer from this, however my parser does and it's much easier to ignore most spaces.

The following examples are rejected by the specified grammar:

• (type )node
• ( type)node
• (type) node

I think it should be fine to accept these cases, as it doesn't create confusion and makes it easier to write parsers

[larsgw]

Whitespace between the type annotation and the node name was discussed in #131, I'm not sure whether the first two examples were considered/discussed.

[pingiun]

I just thought about the rule of having no spaces between =, which I think makes a lot of sense. Of course this also introduces the same problems in my tokeniser, so it seems I'll have to deal with this anyway

[tabatkins]

Curious about the problems you're having with tokenizing - is it not possible to emit WS tokens and handle those at the parser level? Is there something deeper in KDL parsing making that difficult? (My KDL parser doesn't have a separate tokenizer, but CSS's syntax, which I wrote the spec for, does have a tokenizer/parser distinction like this.)

[pingiun]

Hmm I will need to take a look at emitting WS tokens, right now I have hacky tokenizer state that tracks if it has seen whitespace and such. I guess I just didn't think of emitting WS tokens