Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.postscript > #2952 > unrolled thread

pseudoöperators?

Back to article view | Back to comp.lang.postscript

Contents

  pseudoöperators? luser droog <luser.droog@gmail.com> - 2016-11-29 15:12 -0800
    Re: pseudoöperators? Dan Coby <adcoby@earthlink.net> - 2016-12-02 16:35 -0800
      Re: pseudoöperators? luser droog <luser.droog@gmail.com> - 2016-12-02 19:53 -0800
      Re: pseudoöperators? luser droog <luser.droog@gmail.com> - 2016-12-02 20:01 -0800

#2952 — pseudoöperators?

I remember a while back discussing interpretation with
Helmar who at the time had just gotten pseudoöperators
to work, which is a procedure that acts like an operator.

And I remember not being very enthusiastic because I
didn't see the point of doing that. Procedures already
work like operators if you just call them.

But I noticed in the ghostscript docs that gs also has
this ability to make a proc quack like an oper.

Is this commonly done in ps interpreters? What is it
used/useful for?

[toc] | [next] | [standalone]

#2955

On 11/29/2016 3:12 PM, luser droog wrote:
> I remember a while back discussing interpretation with
> Helmar who at the time had just gotten pseudoöperators
> to work, which is a procedure that acts like an operator.
>
> And I remember not being very enthusiastic because I
> didn't see the point of doing that. Procedures already
> work like operators if you just call them.
>
> But I noticed in the ghostscript docs that gs also has
> this ability to make a proc quack like an oper.
>
> Is this commonly done in ps interpreters? What is it
> used/useful for?
>
Since no one else has responded, I will stick in my 2 cents.

It has been a decade since I did anything with Ghostscript but my memory 
is that the issue is how pseudooperators handle errors. If an error 
occurs within a typical PS procedure, then the contents of the stack 
could be whatever happened to be there when the error occurred. With a 
pseudooperator, the stack is restored to a known state. (I think that 
the stack was returned to its state when the pseudooperator was called.)

Dan

[toc] | [prev] | [next] | [standalone]

#2957

On Friday, December 2, 2016 at 6:36:27 PM UTC-6, Dan Coby wrote:
> On 11/29/2016 3:12 PM, luser droog wrote:
> > I remember a while back discussing interpretation with
> > Helmar who at the time had just gotten pseudoöperators
> > to work, which is a procedure that acts like an operator.
> >
> > And I remember not being very enthusiastic because I
> > didn't see the point of doing that. Procedures already
> > work like operators if you just call them.
> >
> > But I noticed in the ghostscript docs that gs also has
> > this ability to make a proc quack like an oper.
> >
> > Is this commonly done in ps interpreters? What is it
> > used/useful for?
> >
> Since no one else has responded, I will stick in my 2 cents.
> 
> It has been a decade since I did anything with Ghostscript but my memory 
> is that the issue is how pseudooperators handle errors. If an error 
> occurs within a typical PS procedure, then the contents of the stack 
> could be whatever happened to be there when the error occurred. With a 
> pseudooperator, the stack is restored to a known state. (I think that 
> the stack was returned to its state when the pseudooperator was called.)
> 
> Dan

Thanks. I hadn't thought of that. That's actually really compelling.

If we take the "pseudo-operator" I posted in another thread,

/show {
    graphicsdict /currgstate get /currfont get
    dup /FontType get 3 ne { pop //show }{
    gsave
        currentpoint translate
        newpath
        dup /FontMatrix get concat
        exch
        %pstack()=
        {
            gsave
                1 index /BuildChar get exec
            grestore
            graphicsdict /currgstate get /currfont get
            dup /xadvance get 1 index /yadvance get
            translate
            %hook
        } forall
        pop
        0 0 transform  % use device-space coordinates to save location past grestore
    grestore
    itransform moveto

    } ifelse
} def

As-is, this would be an excellent candidate for such a thing.
To users it should appear that `show` has hit an error. 

The gyrations necessary for such a procedure to manage its own
internal errors are pretty cumbersome:

/show {
    1 dict begin /ARG 1 index def { mark exch
    graphicsdict /currgstate get /currfont get
    dup /FontType get 3 ne { pop //show }{
    gsave
        currentpoint translate
        newpath
        dup /FontMatrix get concat
        exch
        %pstack()=
        {
            gsave
                1 index /BuildChar get exec
            grestore
            graphicsdict /currgstate get /currfont get
            dup /xadvance get 1 index /yadvance get
            translate
            %hook
        } forall
        pop
        0 0 transform  % use device-space coordinates to save location past grestore
    grestore
    itransform moveto

    } ifelse
} stopped {
  cleartomark ARG end /show cvx $error/errorname get signalerror
}{ cleartomark end } ifelse
} def

And this just passes-on whatever the internal error was,
which may not be meaningful for the operator.

[toc] | [prev] | [next] | [standalone]

#2958

On Friday, December 2, 2016 at 6:36:27 PM UTC-6, Dan Coby wrote:
> On 11/29/2016 3:12 PM, luser droog wrote:
> > I remember a while back discussing interpretation with
> > Helmar who at the time had just gotten pseudoöperators
> > to work, which is a procedure that acts like an operator.
> >
> > And I remember not being very enthusiastic because I
> > didn't see the point of doing that. Procedures already
> > work like operators if you just call them.
> >
> > But I noticed in the ghostscript docs that gs also has
> > this ability to make a proc quack like an oper.
> >
> > Is this commonly done in ps interpreters? What is it
> > used/useful for?
> >
> Since no one else has responded, I will stick in my 2 cents.
> 
> It has been a decade since I did anything with Ghostscript but my memory 
> is that the issue is how pseudooperators handle errors. If an error 
> occurs within a typical PS procedure, then the contents of the stack 
> could be whatever happened to be there when the error occurred. With a 
> pseudooperator, the stack is restored to a known state. (I think that 
> the stack was returned to its state when the pseudooperator was called.)
> 
> Dan

Hmm. For it to always restore the stack to known state, the does the 
procedure code need to be careful with the stack? Tracking local
changes to stack seems difficult and error prone with even simple
things like `exch` `dup` and `pop`. Maybe with a stricter format
for declaring arguments and an automatic `mark ... cleartomark` wrapper
would shore-up some of the sides to this raft.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.postscript

csiph-web