# Monads in a Stack-Based Language

## Christopher Diggins — 2007-07-11 23:51:52

    I've just written a short (and hopefully accurate) tutorial on Mondas

    in pure-functional stack-based languages:

    http://cdiggins.com/2007/07/11/monads-for-a-stack-based-language/

    Any corrections or critiques would be most welcome,

    Christopher

## Chris Double — 2007-07-12 00:27:42

    > ... [1] dip [2] dip [+] dip .x swap [*] dip ...

     Why rewrite using so many invocations of dip? Couldn't you rewrite to:

      ... [ 1 2 + ] dip .x swap * ...

    Chris.

    --

    http://www.bluishcoder.co.nz

## Christopher Diggins — 2007-07-12 01:03:14

    Yes there is no real reason not to use "dip" throughout. I just thought that

    just would makes more explicit what the term rewriting strategy should be.

     On 7/11/07, Chris Double <chris.double@...> wrote:

    >

    >   > ... [1] dip [2] dip [+] dip .x swap [*] dip ...

    >

    > Why rewrite using so many invocations of dip? Couldn't you rewrite to:

    >

    > ... [ 1 2 + ] dip .x swap * ...

    >

    > Chris.

    > --

    > http://www.bluishcoder.co.nz

    >

    >

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

## Daniel Ehrenberg — 2007-07-12 01:37:18

    What does that have to do with monads? The link that you included also

    doesn't have to do with monads. I feel like I'm missing something

    here.

    Daniel Ehrenberg

     >

    > I've just written a short (and hopefully accurate) tutorial on Mondas

    >  in pure-functional stack-based languages:

    >

    >  http://cdiggins.com/2007/07/11/monads-for-a-stack-based-language/

    >

    >  Any corrections or critiques would be most welcome,

    >

    >  Christopher

## William Tanksley, Jr — 2007-07-13 14:27:11

    Christopher Diggins <cdiggins@...> wrote:

     > I've just written a short (and hopefully accurate) tutorial on Mondas

    > in pure-functional stack-based languages:

    > http://cdiggins.com/2007/07/11/monads-for-a-stack-based-language/

     The comments on your post are interesting, especially the paper

    someone pointed to <http://www.cs.nott.ac.uk/~ctm/IdiomLite.pdf>. I

    don't know how useful it'll be, but I'm glad you're studying it. It's

    well outside my usual study.

    It would be nice to have a theory that explains local variables inside

    a concatenative language, if such a thing is possible.

     > Christopher

     -Billy

## Christopher Diggins — 2007-07-13 16:48:21

    On 7/13/07, William Tanksley, Jr <wtanksleyjr@...> wrote:

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

    > > I've just written a short (and hopefully accurate) tutorial on Mondas

    > > in pure-functional stack-based languages:

    > > http://cdiggins.com/2007/07/11/monads-for-a-stack-based-language/

    >

    > The comments on your post are interesting, especially the paper

    > someone pointed to <http://www.cs.nott.ac.uk/~ctm/IdiomLite.pdf>. I

    > don't know how useful it'll be, but I'm glad you're studying it. It's

    > well outside my usual study.

     It would be good to have more eyes on the subject. I am pretty good at

    mucking things up the first time around. :-)

     > It would be nice to have a theory that explains local variables inside

    > a concatenative language, if such a thing is possible.

     I may not understand precisly what you are saying, but I thought Brent

    Kerby did a pretty good job on the subject of local variables. You can

    convert any form with named variables to one without quite easily. In

    Cat (well to be precise an extension to Cat called Big Cat) I now

    support named variables in both definitions and quotation. For

    example:

    define plusx2(x) { x x * + }

    or

    \a.\b.\c.[c b apply c a apply apply]

    These get converted into Little Cat (the core language) immediately.

    What I am looking for is an elegant mapping from a stack-based

    language with global variables to a referentially transparent

    stack-based language. I believe I have found one, but the thoery

    behind it still eludes me.

     > > Christopher

    >

    > -Billy

     Christopher

