Re: [stack] function/object ambiguity + quotation alternative

On Mar 4, 2009, at 5:03 PM, William Tanksley wrote:

> Why only for arrays? It would make more sense to me to make a special
> group syntax that forces the evaluation of the group at the time it's
> constructed rather than the usual runtime. So an array might look  
> like:
>
> { ,(2 1 drop) }

You're right, this is a better approach. Essentially, this would be  
the same thing as quasiquote in Scheme, and with the same syntax to  
boot. You've probably already realized this. For example, this:

    `(+ ,(+ 1 2) (+ 3 4))

reduces to this:

    (+ 3 (+ 3 4))

> I agree that this would be a great way to structure the banana
> combinator. I don't know why this would only work on Joy -- your  
> banana
> combinator doesn't ever copy the stack, or at least it doesn't  
> require a
> stack copy.

It does require a stack copy in a naive implementation because an  
identical stack is given to every function. Factor can typically avoid  
the stack copy thanks to its stack inference.

> I'd say that copying the stack is a really, really bad habit... or  
> at best, a habit that there's no good reason for and much good  
> reason against.

Copying it if it's expensive is bad; if it's cheap, it's very useful.  
In Factor, each conditional in 'cond' can alter the stack for the next  
conditional. You need to use a lot of superfluous 'dup' functions to  
avoid problems, and it removes a guarantee that you take for granted  
in most languages (provided that you're not mutating any values in  
your conditional).

Things like this are the reason I'm not using Factor; I don't find  
that sort of thing acceptable. Maybe Factor's stack inference could be  
used to implement a 'cond' without these problems, but that's beyond  
me unfortunately. Then again, I'm not a fan of smart combinators anyway.

>> Since we have lost the object/function ambiguity, we can now express
>> the semantics of our functions in terms of application. I propose the
>> syntax '<object>:<function>' to indicate an application. Assuming our
>> concatenative language is stack-based, the object will always be a
>> stack.
>
> Wait, why couldn't this be done in the past?

My thinking was that if it's clear what is an object and what is a  
function, then we can put only objects on the left and only functions  
on the right. Without a way to represent objects, you can't really  
represent application. This is not a problem in practice; Factor  
certainly has a REPL that shows a stack with objects on it. I just  
wanted to make things a bit more clear.

- John