Lisp dialect as front end to PostScript
john peterson
ago. This translates many common lisp functions to postscript as well
as manage the environment and many lispisms (&optional and &rest
arguments, multiple values, macros, ...). I'm not working on this
thing anymore but it's available for anyone that wants it. It's
available via anonymous ftp in pub/plisp/plisp.tar.Z on
nebula.cs.yale.edu (128.36.13.1).
John Peterson
peters...@cs.yale.edu
Yale Haskell Project
David Yost
I.e. a lisp dialect that translates more or less directly
to PostScript.
Has anyone done such a thing?
--dave yost
Barry Margolin
Hmm, if you had a complete Lisp-to-Postscript translator written in Lisp,
and fed the translator to itself, you could then download the result to a
printer and then just send it Lisp code!
The nice thing is that Lisp and PS have many features in common, so the
mapping can be pretty straightforward. Specifically, they both have
manifest typing and dynamic allocation with garbage collection. The latter
is often the hardest part of any Lisp implementation, but the implementor
of this translator wouldn't have to worry about it.
--
Barry Margolin
System Manager, Thinking Machines Corp.
bar...@think.com {uunet,harvard}!think!barmar
Mark Kantrowitz
writes:
See "PLisp, A Lisp to Postscript Compiler", by John C. Peterson, University of
Arizona, TR 86-29, December 1986.
--mark
Scott Byer
How many would use such a thing?
That is, given the choice and identical functionality, who
would prefer to program in Lisp?
Scott Byer NeXTMail: by...@adobe.com
Adobe Systems Incorporated These are *my* opinions, and
1585 Charleston Road, P.O. Box 7900 do not necessarily reflect
Mountain View, CA 94039-7900 the opinions of my employer.
---------------------------------------------------------------------
Gerald Q. Maguire
several code analyzers and find the dependency chains and thus compute
each of the chains concurrently. Some analysis which I did 1988
indicates that these chains are typically short and there are a lot
per page (for typical output generated by formatters such as SCRIBE)
thus there is a lot of potential for parallelism. A side benefit is
that you know which characters in which font and what size to cache
for subsequent rendering of a page - which is great if you are going
to reprint this page later; ideally it allows you to keep multiple
representations of a page and emit previous versions very quickly for
a given device.
Chip
Dick Dunn
...
>The nice thing is that Lisp and PS have many features in common, so the
>mapping can be pretty straightforward. Specifically, they both have
^^^^^^^^should be "latent"; just a thinko, I assume.
>...and dynamic allocation with garbage collection. The latter
>is often the hardest part of any Lisp implementation, but the implementor
>of this translator wouldn't have to worry about it.
Level 1 PostScript interpreters didn't have garbage collection...that's why
the save/restore ritual mattered so much. There's nothing to say that
they *couldn't* have had garbage collection, but just that none of them
[as far as I know] *did* have it.
Even in Level 2, it's not clear that the garbage collectors will be capable
of compaction. This might make a difference in LISP-like memory usage.
--
Dick Dunn r...@raven.eklektix.com -or- raven!rcd Boulder, Colorado
...Simpler is better.
Peter da Silva
> That is, given the choice and identical functionality, who
> would prefer to program in Lisp?
Given a choice and identical functionality, I would prefer to program
in Forth. Postscript is pretty close, but there's some design problems
that I'd rather not have to workaround all the time (little things like
the ordering of the arguments to DEF, the artificial distinction between
DEF and SET, and so on).
--
/F{findfont exch scalefont setfont}def /S{moveto show}def /T{/Times-Roman F}def
8 T(Ferranti International Controls Corporation)24 28 S(+1 713 274 5180)24 12 S
(Sugar Land, TX 77487-5012)24 20 S 12 /Courier F(`-_-')320 32 S( 'U` )320 16 S
12 T(Peter da Silva)24 36 S 16 T(Have you hugged your wolf today?)358 24 S
Simon Ward
I am interested to know more about this debate.
Simon Ward
Faculty of Environmental Design
University of Canberra
Mark Tillotson
> the save/restore ritual mattered so much. There's nothing to say that
> they *couldn't* have had garbage collection, but just that none of them
> [as far as I know] *did* have it.
>
> Even in Level 2, it's not clear that the garbage collectors will be capable
> of compaction. This might make a difference in LISP-like memory usage.
> --
> Dick Dunn r...@raven.eklektix.com -or- raven!rcd Boulder, Colorado
> ...Simpler is better.
see raw addresses, there is absolutely no problem in using compaction
in a garbage collector at all. I have read the spec. with exactly
this in mind. (You may have to rehash dictionaries I suppose, but
thats not a tragedy).
The one tricky point is where several composite objects (like arrays
and strings) overlap the same piece of VM, in which case the whole lot
has to be moved together.
The design of PS2 is very careful to allow independant garbage
collection of local VM spaces without having to consult global VM,
which allows truly concurrent collection as well...
I think you can also do a generation based collection as well, but
that gets a little complex (interaction with save/restore).
--
------------------------------------------------------
|\ /| | , M. Tillotson Harlequin Ltd. \
| \/ | /\| |/\ |< ma...@uk.co.harlqn Barrington Hall,\
| | \_| | | \ +44 223 872522 Barrington, \
I came, I saw, I core-dumped... Cambridge CB2 5RG \
My opinions, like my teeth, are all my own (and full of holes?)\
Dick Dunn
[I wrote]
>> Even in Level 2, it's not clear that the garbage collectors will be capable
>> of compaction. This might make a difference in LISP-like memory usage.
>Since PostScript is fully checked and type safe and does not let you
>see raw addresses, there is absolutely no problem in using compaction
Correction: There is no *theoretical* problem with using compaction.
The practical difficulties are implementation issues inside the
interpreter. How do you get a Level 2 interpreter? If you had a
Level 1 interpreter, you probably start with a massive revision to
that code. Adding garbage collection to existing code probably isn't
a major disaster--you have to be careful that none of the code (we're
talking interpreter code, not the PostScript) holds on to anything
the garbage collector doesn't know about. Everybody needs to under-
stand the rules about when GC can happen. While it's not that much
harder to deal with compaction at the outset, retrofitting it can be
hard. You may find some deeply-rooted assumptions that the address
of an object won't change after it's created. It's this practical
difficulty that might make an implementor decide not to compact even
though it's theoretically OK.