language hierarchy

[John Nowak]

Going along with the discussion trying to pin down a definition of  
concatenative and/or develop a new term, I propose this hierarchy with  
the hope that it might be partially correct and/or useful:

A functional programming language is one that treats computation as  
the evaluation of mathematical functions and avoids state and mutable  
data.
Examples: Scheme, ML, Haskell

A function-level programming language is a variable-free functional  
programming language in which all functions are unary and new  
functions are created in terms of existing functions through the use  
of functional forms.
Examples: FP, FL, APL (?), J (?)

A compositional programming language is a function-level programming  
language in which composition is the only functional form.
Examples: Joy, Cat, etc

A concatenative programming language is a compositional programming  
language in which the concatenation of functions denotes composition.
Examples: Joy, Cat, etc

- - -

Side note: Given that the term compositional programming is taken,  
what about calling them composable programming languages? You'd have  
the following definition (roughly):

"A programming language is composable if it is a variable-free, all  
functions are unary, and new functions are created only by composing  
existing functions."

In addition to it not yet having a meaning, I find the term  
"composable programming language" somewhat more playful and to-the-
point. It also highlights the composable/factorable nature of such  
programs nicely.

- John

[William Tanksley, Jr]

John Nowak <john@...> wrote:
> Going along with the discussion trying to pin down a definition of
> concatenative and/or develop a new term, I propose this hierarchy with
> the hope that it might be partially correct and/or useful:

Be careful about hierarchies that extend outside of this group's
direct interest -- if we were to develop one, we really should try to
develop it on a general-interest programming language group rather
than one limited to our narrow interests.

But I never could resist an argument over nit-picking semantics :-).

> A functional programming language is one that treats computation as
> the evaluation of mathematical functions and avoids state and mutable
> data.
> Examples: Scheme, ML, Haskell

Hey, that works. It's a direct quote of Wikipedia, so I can't argue with it.

> A function-level programming language is a variable-free functional
> programming language in which all functions are unary and new
> functions are created in terms of existing functions through the use
> of functional forms.
> Examples: FP, FL, APL (?), J (?)

I don't know about FP and FL, but APL, J, and K are binary; and I'm
not sure it's good to leave them out. How about we call this the
"combinatory programming language", and rather than talking about
"functional forms" (what are those? Google won't tell me), we refer to
"combinators"? Or is that totally not what you meant?

Another naming choice would be "dataflow language".

> A compositional programming language is a function-level programming
> language in which composition is the only functional form.
> Examples: Joy, Cat, etc

I don't know what a "functional form" is, so I can't reply.

> A concatenative programming language is a compositional programming
> language in which the concatenation of functions denotes composition.
> Examples: Joy, Cat, etc

I don't want to narrow us down enough to exclude Forth, Postscript,
and possibly Factor. Forth has never attempted to be functional.

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

> Side note: Given that the term compositional programming is taken,
> what about calling them composable programming languages? You'd have
> the following definition (roughly):

I don't mind using either word. Neither one is heavily used.

> "A programming language is composable if it is a variable-free, all
> functions are unary, and new functions are created only by composing
> existing functions."

I'd just skip the first two requirements. Why exclude a language which
includes variables?

> In addition to it not yet having a meaning, I find the term
> "composable programming language" somewhat more playful and to-the-
> point. It also highlights the composable/factorable nature of such
> programs nicely.

It does look like it's available for our use. I see one random person
on the web using it to mean "a language in which every statement
returns a value." I'd translate that to mean "a language in which
every statement is an expression," (and thus can optionally be
textually included inside another, appropriately typed, statement). I
think this definition has an advantage over your earlier one in that
it's phrased in a positive way. It also happens to be a broader
definition than "concatenative"; every concatenative language is
my-definition-composable, but Scheme is my-definition-composable but
not concatenative or combinatorial. FP is my-definition-composable and
combinatorial, but not concatenative.

Is it possible to be concatenative but not combinatory? It's
definitely NOT possible to be concatenative but not composable (both
by my definitions).

