Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!dali.cs.montana.edu!milton!wiml From: wiml@milton.u.washington.edu (William Lewis) Newsgroups: comp.lang.postscript Subject: Re: transfer function (was Re: Help!) Message-ID: <8301@milton.u.washington.edu> Date: 29 Sep 90 01:02:36 GMT References: <20829@well.sf.ca.us> Organization: University of Washington, Seattle Lines: 35 In article jwz@lucid.com (Jamie Zawinski) writes: >In article <20829@well.sf.ca.us> shiva@well.sf.ca.us (Kenneth Porter) writes: >Hmm, how would you do that? I don't think > > { { currenttransfer exec 1 exch sub fade-factor mul 1 exch sub } > settransfer } > >will work, because currenttransfer is going to return the currently-executing >procedure, leading to infinite recursion. You could do something like > > /saved-transfer currenttransfer def > { { saved-transfer 1 exch sub fade-factor mul 1 exch sub } > settransfer } > >but that doesn't seem especially foolproof. [ /currenttransfer load /exec cvx 1 /exch cvx /sub cvx fade-factor /mul cvx 1 /exch cvx /sub cvx ] cvx settransfer ? I think that'll work .. the reason "currenttransfer" is load/exec'd rather than just cvx'd is that otherwise it would be identical to the first example up there, with infinite recursion... Or, you could do { currenttransfer 1 exch sub fade-factor mul 1 exch sub } bind settransfer in which the bind does about the same thing as building the proc as an array did up there, except it binds *all* of it, not just the /currenttransfer. -- wiml@milton.acs.washington.edu Seattle, Washington (William Lewis) | 47 41' 15" N 122 42' 58" W "These 2 cents will cost the net thousands upon thousands of dollars to send everywhere. Are you sure you want to do this?"