|S/SL (Was Re: Name that PD parser generator) email@example.com (1989-09-14)|
|Re: S/SL (Was Re: Name that PD parser generator) firstname.lastname@example.org (Rayan Zachariassen) (1989-09-25)|
|References:||<1989Sep6.email@example.com> <1989Sep11.firstname.lastname@example.org> <1989Sep12.email@example.com> <1989Sep13.firstname.lastname@example.org> <1989Sep14.email@example.com>|
|Date:||Mon, 25 Sep 89 16:01:46 EDT|
|From:||Rayan Zachariassen <firstname.lastname@example.org>|
Robert Manson <email@example.com> 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
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
Also, here's a message from Jim Cordy, one of the S/SL progenitors:
Date: Sat, 16 Sep 89 10:10:12 EDT
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
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.
[From Rayan Zachariassen <firstname.lastname@example.org>]
Return to the
Search the comp.compilers archives again.