> - John

-Wm

[John Nowak]

> John Nowak <john@...> wrote:
> I don't know about FP and FL, but APL, J, and K are binary; and I'm
> not sure it's good to leave them out. How about we call this the
> "combinatory programming language", and rather than talking about
> "functional forms" (what are those? Google won't tell me), we refer to
> "combinators"? Or is that totally not what you meant?

This page might explain it a bit better:
http://en.wikipedia.org/wiki/Function-level_programming

This goes into more detail on functional forms (aka "functionals" on the
wikipedia article):
http://www.stanford.edu/class/cs242/readings/backus.pdf

As for J and K, I've seen them called function-level, but this may simply
be confusion because they're point-free. I'm not really sure.

> I don't want to narrow us down enough to exclude Forth, Postscript,
> and possibly Factor. Forth has never attempted to be functional.

Is Forth really not functional? Can you not view every function as [stack,
world] -> [stack, world]? I realize this doesn't really capture the spirit
of the language, but I think it allows Forth to still be classified as
functional (or function-based). It is possible that Forth violates this in
ways I'm not aware of; for instance, a Forth with local variables (global
is fine)
might not apply. I'd be interested in hearing arguments as to why this
view of Forth as a functional language isn't valid.

> I'd just skip the first two requirements. Why exclude a language which
> includes variables?

It is necessary to exclude them if you're writing strictly in terms of
function composition. Dealing with variables implies you're doing
value-level programming, not function-level programming. If you don't
consider concatenative languages to be function-level, then you'd not need
to exclude them. Backus's paper goes into more detail on this.

However, if you do allow variables, you lose the factorability of
languages like Joy. I'm not sure I'd want to call anything with local
bindings (module systems are okay) concatenative, because you can't create
new functions simply by concatenating; you've got scopes, name clashes,
and so on getting in the way. Modules don't violate this, because you can
still compose functions easily within a module, modules exist to avoid
name clashes, etc.

> It does look like it's available for our use. I see one random person
> on the web using it to mean "a language in which every statement
> returns a value."

He's a rogue and a drunkard anyway.

> every concatenative language is
> my-definition-composable, but Scheme is my-definition-composable but
> not concatenative or combinatorial. FP is my-definition-composable and
> combinatorial, but not concatenative.

Perhaps the quick, precise definition is:
"A language is composable if programs are written only by composing
functions."

This implies a few things that we can avoid stating outright:
- There are no variables; if there are, you're not writing only in terms
of function composition, are you!
- All functions are unary (else they'd not be composable... assuming they
all return single values anyway, which seems to be a sane assumption)
- A concatenative syntax isn't required, but it is the most obvious choice

Joy would fit in this category. FL would not, as functions can be
manipulated in ways beyond composition. Forth should fit provided local
variables are eschewed. Haskell wouldn't.

> Is it possible to be concatenative but not combinatory?

Heh, it really depends on the definition of concatenative. If you just
mean a concatentive syntax, then yes. For example, look at unary messages
in Smalltalk. You're composing messages which select functions, not
functions themselves.

> It's definitely NOT possible to be concatenative but not composable
(both by my definitions).

Again, depends on the definition. I would think the Smalltalk example
above is concatenative and not composable, assuming you're talking about a
concatenative *syntax*. If you consider concatenative languages as a
subset of compositional/composable languages as I originally proposed (and
as I would still stick with), then you're correct (by definition).

- John

[William Tanksley, Jr]

<john@...> wrote:
> > John Nowak <john@...> wrote:
> > I don't know about FP and FL, but APL, J, and K are binary; and I'm
> > not sure it's good to leave them out. How about we call this the
> > "combinatory programming language", and rather than talking about
> > "functional forms" (what are those? Google won't tell me), we refer to
> > "combinators"? Or is that totally not what you meant?

> This page might explain it a bit better:
> http://en.wikipedia.org/wiki/Function-level_programming

It does indeed! Thank you.

And now I'm enlightened. You weren't merely making up your own
hierarchy :-); you were citing well-established terms.

