Re: [stack] Re: Concatenative Research

Justin <[email protected]> wrote:
> "William Tanksley, Jr" <wtanksleyjr@...> wrote:
>> Justin <zallambo@...> wrote:
>> >> 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.

Yes, you're right. I don't know whether your study makes any
stack-oriented assumptions later, but it doesn't make them in its
opening sections.

It may be that there's something special about a stack when it comes
to the primary data transfer mechanism for a Turing-complete
concatenative model. I don't know, and I'd like to.

>> 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."
> 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.

Indeed, and like all elegant tools, they are from a more civilized
age. They were invented by Backus for FP and FL, the languages that
gave us the term "functional languages", although none of their
immediate successors met their definition of being functional
languages.

-Wm