1. Forum
  2. Usenet
  3. COMP.LANG.POSTSCRIPT

  • Stack Management In GXScript

    From Lawrence D'Oliveiro@21:1/5 to All on Mon Dec 30 04:49:40 2024
    Programming in stack-based languages is notoriously error-prone: it is way
    too easy to lose track of where an operand on the stack came from, and
    leave too many or too few operands for an operation.

    GXScript <https://bitbucket.org/ldo17/gxscript> defines operators “</” (which I call “stackbegin”) and “/>” (which I call “stackend”). They are
    used as follows:

    «n» </

    where «n» is a non-negative integer, pops «n» operands off the top of the current operand stack (obviously it must contain at least that many), and
    puts these on a new operand stack, which becomes the current stack, while
    the previous stack becomes (temporarily) inaccessible, but saved on a
    stack of stacks, as it were.

    Correspondingly,

    «n» />

    verifies that the current operand stack contains exactly «n» items; it
    pops these off, discards the current operand stack, restores the previous
    one, and pushes those values on.

    The stack of stacks allows these </ ... /> sequences to be nested to any desired depth.

    The “;” operator is quite simple: it asserts that the current operand
    stack is currently empty, raising an error if not.

    Simple, even trivial, example:

    /try
    {
    2 </
    add
    1 />
    }
    ddef

    2 3 try = ;

    prints

    5

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Buzz McCool@21:1/5 to Lawrence D'Oliveiro on Fri Jan 3 08:53:44 2025
    On 12/29/2024 8:49 PM, Lawrence D'Oliveiro wrote:
    Programming in stack-based languages is notoriously error-prone: it is way too easy to lose track of where an operand on the stack came from, and
    leave too many or too few operands for an operation.
    gforth allows the use of "locals" in cases like this: https://gforth.org/manual/Local-Variables-Tutorial.html

    Of course many on comp.lang.forth believe if you are having trouble
    keeping track of your stack operands, you should break up your function
    (aka Forth word) into multiple smaller words. So some say that losing
    track of stack operands is a Forth language feature that tells you that
    you are not writing your Forth program correctly.

    BTW, I really applaud the work you are doing. I would use PostScript
    more than I already do if it had double precision floating point math capabilities. I've always toyed with the idea of including the math
    needed to compute an engineering equation and a graph/figure to
    illustrate it in a single unified program. I haven't pursed it on
    PostScript because of the precision issue.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to Buzz McCool on Fri Jan 3 21:23:18 2025
    On Fri, 3 Jan 2025 08:53:44 -0800, Buzz McCool wrote:

    On 12/29/2024 8:49 PM, Lawrence D'Oliveiro wrote:

    Programming in stack-based languages is notoriously error-prone: it is
    way too easy to lose track of where an operand on the stack came from,
    and leave too many or too few operands for an operation.

    gforth allows the use of "locals" in cases like this: https://gforth.org/manual/Local-Variables-Tutorial.html

    I have local variables, too. With lexical binding and full reentrancy. I
    think I posted an example of that previously; shall I do it again?

    I would use PostScript more than I already do if it had double precision floating point math capabilities.

    Since my implementation is in Python, I use Python floats, which are
    double precision.

    I've always toyed with the idea of including the math
    needed to compute an engineering equation and a graph/figure to
    illustrate it in a single unified program.

    I would recommend using Cairo graphics to do that -- it offers a more
    modern graphics API than PostScript <https://www.cairographics.org/>.

    There are several Python bindings for this. Here is mine <https://gitlab.com/ldo/qahirah>.

    For convenient presentation of information in rich-output form, might I
    suggest using Jupyter notebooks <https://jupyter.org/>.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Buzz McCool@21:1/5 to Lawrence D'Oliveiro on Mon Jan 6 08:03:44 2025
    On 1/3/2025 1:23 PM, Lawrence D'Oliveiro wrote:

    I have local variables, too. With lexical binding and full reentrancy. I think I posted an example of that previously; shall I do it again?

    Sure.

    I think you should archive your GXScript postings somewhere like on your bitbucket site. My news server doesn't keep articles very long.


    I would use PostScript more than I already do if it had double precision
    floating point math capabilities.

    Since my implementation is in Python, I use Python floats, which are
    double precision.

    Great


    I've always toyed with the idea of including the math
    needed to compute an engineering equation and a graph/figure to
    illustrate it in a single unified program.

    I would recommend using Cairo graphics to do that -- it offers a more
    modern graphics API than PostScript <https://www.cairographics.org/>.

    There are several Python bindings for this. Here is mine <https://gitlab.com/ldo/qahirah>.

    For convenient presentation of information in rich-output form, might I suggest using Jupyter notebooks <https://jupyter.org/>.

    Thank you for the information. I still think I'm looking for something
    more like PostScript with double precision math.

    Also, GXScript could use a better name (especially if you don't have the GX/graphics part working yet). MostScript? BoastScript?

    Good Luck with your endeavor!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to Buzz McCool on Mon Jan 6 20:15:44 2025
    On Mon, 6 Jan 2025 08:03:44 -0800, Buzz McCool wrote:

    On 1/3/2025 1:23 PM, Lawrence D'Oliveiro wrote:

    I have local variables, too. With lexical binding and full reentrancy.
    I think I posted an example of that previously; shall I do it again?

    Sure.

    Examples from Language.txt in the repo:

    /Count 99 ddef

    /metatry
    { # provides context for nonlocals
    dup
    /Name exch ldef
    /Count 0 ldef
    { # actual proc
    /Count dup lload 1 add lstore
    /Count dup dload 1 add dstore
    Name =
    (local Count = ) print /Count lload =
    (global Count = ) print /Count dload =
    (whichever Count = ) print Count =
    }
    }
    ddef

    /try1 metatry ddef
    /try2 metatry ddef

    try1
    try2
    try1
    try2

    produces output

    try1
    local Count = 1
    global Count = 100
    whichever Count = 1
    try2
    local Count = 1
    global Count = 101
    whichever Count = 1
    try1
    local Count = 2
    global Count = 102
    whichever Count = 2
    try2
    local Count = 2
    global Count = 103
    whichever Count = 2

    and

    /try1
    {
    /Count 31 ldef
    { # actual body
    /Count Count 1 add lstore
    (try1 Count = ) print Count =
    }
    } exec
    ddef

    /try3
    {
    /try1 exch ldef
    /Count 5 ldef
    /try2
    {
    /Count Count 1 add lstore
    (try2 Count = ) print Count =
    }
    ldef
    try1
    try2
    try1
    try2
    }
    ddef

    /try1 dload try3

    produces output

    try1 Count = 32
    try2 Count = 6
    try1 Count = 33
    try2 Count = 7

    For convenient presentation of information in rich-output form, might I
    suggest using Jupyter notebooks <https://jupyter.org/>.

    Thank you for the information. I still think I'm looking for something
    more like PostScript with double precision math.

    PostScript won’t give you the interactivity and rich output that Jupyter does.

    Also, GXScript could use a better name (especially if you don't have the GX/graphics part working yet).

    That part is called “ToastScript” <https://bitbucket.org/ldo17/gxscript_extensions/>, and while it is not
    yet what I would call complete, parts are working.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)