disclude `undefined` from data array, provide notreegen

Related to post processing and eliminating nodes, is there a value I can return from a matched token that will eliminate it from output automatically?

For example, it would be nice if I could just drop optional whitespace, such that–

selector _ combinator _ element

– would return an array of 3 elements instead of 5. I thought I could write:

_ -> null

– but then that just returned an actual null value. I can see why I might want to post-process based on null, so I’m not sure what to suggest, maybe a special nearley token? Like: %null% or something?

[kach]

As a global flag, it would look like this:

_ -> whitespacechar:*
__ -> whitespacechar:+
comment -> "/*" commentchar:+ "*/" | "//" commentchar:+ "\n"
@no-tree _
@no-tree __
@no-tree comment

I prefer this because (1) you can enumerate no-tree nonterminals in one place, (2) you can’t accidentally create a conflict where only some, but not all, rules for a non-terminal are no-tree’d, (3) you can quickly toggle no-tree-ness for a nonterminal without having to change it in multiple places.

[bojidar-bg]

Just my two cents (and my opinion about all the previous discussions…)

//(explicit, rule-bound) A prefix
@no-tree-or-no-output-or-just-match-or-whatever __ -> [\s] | __ [\s]

I somewhat like it, it is quite readable, and understandable, but as @Hardmath123 said, it can be confusing with multiple non-piped declarations.

//(explicit, rule-bound) Global configuration
__ -> [\s] | __ [\s]
@no-tree-or-no-output-or-just-match-or-whatever __

I actually dislike it, because the configuration is too much out of the context of the rule.

//(explicit, rule-bound) Changed arrow
__ -!> [\s] | __ [\s] //(This arrow looks better than !-> or -]> IMHO)

That’s the one I like the most, as it is more readable than (1). About the multiple non-piped declarations argument, I will say that it might be required to use only -!> or -> for a single rule.

//(explicit, use-bound)
a -> number !__ number {% /*now d is like [3,5], and not like [3,null,5]*/ %}

Tolerable, but it can be emulated by all the other variations by just changing the rule name. Also it might break existing grammars…

BTW, why >60% of this discussion have nothing to do with the issue topic? If you ask me, this issue should be split in at least 3 issues…