[stack] Re: Concatenative Research

--- In [email protected], "William Tanksley, Jr" <wtanksleyjr@...> wrote:
>
> Justin <zallambo@...> wrote:
> >"William Tanksley, Jr" <wtanksleyjr@> wrote:
> I didn't mean to imply that "syntactic sugar" should never be used,
> sorry. I meant that it's entirely inappropriate in the use to which I
> was replying. A concatenative language is, by definition, a language
> in which syntactic concatenation is the primary means of expressing
> composition. If there are other means (and there need not be), they
> are the syntactic sugar;concatenation is not.

I see now; you are certainly right.

> >> Possibly true. I'd love to see this explored; it does seem that the
> >> "stack" is not _necessary_ to the idea of a concatenative language.
> > Indeed, my operational semantics does not involve a stack.
> 
> There's no profound reason why it needs to; my friend wrote a very
> simple code generator that used registers for the top stack items.
> However, using something other than a stack means that the behavior of
> the language is different; your operational semantics would be
> different.

All I mean to say is that my operational semantics is general enough that it's completely ambivalent as to what kind of states a language's programs act on. There is no mention of stacks -- only states, which could be anything.

http://dl.dropbox.com/u/17328602/concat/theory/concat.pdf

> >> I know what you mean. Forth, Joy, and Factor are all capable of being
> >> written without clutter; but it's widely admitted that it's easier to
> >> do in Factor than it is in Forth.
> > Why would you say that is? I know it allows both stack manipulation and variables; is this a potent combination, or is something else at work?
> 
> Something else. (Forth also has both.)
> 
> Factor also has the cleave/spread combinators. From
> http://factor-language.blogspot.com/2008/03/inheritance-tuple-reshaping-cleavers.html:
> 
> "These combinators help structure your data flow by grouping parts of
> computations into one-to-many, many-to-many and many-to-one designs."
> ... "For example, I recently converted our serialization library to
> use these combinators. The result is extremely straightforward: there
> is almost no stack manipulation, except for the occasional dup and
> drop, but it doesn't use named locals either. Thanks to the cleave
> combinators, all values just happen to be in the right place at the
> right time, and everything composes together very nicely, like lego
> bricks."

I remember seeing references to 'cleave' and 'spread' but never knew what they were. They seem to be elegant tools; thanks for pointing them out.