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
Add support for picking fields with @
#38
Comments
Like the idea in principle. Will this syntax clash if we decide to use |
Oh, great question. Let's mock those in when we first implement this, and make sure the grammar doesn't clash. In peg.js, it's pretty straightforward, and applies only on the RHS of rules: https://github.com/pegjs/pegjs/blob/b7b87ea8aeeaa1caf096e2da99fd95a971890ca1/src/parser.pegjs#L148 |
I personally prefer to reserve Having |
Are there any other ASCII-7 characters available? I'd like to make sure we're not misaligned with https://github.com/tc39/proposal-decorators as it goes to stage 3, if possible. |
|
How about "any rule starting with an underscore". Since this could potentially break existing code, hide this behind an opt-in. Next step is auto-generating such rules, i.e.
where |
@TymurGubayev syntax changes should be purely additive imo. It's really important that we don't break the grammars that exist in the wild. |
Another possible way of evolution -- change how the At least two options can be suggested:
|
I'm -1 on this. A more nuanced reading of the link above might be "There are problems with ASI no matter which way you choose. Make sure to use lint rules to protect yourself either way." I really don't want us to pick a side on this, because it will alienate a bunch of people either way we pick for not enough benefit. |
This has been repeatedly suggested throughout the years. This breaks javascript and must not occur. |
No they don't. Your preferred eslint config is not "modern JS rules." |
@hildjj - In the linked issue, you suggested that this could be used to ignore productions. At this time I do not yet understand how. The ability to ignore productions would be huge for me. I maintain a compiler behind peg mostly just for this. Would you show me how this syntax enables that, or did I misunderstand? |
If there are breaking changes, this is a meaningless anti-fork, and I will just resurrect my fork. No, we're not going to throw away the entire community on a whim to get a minor feature that can be had other ways. Don't be irresponsible. |
It would allow it by solving a slightly different problem: marking the productions you want to save. If the syntax is small enough, it seems like an approach you might like just as well as marking the ones you want to ignore. |
Let's all assume good intent from everyone involved, please. We'll make decisions together, but ideas that we don't take may kick off new ideas that we do like. |
Any significant breaking change means this library is useless to me, and the original must be re-saved. This will almost certainly be true of every other user of the old library. I'm letting you know, right now, that people who clung to the old library for a year and a half after its old maintainer murdered it through negligence are doing so because they don't have a choice. If you make breaking changes, you're creating the exact same extermination choice. It's important to get this through everyone's head, early, or else you'll lose the whole thing over whimsy. The way to fork a dying library to save the old community is well understood. Don't re-murder it. |
Well, okay, that's fine, maybe even useful But please understand that it's critically different than the issue you tagged it from, and doesn't do anything at all for people who need to ignore productions |
I'm committed to backward compatibility. I'm committed to doing good semantic versioning to ensure that people can make good decisions about when to upgrade. I'm committed to being a steward for the community's consensus (see my work at the IETF for examples of how much I value consensus over my own opinions). Over time, hopefully we can build enough trust in those commitments. |
❤️
👍
🦾 |
I'm confusing: how is slight change of the PEG syntax can break (generated) js? Furthermore, requiring semicolons doesn't really introduce new syntax, but reuses existing one. I can't imagine any situation where you won't be able to switch from the optional semicolons to the required ones. That is why I think that this is the most safe way to resolve ambiguity (except using the other symbol, of course).
That is not my preferred config, honestly, I'm even don't use JS regularly. It is just ESLint default. And I think that people had some good reasons to make defaulted exactly that variant. So I think, that choice could be called "modern rules". |
Let's not get bogged down in any of the syntax wars here, please. Any valid JS should be able to go into an action block. |
Of course, of course, that is holy cow... My suggestion doesn't touch any code blocks at all, it is about semicolons in the grammar, not in the code blocks. Code blocks are always were opaque things and that remains unchanged. |
Nod, that's a helpful distinction. |
PR #89 is pretty close at this point. Now it's time to decide if we like it enough to land it. I do like it; I use Note that the example I added to the end of the documentation is:
which shows off how |
I think, that feature is ready to merging, clash with the proposed annotations syntax actually not so big and I think is easy solvable (if not by requiring semicolons, then by using, for example |
Needs a version bump for a release |
Yep, I'm going to do that on #101 since this isn't the only feature. |
as discussed at pegjs/pegjs#11,
I use this syntax frequently when it's available.
The text was updated successfully, but these errors were encountered: