[stack] What are the advantages and disadvantages in manipulation of the return stack

[blazeski]

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]

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.

Post by blazeski
- 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
/ prepends to the queue the item found at the top of the stack.

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



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/concatenative/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/concatenative/join
(Yahoo! ID required)

<*> To change settings via email:
concatenative-***@yahoogroups.com
concatenative-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
concatenative-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Chris Double]

Post by stevan apter
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.

[blazeski]

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

[stevan apter]

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. :-)

Post by blazeski
- 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
/ prepends to the queue the item found at the top of the stack.

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



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/concatenative/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/concatenative/join
(Yahoo! ID required)

<*> To change settings via email:
concatenative-***@yahoogroups.com
concatenative-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
concatenative-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[j***@johnnowak.com]

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

Post by blazeski
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]

Post by j***@johnnowak.com
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.

Post by j***@johnnowak.com
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]

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