Re: [stack] the concatenative wikipedia article

John Nowak <[email protected]> wrote:
> William Tanksley, Jr wrote:
>> I could also imagine a language where composition is indicated by
>> an explicit operator, and simple juxtaposition indicated curried
>> application.

> Sounds like Haskell to me! The reason Haskell sucks for pointfree
> programming though is that most of the functions are curried. As such,

Interesting point... I wouldn't have expected that currying would
hurt. This just shows what little I know.

>> See the page that ieros/Kerby wrote on concatenative combinators. In
>> order to make up for this advantage, concatenative combinators have to
>> be more complex than applicative ones. In short, conc. combinators
>> have to provide a "make siblings" operation, while applicative
>> combinators don't need that because they have a sibling operation
>> implicit in their syntax.

> I'm not quite sure I understand. I'm going to guess (correct me if I'm
> wrong) that you mean concatenative functions need to preserve the
> values they don't act upon:

Sorry for the unclarity -- no. A 'sibling' operation refers to
something like 'pair'; a way to encode two data items at the same
level of nesting.

The most glaring example of where this comes into play is when I tried
to design a minimal-combinator basis for a concatenative languages.
The minimal basis for applicative languages contains one combinator;
the minimal basis for concatenative languages contains two
(http://portal.acm.org/citation.cfm?id=967781.967785 has a proof). The
reason is that applicative languages hide some program complexity in
their syntax: a combinator that takes more than one parameter makes
its parameters siblings in the parse tree.

> - John

-Wm