Re: [stack] language hierarchy

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