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

John Nowak wrote:
> William Tanksley wrote:
> > 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 simply not perform the stack copy -- if the programmer wants to
preserve the stack, they can do that by writing programs that have the
inputs and outputs that the combinator documents as required. That's a
good habit. In fact, NOT doing it is such a disastrously bad habit that
I don't understand why we're desiring to protect programmers from the
consequences thereof.

It's a very, very easy thing to ask for, and extremely easy to inference
(if you want to do that). What do we gain by not asking for it?

> > 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.

I concede that copying the stack is not "a bad habit". I overspoke. I
disagree that it's useful, except for allowing programmers to write code
that is bad in other ways (essentially, for producing side effects that
the compiler promises to throw away).

> 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).

If you want that guarantee, you can use 'case' instead of 'cond'. If
you're using 'cond' you're going to either use 'dup' (although I'd argue
that there's nothing superfluous, and certainly not "a lot") or you're
working your way through the stack for some other reason.

> 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.

This is precisely why I don't like stack copying combinators: they claim
to be smart about removing "accidental" side effects. How does it know
which effects are accidental? Read the documentation. Well, strangely
enough, that's exactly what I'd have to do in order to write code
WITHOUT accidental side effects.

> >> 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.

I do like the notation you propose. I hope we see it regularly. The
current equivalent is quoted single letter, which is good enough if you
assume/require closed quotations.

> - John

-Wm