# RE: [stack] Re: [+] first: final(?) thoughts

## Tanksley, William D. Jr. — 2003-07-30 22:25:53

    From: Ivan Tomac [mailto:e1_t@...]

     >What if we get rid of first? So that you can't get the first element

    >of a list. Or any element of a list. In fact what if we literally

    >treat all lists as functions so the only operation we can perform on

    >them is execution, nevermind implementation details, complexity, etc.

     This is indeed equivalent to getting rid of ` (or, using Apter's syntax,

    which I will from now on, \). The tricky thing to see is that you're doing

    this by getting rid entirely of the idea of quotation; you're replacing it

    with a delayed (lazy) enlistment.

     >This requires some changes in the design of a language. For example

    >a function thats about to get executed takes all the parameters from

    >the main stack, removes them and puts them onto it's own local stack

    >(in a way this is like having stack frames but it's still a bit

    >different and it's all transparent to the programmer). When the

    >function finishes execution it's output remains on that local stack.

     There's something you're missing here. How does the language know how many

    parameters to remove from the main stack? Does every function have to

    declare how many parameters it'll take? What if it takes a variable amount

    of parameters?

     >There would be a small number of functions designed specifically to

    >manipulate that local stack and transfer the values to the main

    >stack so basically local stacks would replace lists

     Doesn't this have all the same problems as list manipulation? Or is it

    impossible to return a function, in which case your language isn't capable

    of the same things Joy is?

     >Now I'm not completely sure how automatic merging of local stacks

    >with the main stack should work.

     Problems like this are hard, because no matter how clever you get there's

    some programmer who'll reasonably expect it to behave differently. The more

    clever you get, the more expectations you meet -- and the harder it'll be to

    know when an expectation isn't being met.

    Joy has some problems like this; it's hard to know what it'll do with

    functions that access the stack below what combinators expect, for example.

    Manfred's chosen to let those functions see and alter the elements below,

    but then he restores them, leaving only the top element on the new

    function's stack -- but then he has to write special combinators for

    functions that return more.

     >I remember starting a big discussion about laziness in concatenative

    >languages when I first joined the board and I've been convinced that

    >laziness doesn't make sense in a language like Joy (basically

    >execution in concatenative languages is sequential so delaying

    >execution is pointless while in applicative languages execution is

    >more like a tree so delaying execution of some of the branches of

    >the tree makes sense).

     Yup. But it DOES make sense to have an agressively evaluated concatenative

    language -- essentially, one where any function with all its inputs known

    gets evaluated immediately, and the result substituted in the compilation.

    Speculation: aggressive concatenative is roughly equivalent to lazy

    applicative.

     >However with the changes I'm proposing it might make sense to make a

    >lazy language although the final language might not be concatenative.

     I suspect it would be. But I'm not sure it would be as powerful as you'd

    want.

    -Billy

## Ivan Tomac — 2003-07-30 23:46:41

    --- In concatenative@yahoogroups.com, "Tanksley, William D. Jr."

    <william.d.tanksley.jr@s...> wrote:

     > From: Ivan Tomac [mailto:e1_t@y...]

    >

    > >What if we get rid of first? So that you can't get the first

     element

     > >of a list. Or any element of a list. In fact what if we literally

    > >treat all lists as functions so the only operation we can perform

     on

     > >them is execution, nevermind implementation details, complexity,

     etc.

     >

    > This is indeed equivalent to getting rid of ` (or, using Apter's

     syntax,

     > which I will from now on, \). The tricky thing to see is that

     you're doing

     > this by getting rid entirely of the idea of quotation; you're

     replacing it

     > with a delayed (lazy) enlistment.

    >

     Right.

     > >This requires some changes in the design of a language. For

     example

     > >a function thats about to get executed takes all the parameters

     from

     > >the main stack, removes them and puts them onto it's own local

     stack

     > >(in a way this is like having stack frames but it's still a bit

    > >different and it's all transparent to the programmer). When the

    > >function finishes execution it's output remains on that local

     stack.

     >

    > There's something you're missing here. How does the language know

     how many

     > parameters to remove from the main stack? Does every function have

     to

     > declare how many parameters it'll take? What if it takes a

     variable amount

     > of parameters?

    >

     I think there are a few ways to deal with that - one way is for the

    function to take parameters from the main stack as it needs them.

    Or to put it another way lets say there is no local stack but that

    the function just uses the main stack and every element on stack

    that gets touched by the function gets marked. When the function

    returns, all the marked elements get moved into a temporary stack.

     > >There would be a small number of functions designed specifically

     to

     > >manipulate that local stack and transfer the values to the main

    > >stack so basically local stacks would replace lists

    >

    > Doesn't this have all the same problems as list manipulation? Or

     is it

     > impossible to return a function, in which case your language isn't

     capable

     > of the same things Joy is?

    >

    > >Now I'm not completely sure how automatic merging of local stacks

    > >with the main stack should work.

    >

    > Problems like this are hard, because no matter how clever you get

     there's

     > some programmer who'll reasonably expect it to behave differently.

     The more

     > clever you get, the more expectations you meet -- and the harder

     it'll be to

     > know when an expectation isn't being met.

    >

     I've been thinking about this yesterday for a while and I came to

    the same conclusion. The behavior of the functions wouldn't be

    consistent as they'd be split into two groups - those that

    manipulate values on the temporary stack and those that treat the

    temporary stack as an extension of the main stack.

     > >I remember starting a big discussion about laziness in

     concatenative

     > >languages when I first joined the board and I've been convinced

     that

     > >laziness doesn't make sense in a language like Joy (basically

    > >execution in concatenative languages is sequential so delaying

    > >execution is pointless while in applicative languages execution

     is

     > >more like a tree so delaying execution of some of the branches of

    > >the tree makes sense).

    >

    > Yup. But it DOES make sense to have an agressively evaluated

     concatenative

     > language -- essentially, one where any function with all its

     inputs known

     > gets evaluated immediately, and the result substituted in the

     compilation.

     > Speculation: aggressive concatenative is roughly equivalent to lazy

    > applicative.

    >

     I dissagree with that. Lazy evaluation is explicit to the programmer

    while this wouldn't be. This is more like an optimization. Basically

    if you have a function f == [2 +] and somewhere in the code it's

    called with 3 on top of the stack you could replace 3 f with 5,

    assuming you're doing that in a function not a list, and it would

    all be transparent to the programmer.

    Furthermore you could compile the same code without that

    optimization and the output of the newly compiled program would be

    identical to the one compiled with the optimization (with a few

    exceptions such as programs that rely on their own execution time).

    Same is not true for lazy functional languages. If you made Haskell

    eager you'd break most Haskell programs.

     > >However with the changes I'm proposing it might make sense to

     make a

     > >lazy language although the final language might not be

     concatenative.

     >

    > I suspect it would be. But I'm not sure it would be as powerful as

     you'd

     > want.

     Probably not. If such a language encapsulated lists into functions

    it would again have the same problem that Joy has - you wouldn't

    know which function contains a list and which function expects

    parameters on stack. So in a tree consisting of functions you

    wouldn't know which functions would yield lists.

     >

    > -Billy

     Ivan