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]

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

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