Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!rutgers!rochester!cornell!batcomputer!pyramid!decwrl!spar!singer From: singer@spar.SPAR.SLB.COM (David Singer) Newsgroups: comp.windows.news Subject: Re: LispScript Message-ID: <227@spar.SPAR.SLB.COM> Date: Tue, 1-Dec-87 12:26:56 EST Article-I.D.: spar.227 Posted: Tue Dec 1 12:26:56 1987 Date-Received: Fri, 4-Dec-87 23:37:16 EST References: <17331.8711281826@aiva.ed.ac.uk> <833@devvax.JPL.NASA.GOV> Reply-To: singer@spar.UUCP (David Singer) Organization: SPAR - Schlumberger Palo Alto Research Lines: 55 In article <833@devvax.JPL.NASA.GOV> des@jplpro.JPL.NASA.GOV (David Smyth) writes: >In article <17331.8711281826@aiva.ed.ac.uk> richard@aiva.edinburgh.ac.UK (Richard Tobin) writes: >>A recent message to this list mentioned LispScript, which appears to be >>a lisp-to-postscript translator. ... >> ... Postscript >>is such a revolting language that this sounds like a very useful program. > >I was hoping it wasn't just me! How many others HATE postscript? >I'll summarize to the net. > >Also, what would be a better language? PostScript reminds me of an >intermediate language generated by a compiler, not a language suitable >for human beings to think in. I propose a new language which is high >level, and is then compiled into postscript, with appropriate calls >to dbg for source level (NOT PostScript) debugging. > >If you can't think of a specific language (I vote for C, or something >very much like C), indicate what language capabilities should be there. > >Send today, I'll also bring this up at the Sun User's Group meeting Monday! Well, I suppose I had better describe lispscript, since I am unable to see C as an improvement on anything, even Postscript... I wrote lispscript partly as a learning exercise and partly to make writing postscript easier. It takes input in lisp notation and reader syntax, but with postscript operators in functional positions. It recognizes a set of 'special forms' which it handles specially, and also recognizes macros, whose expansion function obviously must be written in common lisp but generate lispscript (i.e. lisp-ized postscript). On the way, it does almost all your stack management for you -- the special form LET gives you compiler (lexical) names for variables on the stack, and for all built-in operators and user-defined functions defined with DEFUN lispscript does argument and result count checking. As a result, there are a few things you can't write easily in lispscript, but you can write a lot of code which is free of stack overflow/underflow problems, off-by-one indexing and other plagues of the postscript programmer. Lispscript optimizes both the input language (let variables may be re-ordered to improve stack usage), and peephole optimizes the outgoing postscript (generally optimizing the simple-minded stack manipulations generated by the translation phase). It runs in two modes: translating a file from lispscript to pure postscript, suitable for loading into news or sending to a printer; or defining a lisp function, with arguments, which has a postscript body which will be written down a stream with argument substitution when the lisp function is called (i.e. it's a CPS equivalent). Lispscript does binary encoding in this latter mode for all expect floating numbers, and including user-defined tokens. For me, the extra checking, the macro capability, and integration with my current source language make this a win over raw postscript. Ah yes, how do you get it? I'm currently trying to work out the best way to get this out, I hope it will be Real Soon Now (seriously though). Dave Singer Schlumberger Palo Alto Research.