> As for J and K, I've seen them called function-level, but this may simply
> be confusion because they're point-free. I'm not really sure.

Wikipedia lists them as examples, and doesn't list APL. I think it's
right -- APL functions are not really manipulable.

> > I'd just skip the first two requirements. Why exclude a language which
> > includes variables?

> It is necessary to exclude them if you're writing strictly in terms of
> function composition. Dealing with variables implies you're doing
> value-level programming, not function-level programming. If you don't
> consider concatenative languages to be function-level, then you'd not need
> to exclude them. Backus's paper goes into more detail on this.

I see what you mean. I agree.

And I guess one might say that concatenative languages would then be
function-level languages such that the functional form 'unary
composition' is denoted by the syntactic relationship of
concatenation. I'm not sure that it's right to say that composition is
the ONLY functional form; others may be permitted (for example, 'map'
is a functional form). Perhaps the rule is that those functional forms
not be expressed in syntax.

> However, if you do allow variables, you lose the factorability of
> languages like Joy. I'm not sure I'd want to call anything with local
> bindings (module systems are okay) concatenative, because you can't create
> new functions simply by concatenating; you've got scopes, name clashes,
> and so on getting in the way. Modules don't violate this, because you can
> still compose functions easily within a module, modules exist to avoid
> name clashes, etc.

I agree. It's also not destructive to have local non-concatenative
syntax here and there, so long as there's some interesting subset of
the language that IS concatenative.

> > every concatenative language is
> > my-definition-composable, but Scheme is my-definition-composable but
> > not concatenative or combinatorial. FP is my-definition-composable and
> > combinatorial, but not concatenative.

> Perhaps the quick, precise definition is:
> "A language is composable if programs are written only by composing
> functions."

> This implies a few things that we can avoid stating outright:
> - There are no variables; if there are, you're not writing only in terms
> of function composition, are you!
> - All functions are unary (else they'd not be composable... assuming they
> all return single values anyway, which seems to be a sane assumption)
> - A concatenative syntax isn't required, but it is the most obvious choice

Okay, I'll agree with that.

What other syntax choices are available, aside from the trivial choice
of using a symbol to represent the composition operator? Is that the
only difference between this definition of 'composable' and
'concatenative'?

> Joy would fit in this category. FL would not, as functions can be
> manipulated in ways beyond composition. Forth should fit provided local
> variables are eschewed. Haskell wouldn't.

...yet well-defined and "interesting" subsets of all those languages
would be composable. Haskell, to the best of my knowledge, doesn't
have an interesting subset that's concatenative -- you have to use an
explicit operator to denote composition.

Correct?

> > Is it possible to be concatenative but not combinatory?
> > It's definitely NOT possible to be concatenative but not composable
> > (both by my definitions).

> Again, depends on the definition.

Hence my caveat "by my definitions".

> - John

-Wm

[John Nowak]

On Dec 4, 2007, at 7:41 PM, William Tanksley, Jr wrote:

>> This page might explain it a bit better:
>> http://en.wikipedia.org/wiki/Function-level_programming
>
> It does indeed! Thank you.
>
> And now I'm enlightened. You weren't merely making up your own
> hierarchy :-); you were citing well-established terms.

Aye. I should've been more clear.

>  I'm not sure that it's right to say that composition is
> the ONLY functional form; others may be permitted (for example, 'map'
> is a functional form).

In Joy, map isn't a functional form; it's just a normal higher order  
function that operates on the value level. The fact that ones of the  
values is a function doesn't make map any less value-level.

Composition in Joy isn't value-level; it's a function-level operation.  
(Of course, Joy also has a function named 'compose' that operates on  
values and is value-level.) FL had many of these functional forms; Joy  
has composition as the only functional form in terms of which programs  
are written. More on this later...

