scsh-users
[Top] [All Lists]

FPS implementation

To: scsh@martigny.ai.mit.edu
Subject: FPS implementation
From: shivers@ai.mit.edu (Olin Shivers)
Date: 05 Nov 1996 08:31:40 -0500
Organization: Artificial Intelligence Lab, MIT
Reply-to: shivers@ai.mit.edu
   From: hbaker@netcom.com (Henry Baker)
   Newsgroups: comp.lang.scheme,comp.lang.scheme.scsh
   Date: Fri, 1 Nov 1996 20:42:54 GMT

   It's fairly trivial to _compile_ Scheme into Postscript, or at least
   a pretty good subset of Scheme.  I understand from usenet gossip last
   year that some compiler courses target Postscript as a 'machine language'.

It's easy to compile some kind of Scheme into Postscript. It would be a lot
of work to compile full R4RS, with bignums, call/cc, etc. into Postscript.
Throwing in call/cc would send you straight into the Turing tarpit.

In any event, a lot of the work Wandy did in FPS was *design*, not
*implementation*. She designed FPS to admit a wide range of possible 
implementations. One possibility would be compiling the FPS program
(rather than the picture structure) to PostScript, if you feel up to it.

Note that FPS isn't PostScript. It's closely linked to PS, but it is its own
thing. It's designed to be able to use PostScript rendering engines, and one
of the things you can do is write FPS back-ends that generate PS text --
allowing you to use PS laserprinters. But you could also implement FPS by
writing the rendering primitives directly in Scheme, or by linking in
rendering primitives from the Ghostscript library as Scheme procedures.

In the case of rendering to bitmap video displays, you'd be better off using
a Scheme->native-code compiler and linked in rendering primitives, rather
than compiling to PS and executing some kind of Display PS interpreter --
eliminate the byte-code interpreter overhead. (This is all speculation, as
FPS currently runs on Scheme 48, which is a byte-code interpreter itself.)

What I find intriguing is the idea of exploring distributed programming in 
Scheme or ML together with some kind of rendering model like FPS. Then
you could partition your program so that parts that needed to be "close to
the display" (e.g., menu display code) could be sent to the display server
and execute there. The programmer could choose where to split a remote app
across the wire (unlike X, which forces a particular split).

This is what NEWS did -- you could download PS code across the net to
run on the display server. Mobile executable content -- it's no surprise
the guy that did NEWS is the guy that did Java...
        -Olin

<Prev in Thread] Current Thread [Next in Thread>