Argument decoupling in concatenative languages
An interesting point about so-called concatenative languages is the decoupling of arguments from procedure calls due to the stack. Here is a simple example:
: foo ( x c -- x' ) if bar else baz then ; ( Forth ) : foo ( x c -- x' ) [ bar ] [ baz ] if ; ( Factor )
The word foo selectively executes bar or baz depending on the value of the condition argument. Notice the argument x is decoupled from the application of bar or baz.
The applicative example might be:
(define (foo x c)
((if c bar baz) x)) ; Scheme
This procedure is equivalent to the Forth word, but is subtly different. The conditional expression evaluates to a procedure value (bar or baz) which is then used inside the application expression. The Forth version does not evaluate the words as values, it simply executes them directly!
What if we wanted to change the definition of baz so that it takes two arguments. Say we want to give it x twice, we could change the definition to:
: foo ( x c -- x' ) if bar else dup baz end ; ( Forth ) : foo ( x c -- x' ) [ bar ] [ dup baz ] if ; ( Factor )
Very easily done. In Scheme we would have to change the procedure to:
(define (foo x c)
(if c (bar x) (baz x x))) ; Scheme
Which now means we have to use two separate application expressions, or a more direct translation:
(define (foo x c)
((if c bar (lambda (a) (baz a a))) x)) ; Scheme
Which is quite bizarre and forces us to create a superfluous lambda. Both solutions are unpleasant and I expect most people would opt for the first version for clarity.
There are advantages and disadvantages to this decoupling. On the plus side, it allows greater factoring opportunities and conciseness. But we pay for this by having to deal with the complexity of stack management and reduced readability since it is not obvious at-a-glance what arguments feed into what words.
Is it possible to invent a syntax which combines the advantages of applicative and concatenative languages? I would really like to see what that would look like.
