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.