# Stack Shuffling Operator Mnemonics

## Christopher Diggins — 2007-01-09 16:38:05

    I don't know if this is original or not, but I defined a large set of

    stack shuffling operations using a very simple mnemonic device.

    def aba { [dup] dip swap }

    def abac { [aba] dip }

    def cba { swap [swap] dip }

    def cbac { [cba] abac }

    etc.

    I have defined a rather list on my blog at

    http://cdiggins.com/2007/01/09/mnemonics-for-stack-shuffling-functions/

    Perhaps this is useful for other concatenative language libraries?

## William Tanksley, Jr — 2007-01-09 17:27:29

    Christopher Diggins <cdiggins@...> wrote:

     > I don't know if this is original or not, but I defined a large set of

    > stack shuffling operations using a very simple mnemonic device.

    > def aba { [dup] dip swap }

    > def abac { [aba] dip }

    > def cba { swap [swap] dip }

    > def cbac { [cba] abac }

    > etc.

     This is precisely why I advocate defining a simple shuffle syntax --

    it's just so common to want something that's easy to ask for, but hard

    to remember how someone else said it. Using my Stevan's notation with

    only shuffle (which I think is the most useful subset, although

    execution is also theoretically useful), your words would be:

     ab-aba

     abc-abac

     abc-cba

     abc-cbac

    ...and the nice thing is, you don't have to think of all the combos

    the users will ever need; they learn how to write one, and the rest

    just fall out naturally. And if they users want to use xyz instead of

    abc, no problem.

     > Perhaps this is useful for other concatenative language libraries?

     I think so.

    I admit that I would like to completely define the notation to include

    the ability to add features such as enlistment, delistment, execution,

    de-CDRing, and whatever else we can agree belongs in such notation --

    but I still hold that the basics are the most useful.

    -Billy

## stevan apter — 2007-01-09 20:28:41

    ----- Original Message -----

    From: "William Tanksley, Jr" <wtanksleyjr@...>

    To: <concatenative@yahoogroups.com>

    Sent: Tuesday, January 09, 2007 12:27 PM

    Subject: Re: [stack] Stack Shuffling Operator Mnemonics

    > Christopher Diggins <cdiggins@...> wrote:

    > > I don't know if this is original or not, but I defined a large set of

    > > stack shuffling operations using a very simple mnemonic device.

    >

    > > def aba { [dup] dip swap }

    > > def abac { [aba] dip }

    > > def cba { swap [swap] dip }

    > > def cbac { [cba] abac }

    > > etc.

    >

    > This is precisely why I advocate defining a simple shuffle syntax --

    > it's just so common to want something that's easy to ask for, but hard

    > to remember how someone else said it. Using my Stevan's notation with

    > only shuffle (which I think is the most useful subset, although

    > execution is also theoretically useful), your words would be:

    >

    >  ab-aba

    >  abc-abac

    >  abc-cba

    >  abc-cbac

    >

    > ...and the nice thing is, you don't have to think of all the combos

    > the users will ever need; they learn how to write one, and the rest

    > just fall out naturally. And if they users want to use xyz instead of

    > abc, no problem.

    and since something like -abac is syntactically illegal,

    you can just extend the syntax to have it mean abc-abac.

    waste not, want not.

    >

    > > Perhaps this is useful for other concatenative language libraries?

    >

    > I think so.

    >

    > I admit that I would like to completely define the notation to include

    > the ability to add features such as enlistment, delistment, execution,

    > de-CDRing, and whatever else we can agree belongs in such notation --

    > but I still hold that the basics are the most useful.

    >

    > -Billy

    >