## William Tanksley, Jr — 2007-07-13 22:20:02

    Christopher Diggins <cdiggins@...> wrote:

     > William Tanksley, Jr <wtanksleyjr@...> wrote:

    > > It would be nice to have a theory that explains local variables inside

    > > a concatenative language, if such a thing is possible.

    > I may not understand precisly what you are saying, but I thought Brent

    > Kerby did a pretty good job on the subject of local variables. You can

    > convert any form with named variables to one without quite easily.

     Perhaps you're right, and his work could lead to a semantic

    understanding of local variables in a concatenative context.

     > In

    > Cat (well to be precise an extension to Cat called Big Cat) I now

    > support named variables in both definitions and quotation.

     Yeah, so do most "concatenative" languages (scare quotes, just for

    fun). Locals are conceptually a bit risky for me; I feel like they're

    foreign to the language. We're all trained in imperative applicative

    languages so locals look natural -- but most of us don't even have a

    precise model for how locals work in _applicative_ languages. (Look

    how hard the authors of SICP have to work to teach the concept.)

     > What I am looking for is an elegant mapping from a stack-based

    > language with global variables to a referentially transparent

    > stack-based language. I believe I have found one, but the theory

    > behind it still eludes me.

     That's good quarry to hunt! Once you stalk it down, you'll also help

    explain how word meanings can be dynamically redefined in the system

    dictionary.

    In typical stack-based concatenative languages, the order of execution

    is completely specified (by the monad of the stack), so "side effects"

    become perfectly predictable. Side effects only become a problem when

    you add in the ability to reorder execution. Gut feeling: I suspect

    that you can only reorder execution when you have a concept of partial

    ordering of dataflow, as we discussed in our other thread today.

    Thus, a formalization of global variables will depend on a

    formalization of reordering execution, which in turn depends on a

    formalization of partial ordering. All the problems fade away in the

    trivial degenerate case where no reordering is allowed because the

    data is totally ordered.

     > Christopher

     -Billy

## John Cowan — 2007-07-13 22:49:19

    William Tanksley, Jr scripsit:

     > > What I am looking for is an elegant mapping from a stack-based

    > > language with global variables to a referentially transparent

    > > stack-based language. I believe I have found one, but the theory

    > > behind it still eludes me.

    >

    > That's good quarry to hunt! Once you stalk it down, you'll also help

    > explain how word meanings can be dynamically redefined in the system

    > dictionary.

     Well, at least we know how to translate linear (use-once) variables

    into concatenative notation, thanks to Henry Baker:

    http://home.pipeline.com/~hbaker1/ForthStack.html

    http://home.pipeline.com/~hbaker1/ForthStack.ps.gz

    Linear lambda calculus has its own interest, and it parallelizes

    well; if you must have non-linear variables, you know where to find them.

    --

    John Cowan    cowan@...    http://ccil.org/~cowan

       There was an old man                Said with a laugh, "I

         From Peru, whose lim'ricks all      Cut them in half, the pay is

           Look'd like haiku.  He              Much better for two."

                                                 --Emmet O'Brien

## Daniel Ehrenberg — 2007-07-14 04:13:38

    On 7/13/07, William Tanksley, Jr <wtanksleyjr@...> wrote:

     >  Yeah, so do most "concatenative" languages (scare quotes, just for

    >  fun). Locals are conceptually a bit risky for me; I feel like they're

    >  foreign to the language. We're all trained in imperative applicative

    >  languages so locals look natural -- but most of us don't even have a

    >  precise model for how locals work in _applicative_ languages. (Look

    >  how hard the authors of SICP have to work to teach the concept.)

     I agree. I don't understand why stack-based languages should have

    locals. There are a few edge cases where variables might be necessary,

    and as far as I can tell, those consist of (a) math formulas and

    similarly complex things and (b) shared data that should be implicitly

    passed between functions. The former would call for some kind of math

    DSL, and the latter would best be solved by global or dynamically

    scoped named variables. Sometimes, a problem most easily be solved by

    named variables is being solved the wrong way, though that's of course

    not always the case.

    Daniel Ehrenberg