Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Name that PD parser generator

31 views
Skip to first unread message

Robert Corbett

unread,
Sep 6, 1989, 11:25:54 AM9/6/89
to

I have been asked to come up with another name for Zoo, since there is
apparently an archiver named Zoo. I do not see the problem. If you have the
other Zoo on your system, please feel free to change the name of one or the
other. Nonetheless, I am willing to entertain suggestions for other names.
To start the ball rolling, I will mention that Zoo was originally named Zeus
(a terrible choice) and Bison was originally named Byson. Please reply to
me rather than posting to news (save the bandwidth).

To those who feel I acted irresponsibly in not checking for name clashes
before making my program available, please feel free to not put Zoo on your
systems.

Yours very truly,
Bob Corbett
--
Send compilers articles to comp...@ima.isc.com or, perhaps, Lev...@YALE.EDU
{ decvax | harvard | yale | bbn }!ima. Meta-mail to ima!compilers-request.
Please send responses to the author of the message, not the poster.

Dave Jones

unread,
Sep 10, 1989, 9:58:24 PM9/10/89
to
>From article <1989Sep6....@esegue.segue.boston.ma.us>, by cor...@ernie.Berkeley.EDU (Robert Corbett):

>
> I have been asked to come up with another name for Zoo, since there is
> apparently an archiver named Zoo.
>

I've just finished a yacc-lookalike. I might have been able to use
Zoo, but when I started this one Sunday, I hadn't read about Zoo
yet. Well, there were some other reasons I wanted to do one from scratch,
besides the copyrights on other ones. For one thing, I wanted LR(1), not
LALR(1).

Anyhow, I too am puzzling over a name.

I used "Molly McYacc" as a working title. But I think I'm going to
go with "jaccl", sort of following through on the wild mammal motif.
It stands for "just another compiler-compiler lookalike".

Either that, or perhaps Mr. Corrbet will allow me to use the second best
name he receives. How about it, Robert? May I see the name list, after
you've picked over it?
[From djo...@megatest.uucp (Dave Jones)]

Scott Schwartz

unread,
Sep 11, 1989, 9:30:14 PM9/11/89
to
In article <1989Sep11....@esegue.segue.boston.ma.us> Dave Jones writes:
| besides the copyrights on other ones. For one thing, I wanted LR(1), not
| LALR(1).

