# What are the advantages and disadvantages in manipulation of the return stack

## blazeski — 2010-06-14 09:10:53

    I've created an interpreter for a stack language in c++:

    Currently it supports:

    - data types : int , float, char, void will add later double,enum

    - operations + - * / abs

    - define

    Support for scrips is approaching completion.

    However I'm little confused about what primitives should I offer beside the above. My implementations runs by using a DEQUE holding parsed but unevaluated syntax tree [ future of computation] and a "STACK" holding evaluated values [past of the computation]. I've ripped of Steven Apter XY (*) because that looked like the easiest to implement.

    Now I'm confused about what primitives should I have in the core. The ones offered by XY seems far different then classical base (swap, dup, drop, dip, cons, uncons, null, and if). Also XY offers manipulation of the return stack, or queue(**) .

    So what are the upsides and downsides of allowing programmer to manipulate the return stack?

    (*)http://www.nsl.com/k/xy/xy.htm

    (**) Though it looks like a deck to me:

    <= moves the tail of the queue to the top of the stack:

    / prepends to the queue the item found at the top of the stack.

## stevan apter — 2010-06-14 13:42:02

    the core words of XY are:

            ->      queue           [X^z Y] -> [X z]

            <-      stack           [X^z Y] -> [z Y]

            =>      cache           [X^z Y] -> [X Y^z]

            <=      uncache         [X Y^z] -> [X^z Y]

            /       use             [X^z Y] -> [X z,Y]

            \       mention         [X z^Y] -> [X^z Y]

            `       enclose         [X^z Y] -> [X^{z} Y]

                    disclose        [X^{z} Y] -> [X^z Y]

    in XY 0 i offered an alternative to => and <=:

            (       stack*          [X Y] -> [X^[X] Y]

            )       queue*          [X Y] -> [X^[Y] Y]

    the familiar base can then be defined using the XY core words.

    here's the overview i wrote up on manfred's request:

    	http://www.nsl.com/k/xy/xy.txt

    i don't know what the practical advantages and disadvantages are to

    allowing the programmer access to the return stack.  my reasons for

    designing XY as i did were mainly aesthetic.  (and for those reasons

    i strongly prefer XY 0 to the initial version of the language.)

    i think chris double (on this list) has had a go at a "serious"

    implementation of some of the ideas in XY, by which i mean that he

    actually intends to use the result in some applications.  so he's

    probably the guy whose opinions you should seek on this matter.

     On Jun 14, 2010, at 5:10 AM, blazeski wrote:

    > I've created an interpreter for a stack language in c++:

    > Currently it supports:

    > - data types : int , float, char, void will add later double,enum

    > - operations + - * / abs

    > - define

    > Support for scrips is approaching completion.

    > However I'm little confused about what primitives should I offer beside the above. My implementations runs by using a DEQUE holding parsed but unevaluated syntax tree [ future of computation] and a "STACK" holding evaluated values [past of the computation]. I've ripped of Steven Apter XY (*) because that looked like the easiest to implement.

    > Now I'm confused about what primitives should I have in the core. The ones offered by XY seems far different then classical base (swap, dup, drop, dip, cons, uncons, null, and if). Also XY offers manipulation of the return stack, or queue(**) .

    > So what are the upsides and downsides of allowing programmer to manipulate the return stack?

    >

    > (*)http://www.nsl.com/k/xy/xy.htm

    > (**) Though it looks like a deck to me:

    > <= moves the tail of the queue to the top of the stack:

    > / prepends to the queue the item found at the top of the stack.

    >

    >

    [Non-text portions of this message have been removed]

## stevan apter — 2010-06-14 13:45:41

    here's chris's page on his implementation:

    	http://old.nabble.com/XY-implementation-in-JavaScript-td22048844.html

    as i wrote to him a while ago, i'm amazed that he was able to make

    sense of it.  :-)

     On Jun 14, 2010, at 5:10 AM, blazeski wrote:

    > I've created an interpreter for a stack language in c++:

    > Currently it supports:

    > - data types : int , float, char, void will add later double,enum

    > - operations + - * / abs

    > - define

    > Support for scrips is approaching completion.

    > However I'm little confused about what primitives should I offer beside the above. My implementations runs by using a DEQUE holding parsed but unevaluated syntax tree [ future of computation] and a "STACK" holding evaluated values [past of the computation]. I've ripped of Steven Apter XY (*) because that looked like the easiest to implement.

    > Now I'm confused about what primitives should I have in the core. The ones offered by XY seems far different then classical base (swap, dup, drop, dip, cons, uncons, null, and if). Also XY offers manipulation of the return stack, or queue(**) .

    > So what are the upsides and downsides of allowing programmer to manipulate the return stack?

    >

    > (*)http://www.nsl.com/k/xy/xy.htm

    > (**) Though it looks like a deck to me:

    > <= moves the tail of the queue to the top of the stack:

    > / prepends to the queue the item found at the top of the stack.

    >

    >

    [Non-text portions of this message have been removed]

## john@johnnowak.com — 2010-06-14 14:07:54

    On Mon, 14 Jun 2010 09:10:53 -0000, "blazeski"

    <blaseski@...> wrote:

     > So what are the upsides and downsides of allowing programmer

    > to manipulate the return stack?

     I'm unaware of any benefits in a language with higher order functions. You

    do need some sort of auxiliary stack in a first order language so that you

    can shove elements aside when necessary, but dip and friends eliminate the

    need for such a low level approach. Higher order functions also eliminate

    any of the control flow benefits you can derive from a manipulatable return

    stack.

    The obvious downside is that makes a mess out of the semantics of your

    language. You can no longer view functions as mapping a stack/queue pair to

    a new stack/queue pair. Instead, you now have to deal with an additional

    exposed implementation detail. Even if you specify exactly how the return

    stack is to behave (e.g. you disallow the compiler to inline functions),

    you'll still have eliminated essentially any possibility for equational

    reasoning because any function can rip its caller off of the return stack

    (or worse, if that's even possible).

    I think that allowing access to the to-be-evaluated syntax tree (i.e. the

    "queue") is also extremely harmful as it means any program modification has

    a global effect; you can't locally verify that some other part of the

    program doesn't behave differently depending on some part of the queue that

    you'll be changing. It would seem you're already far down this path

    however.

    - jn

## stevan apter — 2010-06-14 17:06:17

    >  Even if you specify exactly how the return

    > stack is to behave (e.g. you disallow the compiler to inline functions),

    > you'll still have eliminated essentially any possibility for equational

    > reasoning because any function can rip its caller off of the return stack

    > (or worse, if that's even possible).

    >

     in my design for XY i was looking for a way to allow the

    programmer to do the maximum possible harm with the least

    amount of typing in a language with the smallest possible

    base.

     >

    > I think that allowing access to the to-be-evaluated syntax tree (i.e. the

    > "queue") is also extremely harmful as it means any program modification has

    > a global effect; you can't locally verify that some other part of the

    > program doesn't behave differently depending on some part of the queue that

    > you'll be changing. It would seem you're already far down this path

    > however.

    >

     yes, that's it exactly.

    [Non-text portions of this message have been removed]

## blazeski — 2010-06-14 17:14:19

    Thanks  for your replies, I'll continue with the classical  base.

## Chris Double — 2010-06-15 00:31:35

    On Tue, Jun 15, 2010 at 1:42 AM, stevan apter <sa@...> wrote:

     > i think chris double (on this list) has had a go at a "serious"

    > implementation of some of the ideas in XY, by which i mean that he

    > actually intends to use the result in some applications.

     As well as the JavaScript implementation of XY I did that Stevan

    linked to I also played around with a similar implemention in C++:

    http://github.com/doublec/cf

    This started off as XY and then I sidetracked into doing Stevan's F:

    http://nsl.com/k/f/f.htm

    It has support for lightweight threads and some simple examples.

    I started out wanting to experiment with something really lightweight,

    with a few primitives, and explore from there. Sadly the lure of

    complexity intervened and I added a Self like prototype object system

    and other features. This made things more complicated and ended up

    being less interesting for the original purpose I built it for so

    stopped hacking on it. One day I'll revisit it and strip it back down

    again.

    Chris.

    --

    http://www.bluishcoder.co.nz

## blazeski — 2010-06-15 07:08:09

    Thanks for the link will take a look at it later if I decide that OO support is worth the trouble. Currently I want to keep it as simple as I can. And since I don't know to code in stack languages I want to be able to reuse as much already written code as I can.

    After I finish the implementation of scripts and add some basic high level functionality(*)I will be in the process of deciding what is the best way to support the chosen platform. That's when the tough part begins I hope so that investing in interpreter really pays off .

    Slobodan

    (*) Planned for 20-06-2010