> It's also not destructive to have local non-concatenative
> syntax here and there, so long as there's some interesting subset of
> the language that IS concatenative.

Agreed. Like in the functional programming world where there are  
varying degrees of how functional something is -- Haskell is purely  
functional, ML is mostly functional, etc -- it would be the same here.

>> - A concatenative syntax isn't required, but it is the most obvious  
>> choice
>
> What other syntax choices are available, aside from the trivial choice
> of using a symbol to represent the composition operator? Is that the
> only difference between this definition of 'composable' and
> 'concatenative'?

It's the only thing I see as distinguishing concatenative from  
composable if you consider concatenative languages a subset of  
composable languages. As for other syntactic choices, yes, an explicit  
operator is one way. This might be useful in a language that's not  
purely composable. Graphical syntaxes also could exist. I can imagine  
only ones that are fairly useless at the moment however.

>> Joy would fit in this category. FL would not, as functions can be
>> manipulated in ways beyond composition. Forth should fit provided  
>> local
>> variables are eschewed. Haskell wouldn't.
>
> ...yet well-defined and "interesting" subsets of all those languages
> would be composable.

I don't think there's anything composable about Haskell, strictly  
speaking. The compose operator in Haskell is really just a function  
with infix syntax that operates on functions /as values/ via function  
application. This is something you can add to most any vaguely  
functional language:

        (define (compose f g) (lambda args (f (apply g args))))

To be more clear, in Joy, composition is the only functional form. In  
Haskell, /application/ is the primary functional form. In the program  
'f (g 5)', there's no apply function being called that deals with f or  
g as values. Again, you can have an 'apply' function that operates on  
the value level as in the above Scheme example, but that's something  
different. Interestingly, FL does not have a functional form for  
application as there are no arguments to be applying functions to.

As I'd not consider Haskell composable, I'd not consider it  
concatenative either.

- John

[John Nowak]

On Dec 5, 2007, at 2:04 AM, John Nowak wrote:

> I don't think there's anything composable about Haskell

Just to point out; I think this is the desirable outcome of a good  
definition for "composable". Haskell isn't any more composable than  
Joy is applicative, despite Haskell have a 'compose' function and Joy  
have an 'apply' function (called 'i').

- John

[John Nowak]

On Dec 5, 2007, at 2:11 AM, John Nowak wrote:

> Just to point out; I think this is the desirable outcome of a good
> definition for "composable". Haskell isn't any more composable than
> Joy is applicative, despite Haskell have a 'compose' function and Joy
> have an 'apply' function (called 'i').

Really not sure what I had against the present tense in this one...

- John

[William Tanksley, Jr]

John Nowak <john@...> wrote:
> William Tanksley, Jr wrote:
> > It's also not destructive to have local non-concatenative
> > syntax here and there, so long as there's some interesting subset of
> > the language that IS concatenative.

> Agreed. Like in the functional programming world where there are
> varying degrees of how functional something is -- Haskell is purely
> functional, ML is mostly functional, etc -- it would be the same here.

Hmm... Right. And much the same, there are benefits and drawbacks to
impurity... Perhaps one way of saying it is that impure programs can
tersely express some things for which pure ones need more verbosity,
while pure programs can be reasoned about using a simpler logic.
That's just experience speaking, no hard theory.

I do like your definitions now. Chris, any opinion?

> >> - A concatenative syntax isn't required, but it is the most obvious
> >> choice

> > What other syntax choices are available, aside from the trivial choice
> > of using a symbol to represent the composition operator? Is that the
> > only difference between this definition of 'composable' and
> > 'concatenative'?

> It's the only thing I see as distinguishing concatenative from
> composable if you consider concatenative languages a subset of
> composable languages.

Hmm. Okay, I think I get it. Review: composable means that function
composition is available and capable of forming interesting programs.
Concatenative means that function composition is the default operation
(performed by merely concatenating functions).

> >> Joy would fit in this category. FL would not, as functions can be
> >> manipulated in ways beyond composition. Forth should fit provided
> >> local variables are eschewed. Haskell wouldn't.