## Christopher Diggins — 2007-01-09 20:40:49

    > > ab-aba

    > > abc-abac

    > > abc-cba

    > > abc-cbac

    > >

    > > ...and the nice thing is, you don't have to think of all the combos

    > > the users will ever need; they learn how to write one, and the rest

    > > just fall out naturally. And if they users want to use xyz instead of

    > > abc, no problem.

    >

    > and since something like -abac is syntactically illegal,

    > you can just extend the syntax to have it mean abc-abac.

    >

    > waste not, want not.

     The next logical step then seems to be to simply drop the "-", and use

    the library defined "abac" function that I proposed. Now you don't

    have to change the syntax of the language at all, which seems to be a

    huge plus.

    Christopher Diggins

## John Cowan — 2007-01-09 20:34:15

    stevan apter scripsit:

     > and since something like -abac is syntactically illegal,

    > you can just extend the syntax to have it mean abc-abac.

    >

    > waste not, want not.

     How do you know what is *not* a stack shuffler?

    --

    We are lost, lost.  No name, no business, no Precious, nothing.  Only empty.

    Only hungry: yes, we are hungry.  A few little fishes, nassty bony little

    fishes, for a poor creature, and they say death.  So wise they are; so just,

    so very just.  --Gollum        cowan@...  http://ccil.org/~cowan

## stevan apter — 2007-01-09 22:58:56

    ----- Original Message -----

    From: "John Cowan" <cowan@...>

    To: <concatenative@yahoogroups.com>

    Sent: Tuesday, January 09, 2007 3:34 PM

    Subject: Re: [stack] Stack Shuffling Operator Mnemonics

    > stevan apter scripsit:

    >

    > > and since something like -abac is syntactically illegal,

    > > you can just extend the syntax to have it mean abc-abac.

    > >

    > > waste not, want not.

    >

    > How do you know what is *not* a stack shuffler?

    the minimal case:  a symbol consisting of lowercase letters and

    exactly one "-".

    >

    > --

    > We are lost, lost.  No name, no business, no Precious, nothing.  Only empty.

    > Only hungry: yes, we are hungry.  A few little fishes, nassty bony little

    > fishes, for a poor creature, and they say death.  So wise they are; so just,

    > so very just.  --Gollum        cowan@...  http://ccil.org/~cowan

    >

## William Tanksley, Jr — 2007-01-09 22:36:08

    Christopher Diggins <cdiggins@...> wrote:

     > The next logical step then seems to be to simply drop the "-", and use

    > the library defined "abac" function that I proposed.

     How many of those functions do you want to type in by hand? Which ones

    are you skipping?

     > Now you don't

    > have to change the syntax of the language at all, which seems to be a

    > huge plus.

     Most consideration of languages breaks the syntax into two parts: a

    lexer and a parser. The parser is the complex part. This change

    addresses only the lexer.

    I also don't see how refusing to change a language's syntax is a "huge

    plus". I don't even see it as positive -- lack of change is a zero,

    not a positive.  If we're dealing with something that can break

    compatibility, the change itself could be negative, but that's not the

    issue here.

     > Christopher Diggins

     -Billy

## Christopher Diggins — 2007-01-10 00:12:50

    On 1/9/07, William Tanksley, Jr <wtanksleyjr@...> wrote:

     >

    > Christopher Diggins <cdiggins@...> wrote:

    > > The next logical step then seems to be to simply drop the "-", and use

    > > the library defined "abac" function that I proposed.

    >

    > How many of those functions do you want to type in by hand? Which ones

    > are you skipping?

     A few dozen, but that's the point of standard libraries, someone does

    the work once and for all and it can be reused over and over again.

     > > Now you don't

    > > have to change the syntax of the language at all, which seems to be a

    > > huge plus.

    >

    > Most consideration of languages breaks the syntax into two parts: a

    > lexer and a parser. The parser is the complex part. This change

    > addresses only the lexer.

     There is more to it than that, your proposed change would do more than

    simply add a new token to be parsed. You are effectively adding a new

    kind of expression. There would be several new grammar rules needed.

     > I also don't see how refusing to change a language's syntax is a "huge

    > plus". I don't even see it as positive -- lack of change is a zero,

    > not a positive.

     I'm just trying to say that when comparing the two design approaches

    for Cat, the simpler language design is far more favourable for my

    purposes.

    Maybe the stack shuffling is a good direction for Joy. I can

    definitely see advantages though for other language designs. As I

    mentioned before I think a language with stack shuffling semantics is

    a great idea, especially for a higher level language than Cat.

    It all boils down to what the language design goals are I think.

## William Tanksley, Jr — 2007-01-10 01:04:00

    Christopher Diggins <cdiggins@...> wrote:

     > On 1/9/07, William Tanksley, Jr <wtanksleyjr@...> wrote:

    > > Christopher Diggins <cdiggins@...> wrote:

    > > > Now you don't

    > > > have to change the syntax of the language at all, which seems to be a

    > > > huge plus.

    > > Most consideration of languages breaks the syntax into two parts: a

    > > lexer and a parser. The parser is the complex part. This change

    > > addresses only the lexer.

    > There is more to it than that, your proposed change would do more than

    > simply add a new token to be parsed. You are effectively adding a new

    > kind of expression. There would be several new grammar rules needed.

     I would indeed agree with the goal of minimizing the number of types

    of expressions in the language. I would balance that with the goal of

    simplifying the number of things that have to be known in order to do

    any work with the language.

    It's definitely a balance, but I can't imagine any language for which

    "a few dozen" additional library words (ignoring the words that some

    users will try, but which won't be defined) outweighs a single new

    expression type, when the two are a choice to do something that's done

    in most definitions...

     > > I also don't see how refusing to change a language's syntax is a "huge

    > > plus". I don't even see it as positive -- lack of change is a zero,

    > > not a positive.

    > I'm just trying to say that when comparing the two design approaches

    > for Cat, the simpler language design is far more favourable for my

    > purposes.

     Agreed. It IS very much a judgment call. I can see more complex

    languages not having the ability to use lexemes of that form --

    perhaps a language that already treats all the available separator

    characters (we were using -) syntactically.

     > Maybe the stack shuffling is a good direction for Joy. I can

    > definitely see advantages though for other language designs. As I

    > mentioned before I think a language with stack shuffling semantics is

    > a great idea, especially for a higher level language than Cat.

     Huh, I'd always thought that Cat was high level.

    -Billy

## Christopher Diggins — 2007-01-10 01:19:59

    > > Maybe the stack shuffling is a good direction for Joy. I can

    > > definitely see advantages though for other language designs. As I

    > > mentioned before I think a language with stack shuffling semantics is

    > > a great idea, especially for a higher level language than Cat.

    >

    > Huh, I'd always thought that Cat was high level.

     Cat is a wolf in sheep's clothing if you will pardon the mixed

    metaphors. Some of the type restrictions that it imposes (compared to

    the flexibility of Joy) enable a very straightforward mapping to

    assembly code. My goal for Cat is to be a safe and efficient

    high-level intermediate language, which could also be used for

    application development.

## William Tanksley, Jr — 2007-01-10 04:15:08

    Christopher Diggins <cdiggins@...> wrote:

     > Cat is a wolf in sheep's clothing if you will pardon the mixed

    > metaphors. Some of the type restrictions that it imposes (compared to

    > the flexibility of Joy) enable a very straightforward mapping to

    > assembly code.

     Yeah, static type inference can make generating code easier.

     > My goal for Cat is to be a safe and efficient

    > high-level intermediate language, which could also be used for

    > application development.

     Yes, an interesting goal.

    By the way, the first shuffle notation parser I ever actually

    completed actually generated x86 machine code directly. It was just

    too much of a pain to try to figure out the correct algorithm to

    shuffle the values using standard rot-swap-R> etc.

    And, of course, optimization of stack shuffle notations is a

    well-solved problem. It's not as simple as concatenating them, but

    it's a simple text manipulation to take two adjacent shuffles and make

    a single one.

    (End of advertisement. ;-)

    -Billy