Re: [stack] Barebone implementation of concatenative language in c or c++

On 05/18/2010 01:49 PM, Ruurd wrote:
>
> I'll respond to this one.
>
> Side effects. Then usual culprits are I/O.
 > Now suppose I have a program: get 3 [+] i.
 > I can still proceed from right to left,
 > except that when I am about to execute + I
> do not find two numbers, but a function
> and a number. So 'get' must be evaluated
> before + is evaluated. This means that
> when + finds something that is a function,
 > it has to invoke the function before
 > proceeding with the addition.

But that's not all. If 'f' and 'g' both take one argument on the stack 
and I have the program 'x f y g' where x and y are values, I can only 
evaluate 'g' before 'f' if I know 'f' is pure and total. This is not 
really an interesting property of Joy at all. Any functional language 
allows arbitrary order reduction such cases (e.g. '(f x, g y)').

> Quotations. If A, B, C, D, E are valid
 > programs and B == D E, then A B C ==
 > A D E C and vice versa. That leaves the
 > question: what is a valid program. The
 > empty program is valid. A program that
 > has a matching number of [ and ] is valid.

That's actually not true. For example, '+' is not a valid program. It's 
a valid expression, but not every expression is a valid program.

> When this rule is followed it will not
 > be possible to substitute within a
 > quotation, because then I would have to
 > choose in your example: A == [, D == 1,
 > E == 2 +, C == ], B == 3; A and C are
 >  not valid programs according to the
 > definition.

I think you've misunderstood me. My point is that, for example:

    1 2 +  ==  3
    [1 2 +]  /=  [3]       (because [1 2 +] head  /=  [3] head)

This is because Joy's quotations are not opaque. In languages that offer 
abstractions (typically via lambda), you don't have this problem as it 
is safe to simplify within abstractions. Not offering abstractions and 
providing no way to implement them is an objectively bad thing. I see 
nothing good about this aspect of Joy.

> In your example: x [F] [G] bi = x F x G
 > it depends on the arity of G whether it
 >  can be executed first, doesn't it?

Yes, and that's exactly the problem. After all, determining the arity of 
G is, in general, undecidable!

> The current implementation uses a stack,
 > yes. But I was not talking about
 > implementations, I was talking about the
 > language and the way that I, as a person,
 > can evaluate expressions in whatever order
 > I like. If I can do that, mentally or on
 > paper, it is a property of Joy, the
 > language.

But that's not a reason to say Joy isn't a stack-based language. By your 
logic, neither is Forth! Indeed it is possible to compile Forth to a 
language like C without using a stack at all (given some minor 
restrictions such as that both branches of a conditional must have the 
same stack effect).

- jn