Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.compilers > #1883 > unrolled thread

XPL Analyzer

Started byShoefoot <shoefoot@gmail.com>
First post2017-06-05 01:48 -0400
Last post2017-07-30 14:01 -0700
Articles 8 — 6 participants

Back to article view | Back to comp.compilers


Contents

  XPL Analyzer Shoefoot <shoefoot@gmail.com> - 2017-06-05 01:48 -0400
    Re: XPL Analyzer "Robin Vowels" <robin51@dodo.com.au> - 2017-06-05 20:28 +1000
    Re: XPL Analyzer George Neuner <gneuner2@comcast.net> - 2017-06-05 22:17 -0400
      Re: XPL Analyzer Shoefoot <shoefoot@gmail.com> - 2017-06-07 18:56 -0700
        Re: XPL Analyzer mac <acolvin@efunct.com> - 2017-06-08 17:13 +0000
        Re: XPL Analyzer George Neuner <gneuner2@comcast.net> - 2017-06-09 13:20 -0400
          Re: XPL Analyzer Hans-Peter Diettrich <DrDiettrich1@aol.com.dmarc.email> - 2017-06-13 06:45 -0400
        Re: XPL Analyzer Ben Hanson <jamin.hanson@googlemail.com> - 2017-07-30 14:01 -0700

#1883 — XPL Analyzer

FromShoefoot <shoefoot@gmail.com>
Date2017-06-05 01:48 -0400
SubjectXPL Analyzer
Message-ID<17-06-002@comp.compilers>
I am in the process of writing an XPL compiler.  This is the language defined by McKeeman in his
book "A Compiler Generator".   While searching the net I have found some references to a version of
the XPL Analyzer that used LALR(1) parse tables.  Does anyone have source code for such a program?
[Haven't been able to find it, but of you want LALR tables it shouldn't be hard to
translate the published BNF grammar into a yacc or bison program.  If you don't want to use
the bison parser, it's not very hard to pull out the tables from the generated C. -John]

[toc] | [next] | [standalone]


#1885

From"Robin Vowels" <robin51@dodo.com.au>
Date2017-06-05 20:28 +1000
Message-ID<17-06-004@comp.compilers>
In reply to#1883
>I am in the process of writing an XPL compiler.  This is the language defined by McKeeman in his
> book "A Compiler Generator".   While searching the net I have found some references to a version
> of
> the XPL Analyzer that used LALR(1) parse tables.  Does anyone have source code for such a program?

Versions of XPL are available for a number of systems, including S/360, 390. etc.
and the PC.
McKeeman's book has the complete XPL compiler and Analyzer sources.

https://www.cs.toronto.edu/XPL/

I can supply the source for Optimising XPL.
[Thanks but as far as I can tell, none of those have LALR tables. -John]

[toc] | [prev] | [next] | [standalone]


#1887

FromGeorge Neuner <gneuner2@comcast.net>
Date2017-06-05 22:17 -0400
Message-ID<17-06-006@comp.compilers>
In reply to#1883
On Mon, 5 Jun 2017 01:48:30 -0400 (EDT), Shoefoot <shoefoot@gmail.com>
wrote:

>I am in the process of writing an XPL compiler.  This is the
>language defined by McKeeman in his book "A Compiler Generator".
>While searching the net I have found some references to a version
>of the XPL Analyzer that used LALR(1) parse tables.  Does anyone
>have source code for such a program?

I'm not sure I understand your question: do you have existing tables
that you'd like to plug in to a parser tool, or are you looking for
the (E)BNF source needed to generate tables?

There are some parser tools, e.g., Gold (http://goldparser.org), that
separate the tables and actions from the "engine" that executes them,
and that can demand load new table/action sets.

However, I'm not aware of any tool that can directly use pre-existing
"foreign" tables ... every tool I know of has to have generated the
tables itself.

George

[toc] | [prev] | [next] | [standalone]


#1888

FromShoefoot <shoefoot@gmail.com>
Date2017-06-07 18:56 -0700
Message-ID<17-06-007@comp.compilers>
In reply to#1887
On Wednesday, June 7, 2017 at 6:37:20 PM UTC-4, George Neuner wrote:
> I'm not sure I understand your question: do you have existing tables
> that you'd like to plug in to a parser tool, or are you looking for
> the (E)BNF source needed to generate tables?
>
> There are some parser tools, e.g., Gold (http://goldparser.org), that
> separate the tables and actions from the "engine" that executes them,
> and that can demand load new table/action sets.
>
> However, I'm not aware of any tool that can directly use pre-existing
> "foreign" tables ... every tool I know of has to have generated the
> tables itself.

Maybe I shouldn't have said "used LALR parse tables".  I should have
said "generated LALR parse tables".  The XPL grammar analyzer
generates something the author called MSP tables.  I was thinking it
would be more useful if it generated LALR tables.  Since I am in the
process of writing an XPL compiler I thought I could modernize the
grammar analyzer with something that would make the package more
useful.

I have no interest in converting tables from some other tool.

I was unaware of goldparser.org.  Thanks for the reference.  Currently
the goldparser project is not releasing the source of the grammar
analyzer so it does not help me find a solution.

[toc] | [prev] | [next] | [standalone]


#1890

Frommac <acolvin@efunct.com>
Date2017-06-08 17:13 +0000
Message-ID<17-06-009@comp.compilers>
In reply to#1888
My experience using a port of XPL back in the day was that it generated
these horrible syntax error messages, usually beginning <BOUND HEAD>(...

[toc] | [prev] | [next] | [standalone]


#1892

FromGeorge Neuner <gneuner2@comcast.net>
Date2017-06-09 13:20 -0400
Message-ID<17-06-011@comp.compilers>
In reply to#1888
On Wed, 7 Jun 2017 18:56:44 -0700 (PDT), Shoefoot <shoefoot@gmail.com>
wrote:

>  :
>The XPL grammar analyzer
>generates something the author called MSP tables. I was thinking it
>would be more useful if it generated LALR tables. Since I am in the
>process of writing an XPL compiler I thought I could modernize the
>grammar analyzer with something that would make the package more
>useful.

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.

I don't know how exactly XPL differs from PL/I, but PL/I grammars are
available from a number of sources.  You might find something that is
easier to work with than what is in the book.

George
[XPL is a PL/I subset cut down so it's reasonably easy to compile
and can generate fast code because it doesn't have to deal with all
of PL/I's corner cases.  It's the first of a long line of such
languages from Cornell's PL/C to IBM's PL.8 -John]

[toc] | [prev] | [next] | [standalone]


#1893

FromHans-Peter Diettrich <DrDiettrich1@aol.com.dmarc.email>
Date2017-06-13 06:45 -0400
Message-ID<17-06-012@comp.compilers>
In reply to#1892
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 <teampli.net/XPL/ldindex.html>.

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.

DoDi
[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]

[toc] | [prev] | [next] | [standalone]


#1900

FromBen Hanson <jamin.hanson@googlemail.com>
Date2017-07-30 14:01 -0700
Message-ID<17-08-001@comp.compilers>
In reply to#1888
On Thursday, 8 June 2017 03:25:23 UTC+1, Shoefoot  wrote:
> I was unaware of goldparser.org.  Thanks for the reference.  Currently
> the goldparser project is not releasing the source of the grammar
> analyzer so it does not help me find a solution.

You could try http://benhanson.net/parsertl.html instead as it provides full source.

Regards,

Ben

[toc] | [prev] | [standalone]


Back to top | Article view | comp.compilers


csiph-web