Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does not support ! pegjs operator #9

Open
Pyrolistical opened this issue Sep 11, 2017 · 10 comments
Open

Does not support ! pegjs operator #9

Pyrolistical opened this issue Sep 11, 2017 · 10 comments

Comments

@Pyrolistical
Copy link

Pyrolistical commented Sep 11, 2017

On your example site if you load the JavaScript grammar we have

ExpressionStatement
  = !("{" / FunctionToken) expression:Expression EOS {
      return {
        type:       "ExpressionStatement",
        expression: expression
      };
    }

and the diagram looks like
screen shot 2017-09-10 at 8 16 34 pm

As far as I understand, that is an invalid railroad diagram.

@dundalek
Copy link
Owner

Yeah, that's a negative lookahead. I represent it as a branch with two slashes before it (as you can see on the diagram). The idea is to indicate it is there, but you cannot go through it so it is not part of the parsed result.

Do you have a better way to represent it in mind?

@Pyrolistical
Copy link
Author

Without words, I think this is more clear
screen shot 2017-09-21 at 6 41 05 pm

@dundalek
Copy link
Owner

Hmm, I guess I slightly prefer the first arrangement, since it indicates that parser checks the lookahead first and then continues with the rest. But I like the idea of the cross symbol, I might try to use that since it is distinguishable from the start/end symbols.

@dundalek
Copy link
Owner

@Pyrolistical What do you think of this?

image

@Pyrolistical
Copy link
Author

Pyrolistical commented Sep 22, 2017

I don't see the value of having the X in the front nor having it connect back to the beginning of Expression. Yes this is describing more closely to what the parser is doing, but this is a railroad diagram. I feel my version is more in the spirit of a railroad diagram. Every line you follow is a valid syntax, except we are adding a concept of an invalid path with the X

@jakwings
Copy link

jakwings commented Dec 11, 2017

How about this?

(fig.1 all sub items in the lookahead branch keep using dashed border lines)
fig.1

(fig.2 only markers)
fig.2

@jakwings
Copy link

Or like this:

(fig.3 use ( and ) to mark the start and end)

fig.3

@jakwings
Copy link

And this:

(fig.4 mark the area with dashed lines)
fig 4

@dundalek
Copy link
Owner

Thanks for the suggestions @iology. I like the dashed variant in fig.1. However, it still feels a bit inconclusive for me to implement it.

@jakwings
Copy link

I like fig.4 the most, but I may need to modify the railroad-diagram package. (looking into it)

fig.1 and fig.2 do not work quite nice when there is no branching and when there are nested lookaheads. fig.3 is a bit verbose and we have to find the corresponding start&end markers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants