Grammar-based approach?

[domenic]

I think it'd be interesting, at the very least, to have a formal grammar for the names. Once you had that, you could move from the current algorithmic-parsing to one that applies different semantics to each syntactic goal. Perhaps I am too brain-damaged from reading ES specs but to me that would be easier to parse than the algorithm, and probably has other benefits in terms of guaranteed unambiguity etc.

[darobin]

I certainly won't deny that the algorithmic approach is painful to read (it's not pleasant to write either). But I'm unsure about switching. Traditionally, grammar-based approaches have not been very good at producing interoperability; though it could be that in this case we could make it work since we can describe the behaviour on failure rather simply. And the grammar is pretty simple:

^([^\[]+)(?:(\[\d+\])|(\[[^\]]+\]))*(\[\])?$

I need to mull this over. Do you have a clearer example of what you have in mind?

[domenic]

Well, I am not really familiar with the formal language stuff myself (sadly), but my impression was it would be based on parsing goals. Things like

Simple := <token>
ArrayIndex := <token> "[" <number> "]"
Append := <token> "[]"
Terminator := Simple | ArrayIndex | Append
Intermediate := Simple | ArrayIndex
Beginning := "" | Intermediate | Beginning Intermediate
Full := Beginning Terminator

(this is not correct in any way but meant to illustrate what I meant.)

The parsing goal is then Full, but you would specify how to handle each piece of it in some way.

Most of what I know on this subject I learned in a 30-minute talk at JSConf EU so maybe somebody who can form the words better could step in here...

[Boldewyn]

A bit off-topic, but we could piggy-back RFC 6901 (JSON Pointer), where a grammar comes delivered free.

The syntax would be a bit different. And I seem to remember, that I suggested this before, but can't find the issue, where I did.