rayan@cs.toronto.edu (Rayan Zachariassen) (09/14/89)
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 rayan@cs.toronto.edu (Rayan Zachariassen)]
--
Send compilers articles to compilers@ima.isc.com or, perhaps, Levine@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.rayan@cs.toronto.edu (Rayan Zachariassen) (09/27/89)
Robert Manson <manson@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: cordy@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 <rayan@cs.toronto.edu>]
--
Send compilers articles to compilers@esegue.segue.boston.ma.us
{spdcc | ima | lotus}!esegue. Meta-mail to compilers-request@esegue.
Please send responses to the author of the message, not the poster.