Re: [stack] Survey: Your impressions and thoughts about concatenative languages

On 27/11/07 3:04 AM, "William Tanksley, Jr" <[email protected]> wrote:

>  
>  
This was from William Tanksley (sorry I dropped the date):
> 
> I'm stuck with "I know it when I see it," and I hate having to say that.
> 
>> > Or perhaps just elaborate a
>> > bit on what about concatenation of source text makes a language
>> > concatenative?
> 
> Well, it's not right to limit this group to only stack-based
> languages; that would rule out Enchilada, which is definitely
> concatenative but doesn't use a stack (or that's the impression I
> got...).

Indeed. There is temptation (yes, I have been guilty, too) to slip from
³concatenative² to ³stack². And another temptation (me too), to slip
from ³stack² to ³stack shuffling² (no names for parts of the stack).
Let me explain:

1: Language L is concatenative if and only if the concatenation of
programs P and Q in L computes the composition of the functions
which P and Q compute. Note: the functions must be unary,
otherwise composition makes no sense. No mention of what sort of
arguments and values these functions take.

2: One useful type for the arguments and values is the stack type,
especially for implementing the usual binary operations and relations
for numbers and other useful data types. But hey, there might be
other useful aggregate types. To fire up your imagination, think
of text editors: they have a buffer together with a pointer. This
pointer can be moved by some operations, and most other operations
(insertions, deletions,...) are relative to this pointer. Concatenative?
Well, sort of, with minor adjustments. Or imagine something like
an assembly language but without unconditional and conditional jumps.
A zero address assembly language is presumably a stack language,
but you can also have one-address, two-address and three-address
assembly languages. For these the instructions have 1,2 or 3 addresses
as their parts, but a complete instruction is not a concatenation of
parts that compute functions. Or imagine other aggregate types ...

3: Stacks are nice in that most programs only affect the top few
elements. There is no need to name them, and if they are not quite
in the right order they can be shuffled by dup, pop, and swap. And
to delve deeper into the stack you can use the dip combinator in Joy
and some others. If there are lists, then stack shuffling and list shuffling
should be treated in the same way. But do we need shufflers at all?
I used to think they are an advance because they avoid name space
pollution. Now I am not so sure. Maybe this sort of pollution is
a price worth paying for increased readability. In my experiments
with a Joy written in Prolog I used definitions in this form:

PROGRAM P  turns STACK S1 into STACK S2  :- ...

The turnstyle :- should be read as IF. Stacks are written as Prolog lists,
top few first, then the unspecified rest R. Here is an example:

hypothenuse turns [M N | R] into [H | R] :- H is sqrt(M * M + N * N).
       
Compare that with Joy:

hypothenuse == [dup *] dip dup * +  sqrt

Maybe the example does not convince. Use the annoying quadratic
formula instead.

So: ³concatenative² does not imply ³stack², and ³stack² does not
imply ³anonymity (of parts)². Keep an open mind about possibilities.

  - Manfred


[Non-text portions of this message have been removed]