Re: [stack] a constructive-concatenative language

On Dec 11, 2008, at 1:48 PM, William Tanksley, Jr wrote:

> In the meantime, I fwd'ed this to a friend who's got more time, and
> this is what he said:

Very good. Thanks for passing it on.

>> This is a near-complete re-invention of Backus' FL language,  
>> including
>> syntax.  The only things I can spot which are readily different are
>> the selection syntax and that you no longer need to use 'o' to
>> indicate composition.

This is essentially true. One more important thing that is different  
(that I think your friend realized but didn't mention here) is that  
you cannot write the equivalent of FP's 'hd' or 'tl' functions because  
they both operate on lists of arbitrary length. Here, selection only  
works on tuples of a specific length. The idea was that this would  
prevent some subtle errors and make reading easier, but it seems to be  
something of a burden in my early experiments.

>> The point is, however, that Nowak's language and FP/FL are extremely
>> similar.  I'm not sure to what extent that FP/FL have influenced his
>> thinking, but if it's an independent design, that speaks volumes for
>> Backus' ideas.

It is not entirely independent. I was familiar with FP, although only  
in a cursory way. What really happened was that I enjoyed the clarity  
in which functions could written using the cleave and spread  
combinators in Factor. I ended up working backwards and arriving at  
something very much like FP. After realizing this, I lifted most of  
FP's syntax.

>> I'm not a fan of him using infix mathematics in his language, only
>> because it's nearly impossible to statically disambiguate postfix and
>> infix forms of operators.

I'm not a big fan of this either. The problem is that the verbosity is  
a little irritating if something like it isn't offered. FL offered a  
general infix syntax (the same as J's "fork", roughly '(f g h):x ==  
g:<f:x, h:x>') and 15 level of precedence, perhaps for this reason.  
I'm sure there are other syntactic approaches worth considering  
though. Switching to a right-to-left evaluation order seems to help.

>> However, I'll need to re-evaluate my "toy" language idea to see how
>> making all functions operate on tuples of arguments changes it.

I'd be curious to hear the results of this experiment.

One problem I've already run into with the language I proposed is that  
first class functions are hopelessly painful to work with. The simple  
example I had wanted to do was transform a binary operator (like '+')  
to one that works on 3 values and yields 2:

    foo(F) = [[3@1, 3@2] F, 3@3] F

However, if I try to write a version of 'foo' that takes some function  
'F' as part of a tuple rather than as a constant, it becomes very  
painful. Looking at Backus's FL, it appears the problem is partially  
solved using "prime notation", but it's hardly elegant. Backus's  
Formal FP seems to take an approach similar to what I wrote above,  
although I'm not sure about that. In contrast, the concatenative code  
is trivial: '[dip] keep i'. It's not clear to what extent the problems  
I've run into are merely syntactic, but I suspect the syntax is not  
the fundamental issue.

The other problem I quickly ran into is that rearranging values in  
nested tuples is very awkward. Some kind of shuffling form would be  
necessary to make this work. The addition of such a form may also do  
much to solve the issue with first class functions being too awkward  
to manipulate into a place where they can be properly applied.

- John