Re: [stack] What does "concatenative" actually mean?

On Mar 5, 2009, at 6:16 PM, William Tanksley wrote:

> John Nowak wrote:
>
>> I disagree. According to the Wikipedia definition:
>>    "A concatenative programming language is one in which all terms
>>    denote functions and the juxtaposition of functions denotes
>>    function composition."
>
> I think it's a good enough definition :-). Its only problem is that,
> like the first paragraph of many Wikipedia entries, it's a little
> absolutist.

I think that, given the choice, we should be overly specific rather  
than overly general. In the former case, interesting work on the  
boundaries will still get done, and we'll have a precise definition to  
keep us focused. In the latter case, we get this same discussion every  
month.

Truth be told, the amount of good research into concatenative  
languages is nearly non-existent. We don't have much in the way of  
significant results yet. Getting the definition out of the way seems  
to me like a precondition for talking about what we're doing.

Obviously, there's nothing that says the definition could not expand  
later. Words change meaning over time. I think it is better though to  
avoid preemptively expanding definitions; instead, let's come up with  
interesting things that don't fit the definition and see if they have  
similar properties to things that do. Only this approach, applied  
consistently, is going to help us arrive at an "optimal" definition  
that describes an interesting set of languages with similar properties.

Just my opinion of course.

> ...I didn't assume that we were discussing a _functional_  
> compositional
> language -- I never really noticed we were doing that before.

We've been doing it because it is useful to do so. Once you add  
mutation or IO into the mix, the algebra of things becomes  
significantly more complicated. To apply the approach described above,  
I think we should first focus our efforts on detailing the properties  
of purely functional concatenative languages if for no other reason  
than it being simpler to do so. After we've made progress along these  
lines, dealing with an impure language will be that much easier.

>> Eh? '(f . g) . h == f . (g . h)'; seems to work to me.
>
> Yes, but does '(f . g) . h == (f .) g . h'?

Heh, yes actually. 'f . g == (f .) g'. The reason is that '.' is a  
function. If we were to write it prefix, the reason for this is more  
clear: '(.) f g == ((.) f) g'. In a language with curried functions  
like Haskell, the former is really just a more concise way of saying  
the latter. They're functionally identical.

I realize your point though, and I understand that a good notation has  
value. That said, I don't see much to indicate that using an explicit  
composition operator is a "less good" notation than using  
juxtaposition. The language I'm working on now uses explicit  
composition; this frees up juxtaposition to be used for other things  
(in my case, meta-application, aka the application of a combining form  
to a function or tuple of functions).

The current definition on Wikipedia claims that it must be  
juxtaposition denoting composition. Accordingly, my current project  
would not quality. That's fine with me as it doesn't exist yet. When I  
finish it, maybe I'll push the issue should it have the same  
properties as a concatenative language minus the minor notational  
difference.

In short, I'm going along with the "juxtaposition is composition"  
definition because we don't have any existing counter-examples. That  
said, we also have no existing concatenative languages that do not use  
a stack. Accordingly, I've been thinking lately that it may be best to  
go ahead and consider the stack (or some sort of stack/queue tuple)  
part of the definition. Slava would be happy at least.

I'll back up the claim that perhaps the stack should be part of the  
definition with the example of FP. FP and Joy are pretty similar on  
paper. You can go ahead and denote composition in FP with  
juxtaposition if you'd like. However, the simple difference between  
using always using a stack and using a list only when necessary is  
huge. The languages feel completely different from one another, and  
indeed the latter doesn't "feel" concatenative at all as we've both  
previously agreed on.

Maybe a precise definition could look like this:

1. All terms denote functions.
2. All functions are unary functions from a some aggregate (e.g. a  
stack or stack/queue tuple) to an aggregate of the same type.
3. Juxtaposition denotes the composition of functions.

My problem with this definition is #2; it's ugly. I'll pose a question  
that may lead to a way of being more precise in a separate email.

- John