SSL, by Rick Holt, is an LR(N) parser generator, and as far as I know
it is freely available. Does anyone (who isn't at Toronto :-) use
this? (SSL == Syntax Semantic Language, by the way.)
--
Scott Schwartz <schw...@shire.cs.psu.edu>

Keith Hanlan

unread,
Sep 13, 1989, 10:53:08 AM9/13/89
to
In article <1989Sep12....@esegue.segue.boston.ma.us> schw...@shire.cs.psu.edu (Scott Schwartz) writes:
>In article <1989Sep11....@esegue.segue.boston.ma.us> Dave Jones writes:
>| besides the copyrights on other ones. For one thing, I wanted LR(1), not
>| LALR(1).
>
>SSL, by Rick Holt, is an LR(N) parser generator, and as far as I know
>it is freely available. Does anyone (who isn't at Toronto :-) use
>this? (SSL == Syntax Semantic Language, by the way.)

S/SL is used here at Bell-Northern Research. In fact it was
partially funded by BNR. I used it at Queen's University when I
took a compiler course from Jim Cordy (one of the designers).
S/SL is simple, elegant, and very easy to develop and maintain.
I was quite impressed. Unfortunately all the reference material
I have on S/SL is proprietary. (It's so simple however, that
little is required)

The reference you want is:
Cordy, J.R. and Holt, R.C. [1980] Specification of S/SL:
Syntax/Semantic Language, Computer Systems Research Institute,
University of Toronto.

The address is:
CSRI, University of Toronto
Sanford Fleming Building,
10 King's College,
52S-1A4

416-978-8751

Rayan Zachariassen

unread,
Sep 14, 1989, 10:29:07 AM9/14/89
to
A usually more handy reference is:

"An Introduction to S/SL: Syntax/Semantic Language"
by R.C. Holt, J.R. Cordy, and D.B. Wortman,
in ACM Transactions on Programming Languages and Systems (TOPLAS),
Vol 4, No. 2, April 1982, Pages 149-178.

S/SL used to be a ``product'' but since only 4 or so places actually paid for
tapes I believe the authors consider it freely available (though
implementations are still copyrighted). At least, when I needed it for my
mailer and wrote a version in C, they agreed that it could be freely
redistributed subject to proper attribution when S/SL technology is used.

The proper address for CSRI is:

CSRI, University of Toronto
Sandford Fleming Building,
10 King's College Road,
Toronto, Ontario
Canada M5S 1A4


S/SL, in a nutshell, is compilable pseudo-code. A small language that defines
input/output/error token names (& values), semantic operations (which are
really escapes to a programming language but allow good abstration in the
pseudo-code), and a pseudo-code program that defines a grammar by the token
stream the program accepts. Alternation, control flow, and 1-symbol lookahead
constructs are part of the language. What I call an S/SL "implementation", is
a program that compiles this S/SL pseudo-code into a table (think byte-codes)
that is interpreted by the S/SL table-walker (interpreter). The S/SL compiler
is written using S/SL in case you need a real example. You supply the
table-walker, possibly based on a sample skeleton walker provided. I think
the pseudo-code language is LR(1), and that the semantic mechanisms turn it
into LR(N) relatively easily. It reminds me most of an abstract recursive-
descent approach.

You wouldn't use S/SL for off-the-cuff parsing needs, because the investment
in the table walker is much higher than what is needed to throw a yacc program
together. However for large or complicated jobs, anything based on yacc is
likely to be contorted and unmanageable. I used to have a hand-crafted RFC822
(that's a mail protocol) parser and a lex/yacc-based /bin/sh clone
implementation and got so disgusted with both that they are now implemented
using S/SL. S/SL has been used to build several quite large compilers
systems (Concurrent Euclid, Turing, Turing+ and variations, are those I know
of).

If you've read this far, you deserve a cookie... my C implementation of the
S/SL compiler is now available by anonymous FTP to neat.cs.toronto.edu in
pub/ssl.tar.Z.

rayan
[From ra...@cs.toronto.edu (Rayan Zachariassen)]

Rayan Zachariassen

unread,
Sep 26, 1989, 8:44:40 PM9/26/89
to
Robert Manson <man...@riker.eng.ohio-state.edu> found a bug in the ssl.c
available for FTP. Since about 60 people have fetched it already I
thought posting it here would be most appropriate.

In ssl.c, change

int specialChar[(int)tIllegal];

to

int XspecialChar[(int)tIllegal-(int)tSyntaxError];
int *specialChar=XspecialChar-(int)tSyntaxError;

This doesn't make any operational difference on the two or three machines I've
tried it on, but it is good form to make this fix whether you think you need
it or not. If you fetched ssl.tar.Z after noon of September 16th, you don't
need it.

Also, here's a message from Jim Cordy, one of the S/SL progenitors:

Date: Sat, 16 Sep 89 10:10:12 EDT
Reply-to: co...@qucis.queensu.ca
Subject: S/SL, etc.

Rayan, to my knowledge S/SL was never a "product" - it has always
been distributed at the standard CSRI tape-cost-recovery price,
decided in the mists of time to be the cost to CSRI of putting a copy
together.

There was once a separate S/SL tape, but it is now distributed with
the PT Pascal compiler only, since it is most useful when it comes with
an example of its use. There have been a large number of these tapes
sent out over the years (like 100 or so).

There are at least 20, mostly industrial, places that are currently
using S/SL for real work. Some of them will not admit it for company
secrecy reasons, but their employees are friends and former students,
so let's just say the beer did it, and we find out.

I'm always surprised by the number of people that have made "home-brew"
S/SL's - I just got a letter from a fellow in Darmstadt last week
about one. Of course, that was the intention of the TOPLAS article -
to show you haow simple it was, and how easy to make your own (hence the
publication of the walker and the table of equivalences for the assembler).

The characterization as an "executable pseudo-code" misses the point.
A better characterization is that S/SL is a language explicitly designed
for making efficient recusive-descent parsers. Unlike most other languages,
practicially the LEAST expensive thing you can do in S/SL is recur.
This is by design, and is a side effect of having not native variables and data.

Thanks for submitting the note to comp.compilers.

Pass this stuff on if you like.

Cheers
Jim
[From Rayan Zachariassen <ra...@cs.toronto.edu>]
--
Send compilers articles to comp...@esegue.segue.boston.ma.us
{spdcc | ima | lotus}!esegue. Meta-mail to compilers-request@esegue.

0 new messages