> > ...yet well-defined and "interesting" subsets of all those languages
> > would be composable.

> I don't think there's anything composable about Haskell, strictly
> speaking. The compose operator in Haskell is really just a function
> with infix syntax that operates on functions /as values/ via function
> application.

Perhaps, but the language supports that composition on such a
fundamental level that it's hard to identify it as NOT part of its
syntax. A number of different subsets of Haskell can be constructed
that form a composable language -- for example, consider a stack
monad. At least if I'm reading your definition of 'composable'
correctly.

Of course, Haskell as a whole isn't composable, or at least isn't
purely composed. It's just that it has all of the syntactic power
needed to construct purely composed programs.

> This is something you can add to most any vaguely
> functional language:
>         (define (compose f g) (lambda args (f (apply g args))))

Sure; and if you can define that as infix, your language has
superficial support for composability. If you can define it as the
default operation for concatenation, your language has superficial
support for concatenativity. Making that support more than superficial
will require being able to define the datatype on which the functions
are operating, and the basis set of functions themselves.

> As I'd not consider Haskell composable, I'd not consider it
> concatenative either.

I'd consider it composable (if I understand the word correctly) -- it
has sufficient expressive power to be warped that way -- but not
purely composable. To the best of my understanding, it's not at all
concatenative.

I think your definition is adequate, so let's go forward with it.

> - John

-Wm

[John Nowak]

On Dec 5, 2007, at 10:13 AM, William Tanksley, Jr wrote:

> Hmm. Okay, I think I get it. Review: composable means that function
> composition is available and capable of forming interesting programs.
> Concatenative means that function composition is the default operation
> (performed by merely concatenating functions).

No, not quite. Composable means composing functions is the only way to  
write programs. Joy works this way. Concatenative languages are  
composable languages with Joy-style syntax. I do not know of any  
language that is composable and not also concatenative; It's the  
obvious syntax to use. However, you can imagine such languages fairly  
easily.

>> I don't think there's anything composable about Haskell, strictly
>> speaking. The compose operator in Haskell is really just a function
>> with infix syntax that operates on functions /as values/ via function
>> application.
>
> Perhaps, but the language supports that composition on such a
> fundamental level that it's hard to identify it as NOT part of its
> syntax.

It isn't any more part of the syntax than 'apply' is part of Cat's  
syntax.

> A number of different subsets of Haskell can be constructed
> that form a composable language -- for example, consider a stack
> monad. At least if I'm reading your definition of 'composable'
> correctly.

No, I don't think you are. The compose function in haskell operates on  
values via application, not on functions directly as it does in Joy.  
Haskell is a functional language, not a function-level language like FL.

>> This is something you can add to most any vaguely
>> functional language:
>>        (define (compose f g) (lambda args (f (apply g args))))
>
> Sure; and if you can define that as infix, your language has
> superficial support for composability.

Neither infixness, nor any other syntax-related feature, has nothing  
to do with my definition of 'composable'.

>  think your definition is adequate, so let's go forward with it.

Hm. Well, I will at least!

- John

[John Nowak]

On Dec 6, 2007, at 12:31 AM, John Nowak wrote:

> Neither infixness, nor any other syntax-related feature, has nothing
> to do with my definition of 'composable'.

s/nothing/anything

Ugh. Apologies. I'm sick you see.

- John

[John Nowak]

On Dec 6, 2007, at 12:33 AM, John Nowak wrote:

> On Dec 6, 2007, at 12:31 AM, John Nowak wrote:
>
>> Neither infixness, nor any other syntax-related feature, has nothing
>> to do with my definition of 'composable'.
>
> s/nothing/anything

s/has/have

Maybe I should take a break. Sorry for the noise.

[Christopher Diggins]

On Dec 5, 2007 2:04 AM, John Nowak <john@...> wrote:
> Composition in Joy isn't value-level; it's a function-level operation.
> (Of course, Joy also has a function named 'compose' that operates on
> values and is value-level.) FL had many of these functional forms; Joy
> has composition as the only functional form in terms of which programs
> are written. More on this later...

