So I honestly thought I'd be talking about Erlang and various processing tactics relating to it. I was also potentially planning to do and talk about some more work on clomments, the main off-hours project I've been trying to keep at. As an absolute last resort, I was going to dive into some more Elisp, or maybe finally talk about the shell-ui project. It didn't occur to me that the week would see me dusting off an old implementation of postscript for some new code.
I haven't actually written new code for it, but I have gone over what was there and flipped through the few resources I could find. Postscript, the language, is actually more versatile than I gave it credit for the last time around. To the point that I might actually want to revisit postscript.plt as opposed to just porting what I had over to CL.
Going through the first of the resources I mention above, it actually occurred to me that I could likely accomplish some of my goals by typing .ps directly. I'm going to try that first, but still keep the embedding option in my back pocket to hedge against some issues. First impressions are that the stack is going to annoy the ever-loving fuck out of me. I remember trying out Forth a while ago and not really minding that aspect of it[1], but I honestly can't see how to write a procedure that takes more than two or three parameters without doing some serious head-scratching. If you want the argument order to be at all sensible, it seems like you need to chain exch, dup and pop like a fiend, with an index or two thrown in for good measure. That means functional programming in this language is at least slightly hobbled from the get-go, but it does force you to make the smallest possible procedure to avoid being shot in the foot inadvertently.
The other reason that implementing PostScript in another language would probably be a good idea is, ironically, performance. Not writing performance, obviously, but processing performance at the printer end. If you take a look at that third resource I link to and open it in your editor of choice, you'll notice that the author deliberately chooses one and two letter identifiers for their procedures.
Ordinarily, I'd agree that that's awful, but keep in mind that every extra character in an identifier is one more that the printer will have to parse before outputting. Shortcutting grestore to gr or lineto to li doesn't seem like much, but compounded by the number of invocations per page, pages per document copy and then by copies per hour, I could see that getting scary pretty fast where frequent output is concerned. Now, that's really not much of a reason for me to actually apply this directly; I'd much rather write with human-readable function names and have an intermediate machine compress them down to a more compact format before sitting it in front of the printer. That's basically what I see using the lisp-based generator for; if I plan it out properly, the result will be a much easier language to work in that actually has more efficient output than a hand tuned chunklet of PS.
I was going to promise to post more related content soon, but frankly, as you can see from the new addition to the language bar, you aren't likely to see me for a month or so.
Footnotes
1 - [back] - Maybe it had some syntactic help; I no longer remember, never having done any serious development in it.
No comments:
Post a Comment