Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!bloom-beacon!spdcc!ima!esegue!compilers-sender From: rayan@cs.toronto.edu (Rayan Zachariassen) Newsgroups: comp.compilers Subject: Re: S/SL (Was Re: Name that PD parser generator) Message-ID: <1989Sep27.004440.5092@esegue.segue.boston.ma.us> Date: 27 Sep 89 00:44:40 GMT References: <1989Sep6.152554.318@esegue.segue.boston.ma.us> <1989Sep11.015824.1006@esegue.segue.boston.ma.us> <1989Sep12.013014.1720@esegue.segue.boston.ma.us> <1989Sep13.145308.247@esegue.segue.boston.ma.us> <1989Sep14.142907.2085@esegue.segue.boston.ma.us> Sender: compilers-sender@esegue.segue.boston.ma.us Reply-To: Rayan ZachariassenOrganization: Compilers Central Lines: 62 Approved: compilers@esegue.segue.boston.ma.us Robert Manson 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 ] -- 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.