Terminology such as "value-level" and "function-level" are outdated
and are very uncommon in modern literature on programming language
theory. You seem to be saying that composition is part of the abstract
syntax in Joy and application isn't, and that in a language like
Haskell application is part of the abstract syntax and composition
isn't. I think that would be a more effective way to communictate the
same sentiment. FWIW I agree with what you are saying, just
nit-picking how you are saying it.

....
> As I'd not consider Haskell composable, I'd not consider it
> concatenative either.

So concatenation of terms in Haskell denotes application, but it isn't
considered a concatenative language according to your definition. Try
explaining that to a random group of programmer or computer scientists
and see what their reaction is.

- Christopher Diggins

[William Tanksley, Jr]

Christopher Diggins <cdiggins@...> wrote:
> Terminology such as "value-level" and "function-level" are outdated
> and are very uncommon in modern literature on programming language
> theory. You seem to be saying that composition is part of the abstract
> syntax in Joy and application isn't, and that in a language like
> Haskell application is part of the abstract syntax and composition
> isn't. I think that would be a more effective way to communicate the
> same sentiment. FWIW I agree with what you are saying, just
> nit-picking how you are saying it.

I don't see that any terms here became outdated; they simply never
were heavily used. Few of the languages allegedly inspired by FP and
FL actually used their core ideas (especially this one).

> > As I'd not consider Haskell composable, I'd not consider it
> > concatenative either.

> So concatenation of terms in Haskell denotes application, but it isn't
> considered a concatenative language according to your definition. Try
> explaining that to a random group of programmer or computer scientists
> and see what their reaction is.

But it doesn't, I think. Concatenation of terms in Haskell perhaps
offers those terms for partial application; but the application only
happens if the first term denotes a function with a free variable.
Otherwise ... Well, I'm not sure; is it a syntax error? At any rate,
it's not application.

I don't think the path you're trying to walk will be fruitful. The
problem is that any language written in plain text MUST do something
when terms are concatenated (because that's the only thing you can DO
with plain text); trying to call a language "concatenative" merely
because it "does something" *in some cases* when terms are
concatenated is so vague it describes ALL languages.

A language that deserves the name "concatenative" should respond to
concatenation in the same way every time.

> - Christopher Diggins

-Wm

[William Tanksley, Jr]

John Nowak <john@...> wrote:
> William Tanksley, Jr wrote:

> > Hmm. Okay, I think I get it. Review: composable means that function
> > composition is available and capable of forming interesting programs.
> > Concatenative means that function composition is the default operation
> > (performed by merely concatenating functions).

> No, not quite. Composable means composing functions is the only way to
> write programs.

Okay, sorry. You might want to choose a different word form then...
the suffix "-able" means that the action is possible, not that it's
mandatory. Perhaps "compository" or "compositional"?
http://plato.stanford.edu/entries/compositionality/ (already taken,
but not in programming).

> Joy works this way. Concatenative languages are
> composable languages with Joy-style syntax. I do not know of any
> language that is composable and not also concatenative; It's the
> obvious syntax to use. However, you can imagine such languages fairly
> easily.

So "concatenative" in your definition refers ONLY to the syntax of a
composable language! Interesting. Perhaps Chris is right, and your
definition of "concatenative" could apply to non-composable languages
as well.

> >> I don't think there's anything composable about Haskell, strictly
> >> speaking. The compose operator in Haskell is really just a function
> >> with infix syntax that operates on functions /as values/ via function
> >> application.

> > Perhaps, but the language supports that composition on such a
> > fundamental level that it's hard to identify it as NOT part of its
> > syntax.

> It isn't any more part of the syntax than 'apply' is part of Cat's
> syntax.

Apply doesn't have special syntax support in Cat. The composition
operator has special syntax support in Haskell.

