Re: XPL Analyzer

Hans-Peter Diettrich <>
Tue, 13 Jun 2017 06:45:55 -0400 (EDT)

          From comp.compilers

Related articles
XPL Analyzer (Shoefoot) (2017-06-05)
Re: XPL Analyzer (Robin Vowels) (2017-06-05)
Re: XPL Analyzer (George Neuner) (2017-06-05)
Re: XPL Analyzer (Shoefoot) (2017-06-07)
Re: XPL Analyzer (mac) (2017-06-08)
Re: XPL Analyzer (SLK Parser Generator) (2017-06-09)
Re: XPL Analyzer (George Neuner) (2017-06-09)
Re: XPL Analyzer (Hans-Peter Diettrich) (2017-06-13)
Re: XPL Analyzer (Ben Hanson) (2017-07-30)
| List of all articles for this month |

From: Hans-Peter Diettrich <>
Newsgroups: comp.compilers
Date: Tue, 13 Jun 2017 06:45:55 -0400 (EDT)
Organization: Compilers Central
References: 17-06-002 17-06-006 17-06-007 17-06-011
Injection-Info:; posting-host=""; logging-data="49390"; mail-complaints-to=""
Keywords: parse, history
Posted-Date: 13 Jun 2017 06:45:55 EDT

Am 09.06.2017 um 19:20 schrieb George Neuner:

> In that case, (our moderator) John's suggestion is probably best ...
> if you have the grammar, then plug it into an (LA)LR tool and have it
> generate tables for you.
> I'm not familiar with the book you mentioned, but if a grammar is
> provided [even if not in EBNF], it should be possible to translate it
> for a modern tool.

At least I could find a grammar in BNF, by following the links in
Wikipedia to <>.

If I had to write an XPL compiler, as an excercise, I'd try to handcraft
an LL(1) top-down parser for it. This approach will give more insight
into "how to write a compiler", than understanding how to use a compiler
generator. Finally that compiler can be rewritten in XPL. Much time will
have to be spent in implementing the system library (Implicit
Declarations) and memory management.

[It does depend on whether you want to write a modern compiler or one that
someone might have written back when XPL was new. -John]

Post a followup to this message

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