Re: Scannerless parsing was: Why does the lexer convert text integer lexemes ...?

"Ev. Drikos" <drikosev@gmail.com>
Fri, 22 Jul 2022 12:29:40 +0300

          From comp.compilers
Related articles
| List of all articles for this month |
From: "Ev. Drikos" <drikosev@gmail.com>
Newsgroups: comp.compilers
Date: Fri, 22 Jul 2022 12:29:40 +0300
Organization: Aioe.org NNTP Server
References: 22-07-011 22-07-030 22-07-036 22-07-042
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="78604"; mail-complaints-to="abuse@iecc.com"
Keywords: lex, design
Posted-Date: 22 Jul 2022 13:01:47 EDT
Content-Language: en-US

On 21/07/2022 13:41, Ev. Drikos wrote:
> ...
>
> [I don't see how this grammar will allow a comment before the statement.
> -John]




The where-used list of the separator contains four regular rules. Which
means I've added them explicitly, as shown at the end of the message.


What I suspect may be restrictive is that the lookahead operator accepts
only the next token, simply one letter in a scannerless grammar. Yet, in
SQL the (Unicode) delimited identifier doesn't end ie with a repeated
symbol as the identifier body of a regular identifier.


Here is the grammar for further inspection and error report:
https://gist.github.com/drikosev/3104c3cb79b0b4d8f41da6162f4c65d3




Regards,
Ev. Drikos




-----------------------------------------------------------------------
<direct SQL statement> ::=
                        [ <separator> ] <directly executable statement> <semicolon>


<binary string literal>::= X<quote>[{<hexit><hexit>}...]<quote>
                                [{<separator><quote>[{<hexit><hexit>}...]<quote>}...]




<national character string literal> ::= (too long) ...


<Unicode character string literal> ::= (too long) ...

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.