Not exactly, but true insofar as SVG and PDF files are basically PostScript programs with the code and logic stripped out, and effective drawing commands left in (or "distilled out"), which is that they merely represent the graphical output, without the Turing complete programming language underneath. With all the loops unrolled and mathematical expressions, logic, and conditions evaluated.
Capturing the graphical output of a program (just drawing commands, or calls to any api surface like turtle graphics, or stencil/paint porter/duff renderinging API, i.e. PostScript => PDF, SVG, or HTML canvas 2d rendering context) is called "partial evaluation".
In computing, partial evaluation is a technique for several different types of program optimization by specialization. The most straightforward application is to produce new programs that run faster than the originals while being guaranteed to behave in the same way.
Meta-circular evaluators are useful for partially evaluating programs, and fortunately they are easy to write in homoiconic languages like PostScript and Logo:
In computing, a meta-circular evaluator (MCE) or meta-circular interpreter (MCI) is an interpreter which defines each feature of the interpreted language using a similar facility of the interpreter's host language. For example, interpreting a lambda application may be implemented using function application.[1] Meta-circular evaluation is most prominent in the context of Lisp.[1][2] A self-interpreter is a meta-circular interpreter where the interpreted language is nearly identical to the host language; the two terms are often used synonymously.[3]
In computer programming, homoiconicity (from the Greek words homo- meaning "the same" and icon meaning "representation") is an informal property of some programming languages. A language is homoiconic if a program written in it can be manipulated as data using the language.[1] The program's internal representation can thus be inferred just by reading the program itself. This property is often summarized by saying that the language treats code as data. The informality of the property arises from the fact that, strictly, this applies to almost all programming languages. No consensus exists on a precise definition of the property.[2][3]
The Shape of PSIBER Space: PostScript Interactive Bug Eradication Routines — October 1989:
For example, partially evaluating ("distilling") this compact high level recursive data driven fractal PostScript pot leaf drawing program would expand it from one page of concise PS to many pages of repetivive low level PDF drawing commands.
DonHopkins on March 2, 2020 | parent | context | favorite | on: Sun's NeWS was a mistake, as are all toolkit-in-se...
I wrote a metacircular evaluator, ps.ps, but I only used it in PSIBER for debugging (single stepping through code, which the normal PostScript interpreter didn't support directly, and also drawing visualizations of code execution). So the fact that it was slow wasn't really an issue, since it wasn't used in any speed critical situation.
Nether GoodNeWS aka HyperNeWS aka HyperLook nor TNT (The NeWS Toolkit) used a metacircular evaluator themselves.
HyperLook could copy the image of windows to the clipboard as a PostScript drawing, but didn't need to use "PostScript capture" for that [below], because it represented drawings in its own format as a display list of PostScript data, that PostScript code interpreted to draw, and when you printed an image, it would just send a header with the drawing interpreter to the printer, followed by the drawing data and a call to the interpreter.
Maybe it was the speed of the structured drawing interpreter that people were complaining about. There is some overhead of course, but it's washed out by the fact that actually performing the drawing itself takes much more time than interpreting the data.
Or maybe you're thinking of "PostScript capture", which is effectively "partial evaluation" of arbitrary PostScript code, with respect to the imaging model (making paths, filling and stroking them, and rendering text)? You can efficiently implement PostScript capture without resorting to a metacircular evaluator, simply be redefining a few key operators like "fill", "stroke", "show", etc.
PostScript capture is the technique of executing some arbitrary PostScript code that produces a drawing (which could be a traditional document in a PostScript file meant for the printer, or even a window system object like a menu), and capturing the drawing commands as another PostScript program, without any computation, conditionals, and loops. It would capture the effects of the drawing commands as another simple, flat PostScript program with all the conditionals and loops unwound (so a small recursive drawing procedure would produce an enormous flat drawing file, but most normal documents would be optimized to be smaller and even print faster), in the same global coordinate system, with unnecessary graphics state changes removed.
That's the essence of Adobe Acrobat's "Distiller", or Glenn Reid's "PostScript Distillery". I wrote distill.ps "in the spirit of Glenn Reid's Distillery" for PSIBER, and the NeWS Toolkit had its own /capture method built in, but they weren't actually used for much besides making a few illustrations.
The data structure displays (including those of the Pseudo Scientific Visualizer, described below) can be printed on a PostScript printer by capturing the drawing commands in a file.
Glenn Reid’s “Distillery” program is a PostScript optimizer, that executes a page description, and (in most cases) produces another smaller, more efficient PostScript program, that prints the same image. [Reid, The Distillery] The trick is to redefine the path consuming operators, like fill, stroke, and show, so they write out the path in device space, and incremental changes to the graphics state. Even though the program that computes the display may be quite complicated, the distilled graphical output is very simple and low level, with all the loops unrolled.
The NeWS distillery uses the same basic technique as Glenn Reid’s Distillery, but it is much simpler, does not optimize as much, and is not as complete.
Here's more about the metacircular interpreter and distilled PostScript:
>If you wanted to produce "safe" PostScript file for printing, that used a standard header file and didn't require a Turing complete printer with loops, conditionals, functions, etc, you could write a partial evaluator for PostScript that projects it against the stencil-paint imaging model, optimizes the graphics, and prints out another "safe" PostScript program using a standard header, with all the loops unrolled and conditionals evaluated and functions called and graphics in the same coordinate system. That would enable you to capture anything you draw on the screen, independent of the PostScript algorithmic procedures and classes and libraries and application required to draw it.
Glenn Reid, who also wrote books on PostScript like Thinking in PostScript, pioneered that idea in his "PostScript Language Distillery", which is the idea that grew into PDF.
Comments
Not exactly, but true insofar as SVG and PDF files are basically PostScript programs with the code and logic stripped out, and effective drawing commands left in (or "distilled out"), which is that they merely represent the graphical output, without the Turing complete programming language underneath. With all the loops unrolled and mathematical expressions, logic, and conditions evaluated.
Capturing the graphical output of a program (just drawing commands, or calls to any api surface like turtle graphics, or stencil/paint porter/duff renderinging API, i.e. PostScript => PDF, SVG, or HTML canvas 2d rendering context) is called "partial evaluation".
https://en.wikipedia.org/wiki/Partial_evaluation
Meta-circular evaluators are useful for partially evaluating programs, and fortunately they are easy to write in homoiconic languages like PostScript and Logo:
https://en.wikipedia.org/wiki/Meta-circular_evaluator
https://en.wikipedia.org/wiki/Homoiconicity
The Shape of PSIBER Space: PostScript Interactive Bug Eradication Routines — October 1989:
Printing Distilled PostScript:
https://donhopkins.medium.com/the-shape-of-psiber-space-octo...
The Metacircular Postscript Interpreter:
https://donhopkins.medium.com/the-shape-of-psiber-space-octo...
For example, partially evaluating ("distilling") this compact high level recursive data driven fractal PostScript pot leaf drawing program would expand it from one page of concise PS to many pages of repetivive low level PDF drawing commands.
https://donhopkins.com/home/archive/news-tape/pictures/leaf....
https://news.ycombinator.com/item?id=22461545
DonHopkins on March 2, 2020 | parent | context | favorite | on: Sun's NeWS was a mistake, as are all toolkit-in-se...
I wrote a metacircular evaluator, ps.ps, but I only used it in PSIBER for debugging (single stepping through code, which the normal PostScript interpreter didn't support directly, and also drawing visualizations of code execution). So the fact that it was slow wasn't really an issue, since it wasn't used in any speed critical situation.
https://www.donhopkins.com/home/code/ps.ps.txt
Nether GoodNeWS aka HyperNeWS aka HyperLook nor TNT (The NeWS Toolkit) used a metacircular evaluator themselves.
HyperLook could copy the image of windows to the clipboard as a PostScript drawing, but didn't need to use "PostScript capture" for that [below], because it represented drawings in its own format as a display list of PostScript data, that PostScript code interpreted to draw, and when you printed an image, it would just send a header with the drawing interpreter to the printer, followed by the drawing data and a call to the interpreter.
Maybe it was the speed of the structured drawing interpreter that people were complaining about. There is some overhead of course, but it's washed out by the fact that actually performing the drawing itself takes much more time than interpreting the data.
Or maybe you're thinking of "PostScript capture", which is effectively "partial evaluation" of arbitrary PostScript code, with respect to the imaging model (making paths, filling and stroking them, and rendering text)? You can efficiently implement PostScript capture without resorting to a metacircular evaluator, simply be redefining a few key operators like "fill", "stroke", "show", etc.
https://en.wikipedia.org/wiki/Partial_evaluation
PostScript capture is the technique of executing some arbitrary PostScript code that produces a drawing (which could be a traditional document in a PostScript file meant for the printer, or even a window system object like a menu), and capturing the drawing commands as another PostScript program, without any computation, conditionals, and loops. It would capture the effects of the drawing commands as another simple, flat PostScript program with all the conditionals and loops unwound (so a small recursive drawing procedure would produce an enormous flat drawing file, but most normal documents would be optimized to be smaller and even print faster), in the same global coordinate system, with unnecessary graphics state changes removed.
That's the essence of Adobe Acrobat's "Distiller", or Glenn Reid's "PostScript Distillery". I wrote distill.ps "in the spirit of Glenn Reid's Distillery" for PSIBER, and the NeWS Toolkit had its own /capture method built in, but they weren't actually used for much besides making a few illustrations.
https://medium.com/@donhopkins/the-shape-of-psiber-space-oct...
Here's more about the metacircular interpreter and distilled PostScript:
https://news.ycombinator.com/item?id=13705664
http://www.donhopkins.com/home/psiber/cyber/ps.ps.txt
>If you wanted to produce "safe" PostScript file for printing, that used a standard header file and didn't require a Turing complete printer with loops, conditionals, functions, etc, you could write a partial evaluator for PostScript that projects it against the stencil-paint imaging model, optimizes the graphics, and prints out another "safe" PostScript program using a standard header, with all the loops unrolled and conditionals evaluated and functions called and graphics in the same coordinate system. That would enable you to capture anything you draw on the screen, independent of the PostScript algorithmic procedures and classes and libraries and application required to draw it.http://www.donhopkins.com/home/psiber/cyber/distill.ps.txt
http://donhopkins.com/home/archive/postscript/newerstill.ps....
Glenn tells me that the PostScript distillery was actually John Warnock's idea!