Is it possible to access what a positive assertion matches?

[mojavelinux]

When I use a positive assertion in a rule, I sometimes need to access the input matched by the assertion in order to store that information in the AST. Is it possible to access what was matched by a positive assertion by assigning it to a label or marking it with @. In other words, can I do this? (notice marker:&(...))

rule_name = marker:&([*]+ ' ') line:$[^\n]+ {
  console.log('marker is ' + marker)
  return line
}

I can see in the generated parser that there's a point in the rule function where the match is stored in a local variable. But that variable never gets passed to the action for the rule.

I'm trying to understand if I'm doing something incorrectly or if this is not something that peggy (and PEG in general) supports. Any insight would be appreciated.

I know there are other ways to get the information matched by the positive assertion since the input will eventually be consumed. However, it makes the grammar more complex and harder to understand. It seems to me like it should be possible to capture input that has already been found, even if by an assertion.

[Mingun]

Yes, that should be possible. Actually, it was possible but changed in one of linked PRs of this in the original repo, which was the wrong decision.

[mojavelinux]

It seems like the answer right now for peggy is that, yes, it can be bound to a variable, but the value is always undefined. If that assertion is accurate, I also believe that is the incorrect behavior.

[hildjj]

I'm worried about backward-compatibility. What if we used $& to be the capturing version, which always stringifies? It's currently not valid in the grammar.

Do you have an example where it would be useful for !, or the code forms ($&{ return true })?

[mojavelinux]

I don't think it would be useful in a negative assertion as nothing was matched. undefined makes complete sense there. It's really the positive assertion that's useful. It allows us to peer into what is about to be parsed, which for me comes in when I need to use predicates inside the ensuing rules or in the rule action.

In terms of syntax, I'm thinking more about capturing only when it is labeled (e.g., marker:&list_start). The idea is really to be able to pass that information to the semantic action for the rule. An example of where this comes up is listing parsing. Consider this rule:

list = marker:&list_start items:(lf* @list_item)+
  {
    const variant = marker[0] === '*' ? 'unordered' : 'ordered'
    return { type: 'block', name: 'list', variant, marker, items: items }
  }

We'd like to know the marker here before we start parsing the list items. I'm not making the case that this can't be done another way. There's almost always another way. But it seems very reasonable to be able to access something that has just been matched. It's right beyond our fingertips.