Re: [stack] language hierarchy

I'm going to do something that's VERY unusual for me. I'm going to
say, "let's skip the arguments and cut straight to the agreement."

We've got a LOT of misunderstandings going in this thread... But
you've come up with a refinement of the "standard" definition which is
IMO beautiful.

So, let's skip the arguments and cut straight to the agreement. THEN
we can start arguing again more efficiently.

Christopher Diggins <[email protected]> wrote:
> Here is a new suggestion for the definition of
> concatenative language:
> "A concatenative language is a programming language where the
> concatenation (i.e. the sequencing or juxtaposition) of terms
> corresponds to an associative operation on functions."

I like it. It actually reveals something to me that our original
standard definition failed to do; specifically, it explains how my
idea of "flatness" is related to the standard idea of concatenativity.
I think you've discovered something very important.

Let me paste in my phrasing of the "standard definition": "A
concatenative programming language is a language in which the
concatenation of any two valid programs is a valid program."

Your definition is superior in that it expressly requires
associativity, which (come to think of it) was part of what I was
assuming all along. Therefore, I like it and second your vote to make
it the new standard definition.

I do have a question, though. Does the old standard definition
covertly imply associativity? It does rule out application (contrary
to your earlier statement), since application doesn't work between
"any two programs". I think there's a clear implication that the
properties of concatenation should apply, but I think the old
definition is incomplete and erroneous because it does NOT clearly
state that all programs in a concatenative language can be built using
only composition.

I did, earlier in this thread, post a definition which included that
requirement: "A concatenative programming language is a language in
which the concatenation of any two valid programs is a valid program,
and the entire language can be generated by the concatenation of a
finite set of primitive programs." In other words, the language must
be closed under concatenation (which rules out application as the
meaning of concatenation) and must consist only of primitives and the
concatenation of valid programs. This requirement in turn implies that
the semantics of the language must follow the properties of
concatenation, including associativity.

I believe that this is exactly equivalent to your definition: HOWEVER,
I believe that your definition is useful when discussing semantics,
since it makes a direct semantic requirement which my definition
leaves implied.

Hmm. My definition still has a flaw: it demands a finite set of
primitives, which ignores the fact that literals (such as quotations)
may be infinite. How about this: "A concatenative programming language
is a programming language which is identical to its own Kleene
closure." I found that term on Wikipedia while trying to sort out the
idea of closure. A Kleene closure of a language is the set containing
all concatenations of all terms in the language. It's the meaning of
the Regexp symbol "*".

In other words, although Haskell isn't concatenative, Haskell* would
be (by my definition). :-) This suggests (jokingly) that C* would be
the new concatenative version of C, just as C++ is the object-oriented
version. (No, I don't want to see C++*. I suspect C*++ would be less
complex than C++ alone.)

My definition, however, is now *very* specific to syntax. Perhaps I'd
better phrase it as: "A language's syntax is concatenative if the
language it accepts is its own Kleene closure." Then, your definition
rephrased to be parallel to mine would be: "A language's semantics is
concatenative if every term denotes a function, and every
concatenation of terms denotes an associative operation on those
functions." (Hmm, is the word "semantics" plural?)

Now I *really* like your definition!!! This rephrase makes it VERY
clear to me that even my new version is inadequate -- it was PURELY
syntactic. I'm not sure whether your definition is sufficient by
itself -- but it's clearly *necessary*.

What do you think?

> Thanks for hammering out these issues William,

Hey, it's fun. Thanks for persisting.

> Christopher

-Wm