Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!intercon!news From: amanda@mermaid.intercon.com (Amanda Walker) Newsgroups: comp.lang.postscript Subject: Defining procedures with named parameters Message-ID: <1990Feb28.192129.9580@intercon.com> Date: 28 Feb 90 19:21:29 GMT Sender: @intercon.com Reply-To: amanda@mermaid.intercon.com (Amanda Walker) Organization: InterCon Systems Corporation, Sterling, VA Lines: 43 I've been thinking about ways to define PostScript procedures with named parameters. The syntax would be something like: /mumble [/foo /bar/zot] { ... } procdef where "foo," "bar," and "zot" would be bound to the parameters passed on the stack during the execution of the body of the procedure. It's fairly easy to make a quick-and-dirty version of this that makes a little private dictionary for this procedure in which it can define the names, but this approach has a couple problems: - it amounts to dynamic binding if you just go " begin" at the beginning and "end" before exiting, which means you can get weird side effects. - if the dictionary is allocated statically at the time that the procedure is defined, "mumble" can't call itself except tail-recursively, since the caller's copy of the arguments gets overwritten by the callee. - if the dictionary is allocated on the fly, we avoid the above problem, but each invocation of "mumble" consumes an amount of VM proportional to the number of arguments. This is OK under NeWS, where the orhpaned dictionary will get garbage-collected away, but it would be bad in a printer or other PostScript implementations with the standard Adobe memory model. Another approach would be to walk through the procedure and substitute each occurence of a parameter with code to pull it off of the stack with "index." This has the advantages of lexical binding, no recursion problems, and no net VM usage, but it does mean that "procdef" would have to know how every possible operator affects the stack so that it can track the runtime stack height as it walks through the procedure. This could be difficult... Has anyone out there implemented anything like this, or do you have any inspirations for better approaches? -- Amanda Walker InterCon Systems Corporation "Many of the truths we cling to depend greatly upon our own point of view." --Obi-Wan Kenobi in "Return of the Jedi"