Monads in a Stack-Based Language
Christopher Diggins — 2007-07-11 23:51:52
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