Can you consider adding a `result()` function

Issue type

• Bug Report: no
• Feature Request: yes
• Question: no
• Not an issue: no

Prerequisites

• Can you reproduce the issue?: yes
• Did you search the repository issues?: yes
• Did you check the forums?: yes
• Did you perform a web search (google, yahoo, etc)?: yes

Description

Kindly add a result() function that returns the entire result so far

currently to get the entire result so far, one would:

Expr = all:(  /* some other expression ... */ ) { return all }

This feature request is for you to consider adding a result() function (similar to the text() function) that would achieve the exact same thing as above in a much less verbose manner i.e. the above would instead be.

Expr =  /* some other expression ... */  { return result() }

[futagoza]

Since we are perfecting my example:

Namespace = Identifier NamespacePart* { return result(); }
NamespacePart =  _ "." _ name:Identifier { return name; }
Identifier = $[a-z]i*
_ = " "*

Happy 😝

I’ll add this to the v1 milestone 😄

[StoneCypher]

Maybe I’m missing something here… but I really don’t understand why anyone thinks of this as a breaking change?

Because common grammars that have existed for a decade, when put through this, will parse differently and break

.

More importantly, Instead of rushing to shoot the entire proposal down

This proposal is from 2018. Nobody is rushing.

.

may we focus our attention on alternative solutions that don’t break your code,

I already did. So did several other people in this thread.

It was pointed out to you in 2019 that simply removing the handler got you the result you wanted, as well.

.

Perhaps, add a complier option to explicitly opt into using this feature

There’s no need. This is already do-able with features that have been in there for years.

.

Hopefully we can all come to some consensus

Not likely. This library has been non-maintained for three years, and nothing has been published since 2017.

The major reason for this is that the current maintainer is more interested in chasing unnecessary half-features than just finishing the existing work that needs to be done.

If that pattern is continued, nobody will ever solve this because the library will never release again.

If that pattern is broken, nobody will solve this for a very long time, because there are things the library actually does need, that have outstanding PRs already working and tested, and those should retain priority.

I don’t understand why you’re pushing for this more than a year after someone told you how to do it, and hitting thumbs down on people saying “you don’t need this, here’s what to do” and saying “well can’t we look for a way to do this”

You’ve been given several ways to do this.

I’m trying to get the original owner to give me the ability to bring this library back to life.

• I believe that the single most important thing to bringing this library back to life is focusing on getting a normal healthy release pattern happening.
• I believe that the second most important thing is focusing on important issues, like fixing es6 support, and outstanding bugs in the parser, like the cache bug, or that some of the AST nodes are misspelled.
• I believe that the next most important thing is making the user-developer joining story easier.
• I believe that the next most important thing is making the contributor-developer joining story easier.

The current maintainer allowed the 0.11.0 release to grow for three years, until he doesn’t trust it, won’t release it, is throwing it away, and starting the whole library over from scratch. In order to fix that, priorities must be set.

I believe that the #1 priority is getting npm releases back to something regular. I believe #2 is removing the hipster tools and getting back to a simple clean build. I believe #3 is fixing the distribution so that it works in modern tooling, which is a four line fix.

I’m going to keep churning heavy duty cross-user pain point.

If David lets me resurrect this library, here’s the answer you’re going to get from me:

I don’t think this is a priority, because you can get what you’re asking for simply by removing the handler you wrote.

If you can show me a case where this is significantly more powerful, expressive, or easier than the things you were already told about, I’m open to looking again, but your actual example was already fixed for you.

At this time, peg 0.12.0 needs to focus on major issues and coming back to life. This is scheduled past 1.0, with the expectation that unless someone explains something to me or submits a well tested PR, this probably will not actually happen.