> > A number of different subsets of Haskell can be constructed
> > that form a composable language -- for example, consider a stack
> > monad. At least if I'm reading your definition of 'composable'
> > correctly.

> No, I don't think you are. The compose function in haskell operates on
> values via application, not on functions directly as it does in Joy.
> Haskell is a functional language, not a function-level language like FL.

When you're looking at a Haskell program which uses composition
exclusively, can you tell it's not actually "composable"? I would say
that there are subsets of Haskell which are composable, just as there
are subsets of Joy which are not (for example, function definition).

> >> This is something you can add to most any vaguely
> >> functional language:
> >>        (define (compose f g) (lambda args (f (apply g args))))

> > Sure; and if you can define that as infix, your language has
> > superficial support for composability.

> Neither infixness, nor any other syntax-related feature, has anything
> to do with my definition of 'composable'.

All features of a language are syntax-related.

> - John

-Wm

[Christopher Diggins]

> > So concatenation of terms in Haskell denotes application, but it isn't
> > considered a concatenative language according to your definition. Try
> > explaining that to a random group of programmer or computer scientists
> > and see what their reaction is.
>
> But it doesn't, I think. Concatenation of terms in Haskell perhaps
> offers those terms for partial application; but the application only
> happens if the first term denotes a function with a free variable.

That statement is simply false.

See: http://www.haskell.org/onlinereport/exps.html
"Function application is written e1 e2."

> I don't think the path you're trying to walk will be fruitful. The
> problem is that any language written in plain text MUST do something
> when terms are concatenated (because that's the only thing you can DO
> with plain text);

False. The following is not simply invalid C:

"12 13"

Notice the concatenation of terms!

> trying to call a language "concatenative" merely
> because it "does something" *in some cases* when terms are
> concatenated is so vague it describes ALL languages.

That is not true. See: C, Java, C++, Pascal, Algol, etc. etc. etc.

> A language that deserves the name "concatenative" should respond to
> concatenation in the same way every time.

Whatever response you require in your definition, be it application,
composition, or some other operation, will be arbitrary: hence
confusing.

- Christopher

[John Nowak]

On Dec 6, 2007, at 1:09 PM, William Tanksley, Jr wrote:

>> No, not quite. Composable means composing functions is the only way  
>> to
>> write programs.
>
> Okay, sorry. You might want to choose a different word form then...
> the suffix "-able" means that the action is possible, not that it's
> mandatory. Perhaps "compository" or "compositional"?
> http://plato.stanford.edu/entries/compositionality/ (already taken,
> but not in programming).

Well, perhaps you have "purely composable", "partially composable", et  
cetera. No different than "purely functional" really. Compositional is  
taken in programming, if you recall earlier discussion.

> So "concatenative" in your definition refers ONLY to the syntax of a
> composable language! Interesting. Perhaps Chris is right, and your
> definition of "concatenative" could apply to non-composable languages
> as well.

I think that's reasonable. However, I also think it makes the term  
concatenative fairly useless, which I believe is what Chris was  
saying. Fair enough; I do agree.

> Apply doesn't have special syntax support in Cat. The composition
> operator has special syntax support in Haskell.

No more special than any other infix operator (which are user-
definable in Haskell).

> When you're looking at a Haskell program which uses composition
> exclusively, can you tell it's not actually "composable"?

Perhaps dropping the requirement that composition be part of the  
abstract syntax (as Chris says) is sensible. Then, I suppose, Haskell  
would be partially composable. However, so would many other languages  
(Scheme, Python, etc).

When explaining composable languages, it's difficult to make their  
benefits clear if Haskell is composable PLUS all the other stuff we're  
used to. We (as in people on this list) already essentially know what  
we're talking about and why Joy, Forth, Cat, Factor, etc, are related.  
It's conveying the idea to other people in a way that's clear and  
attractive that warrants a new term. For that, I'd prefer a definition  
that's possibly overly precise to one that's too vague so that the  
properties (and benefits) of such languages are not in question.

- John