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