Re: [stack] the concatenative wikipedia article

John Nowak <[email protected]> wrote:
> William Tanksley, Jr wrote:
> Perhaps this is a better example:

Thanks :-).

>    a = hd
>    b = hd tl
>    c = hd tl tl
>    hypot = sqrt + [sq a, sq b]
> Or, you could do something like this:
>    sq-top = cons [sq a, tl]
>    hypot = sqrt + sq swap sq
> I don't think it would be reasonable to say this isn't concatenative
> just because the average number of contiguous compositions is somewhat
> lower than in a stack-based language. They both share the all
> properties highlighted on the wikipedia entry-in-progress.

I'm having a hard time grasping the rules, so I'm limited to asking
questions. But if a pair of definitions are valid, is their
juxtaposition also always valid? I don't see why not, so on those
grounds I think I'll say your language is concatenative. No, I don't
care to measure the average number of compositions either :-).

The interesting thing about a hybrid language like this is that we
might get a chance to compare which part of the language most people
wind up using. In this hybrid I'd say that concatenativity is favored,
since it's the default operation; I could also imagine a language
where composition is indicated by an explicit operator, and simple
juxtaposition indicated curried application.

>>> If your answer is yes, my problem with that is that we don't impose
>>> the same syntactic restrictions on the definition of an applicative
>>> language.

>> We talk about applicative languages here, but the reality is that
>> there are many different syntaxes for applicative languages, united in
>> common by one syntactic feature: the need for a tree structure.

> Applicative languages do not need a tree structure. The combinatory
> calculus is applicative and can even be written with a "concatenative"
> syntax. Look at Unlambda.

Every applicative language has a tree structure; unlambda is no
exception. The tree structure arises when a "parent" syntactic element
(a function) takes more than one "child" syntactic elements (the
parameters applied to the function). This is a hidden advantage that
applicative combinator languages have over concatenative combinators.
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 think it's proper to define and classify languages in terms of their
>> syntax
> Agreed, ideally provided another term is available for languages with
> the same semantics but a different syntax. Lacking such a term, I
> think we lack the capability to talk about an interesting family of
> languages. In any case, I have no issue with making the term
> "concatenative" have syntactic implications as the Wikipedia entry-in-
> progress indicates.

To me, the interesting thing about these languages is precisely that
the mathematical properties of their syntax and semantics match so
well.

If we called them "associative" languages perhaps I'd be mollified...
But it's already been used in computer language science.

> - John

-Wm