Re: A minimal LL(1) parser generator ?

carlglassberg@gmail.com
Sun, 5 Jan 2020 11:59:45 -0800 (PST)

          From comp.compilers

Related articles
[6 earlier articles]
Re: A minimal LL(1) parser generator ? carlglassberg@gmail.com (2020-01-01)
Re: A minimal LL(1) parser generator ? gaztoast@gmail.com (honey crisis) (2020-01-02)
Re: A minimal LL(1) parser generator ? anton@mips.complang.tuwien.ac.at (2020-01-02)
Re: A minimal LL(1) parser generator ? gneuner2@comcast.net (George Neuner) (2020-01-02)
Re: A minimal LL(1) parser generator ? rockbrentwood@gmail.com (2020-01-04)
Re: A minimal LL(1) parser generator ? gaztoast@gmail.com (honey crisis) (2020-01-05)
Re: A minimal LL(1) parser generator ? carlglassberg@gmail.com (2020-01-05)
Re: A minimal LL(1) parser generator ? carlglassberg@gmail.com (2020-01-05)
Re: A minimal LL(1) parser generator ? carlglassberg@gmail.com (2020-01-05)
Re: A minimal LL(1) parser generator ? anton@mips.complang.tuwien.ac.at (2020-01-22)
Re: A minimal LL(1) parser generator ? anton@mips.complang.tuwien.ac.at (2020-01-22)
Re: A minimal LL(1) parser generator ? carlglassberg@gmail.com (2020-01-23)
| List of all articles for this month |

From: carlglassberg@gmail.com
Newsgroups: comp.compilers
Date: Sun, 5 Jan 2020 11:59:45 -0800 (PST)
Organization: Compilers Central
References: 19-12-016 19-12-030 19-12-032 19-12-040 20-01-001 20-01-003
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="3315"; mail-complaints-to="abuse@iecc.com"
Keywords: parse, syntax
Posted-Date: 05 Jan 2020 15:29:48 EST
In-Reply-To: 20-01-003

On Thursday, January 2, 2020 at 10:21:53 AM UTC-8, Anton Ertl wrote:
...
> (( a b && c d && ))


1. For concatenation of these, I would write, in Gray:
      ((a b &&))((c d & &&)) for EBNF: a { b a } c { d c }
because wouldn't
      ((a b && c d & &&))
be the same as?
      a { b a } c { d a { b a } c }


2. Let us compare separator-list notation.


In Waite and Goos, "Compiler Construction", there is an infix operator, "||", for separator list, not to be confused with Gray's meta-symbol for "or".
And Eiffel has a special notation for separator list.


In comparison, Anton's Gray has a postfix operator, "&&", for separator-list.


/Comparison of separator-list notation in
Waite/Goos EBNF, Eiffel EBNF (BNF-E), and Gray EBNF/


                                                              Wirth EBNF Gray EBNF:
-------------------------------------------------------------------
Waite/Goos: x || y ==========> x { y x } x y &&


In Eiffel: { x y ...}* ===> [ x { y x } ] (( x y && )) ??
                        { x y ...}+ ===> x { y x } x y &&
-------------------------------------------------------------------


What is better about Gray is that it only uses braces in action semantics,
in doubled form {{ ... }}, and no one is likely to be confused by the use of
braces.


Also it's postfix separator-list operator, "&&", is easier to remember than
Eiffel's more verbose special variation of standard EBNF braces.


And Gray's "&&" separator-list operator is just another postfix op, consistent with it's use of "??", "**" and "++"


Gray better separates the 2 styles of notation, it's "regular expression" style versus standard bracketed EBNF style.


The 2 styles ideally should not be mixed, or at least confusion should be avoided by not introducing yet another similiar notation, in the form of a special variation of standard EBNF braces for separator lists.


One minor criticism of Gray:


I do wish Gray had a production rule terminator, say semicolon ";" or stop "."


The end of 1 rule would be clearly distinguishable from the beginning of the next without special processing of end-of-line which makes scanning and
parsing space sensitive. We would avoid the need for LL(2) parsing or other
parsing and scanning techniques.


Carl
----


Post a followup to this message

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