forked from zaach/jison
-
Notifications
You must be signed in to change notification settings - Fork 20
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
Use sub part of the parser #65
Comments
I haven't worked with the core code for quite some time, so apologies up
front for possible faults in my recall.
The short(-ish) answer is no (as in: this is technically possible but
recursive invocation of a generated parser may have unexpected side effects
and should only be done when you have very special requirements and need
environment changes during parse. I cannot think of an example that would
make sense right now.)
The longer answer is: why would you do it that way?
It would make sense when, for example, you are intent on parsing another
QUITE DIFFERENT independent grammar that is encapsulated in that term. Say,
for example, you are parsing a script language in grammar A, where you have
embedded SQL in string rvalues as grammar B, where you feed the string
tokens produced by grammar A parse to your grammar B (SQL in this example)
to pull it apart further there. Ergo: this sort of thing is usually only
done in very advanced scenarios where other design decisions have resulted
in the requirement of having to have two different grammars (maintenance
arguments, f.e.)
Your parseMathExpr() suggestion MAY be a sensible design decision when you
want to look at expressions embedded in constant string values -- my
personal preference as a language designer would however be to see if I
could set up the lexer and parser language in such a way that I would have
the lexer chop up such strings in series of tokens and then augment the
parse grammar such that I can parse any viable expressions hiding in string
constants like that without the need of such recursive parse calls. And
when such a expression-hiding-in-string parse rule (rule set) fails, take
those lexer tokens and glue them together into a single constant string
token instead as a cop-out-on-not-having-found-a-viable-subexpr-in-string.
I imagine producing lexer tokens sequences like this one:. OPENQUOTE ID
OPERATOR ID COLON CLOSEQUOTE for a sample input like "a + b:", and I would
then have think about how I would handle the
OPENQUOTE error CLOSEQUOTE
rule as it's action code would have to produce a basic STRINGCONSTANT from
that lexer tokensequence instead.
(I would have to really dig into the Jason internals again before I would
be able to produce a working example though!)
In this example one could therefore argue sensibly to make the
expression-hiding-in-string stuff a separate grammar and invoke that second
grammar's parser from within the action code for the STRINGCONSTANT token,
either in the lexer or parser phase.
This would be a-okay as you would always have a non-recursive parser A
action code block calling parser B parser, which would be independent and
therefore just act like any other library function call.
Your parseMathExpr() however reads to me like a recursive invocation of
(part of) parser A by action code in parser A, which feels.... strange.
In THEORY, I kept reentrance in mind while modifying the jison parser and
lexer cores, but from a language design perspective this way of using it
still feels strange and immediately raises the question in my brain: why do
you do this? Why can't you accomplish the same by making your parser rules
themselves capable of handling your needs instead, I.e. why can't what you
want be done in a straight (LALR or LR) grammar?
Because, when you write it in your grammar rules, you get to keep the speed
and power advances of the table based parser. Function calling a
(sub)parser as (parser rule action) is way more common in LL style parsers,
which are usually stack based (recursive rule parse functions calling one
another).
Don't know if this helps you move forward or only raises questions, but my
covering answer would therfor be: without knowing specifics, this is
generally advised against (unless it's a parser A calling parser B scenario
where parser input is a mix of two independent languages which must be
parser at the same time). If you absolutely must, I believe it can be done,
but be sure to have intimate understanding of the parser core then and have
confidence about your awareness of potential risks and side effects, PLUS
confidence in your ability to debug and fix any weirdnesses you will
encounter along the way.
The parser core is designed to be reentrant and can be invoked recursively
(IIRC), but I am hard pressed to imagine a scenario where this is mandated.
HTH
…On Wed, Feb 9, 2022, 10:02 dooxe-creative ***@***.***> wrote:
Hello !
Let's say we have the following parser grammar :
element
: mathExpr
| STRING
;
mathExpr
: NUMBER
| mathExpr '+' NUMBER
;
I'm wondering whether it is possible, inside actions, to use kind of
"parseMathExpr(myString)" ?
Thanks
—
Reply to this email directly, view it on GitHub
<#65>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADCIHR4AGDKA4ZFHDOTUO3U2IUTJANCNFSM5N43CGJQ>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Thanks a lot for your (very) extensive reply! I ended up with the following solution inspired from your reply: I have a dedicated parser for mathematical expressions, that are surrounded by a specific character. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello !
Let's say we have the following parser grammar :
I'm wondering whether it is possible, inside actions, to use kind of "parseMathExpr(myString)" ?
Thanks
The text was updated successfully, but these errors were encountered: