[Prev][Next][Index][Thread]
Re: Dylan Features
"Bruce Hoult" <bruce@hoult.org> wrote in message
bruce-D2F886.11172406082000@news.akl.ihug.co.nz">news:bruce-D2F886.11172406082000@news.akl.ihug.co.nz...
> You can convert this (manally or automatically) into
> "continuation-passing style":
>
> define method fact(n, return)
> if (n = 0)
> return(1)
> else
> fact(n - 1, method (val) return(n * val) end)
> end
> end;
>
> Now, instead of calling this as...
>
> format-out("factorial 5 is %=\n", fact(5));
>
> ... you'd call it as ...
>
> fact(5, method (val) format-out("factorial 5 is %=\n", val) end);
I think I understand the idea, but I'm still unclear on some of the
details. For instance, is "val" a keyword? I'm also unclear why you'd want
to do this, the second example makes my eyes cross.
> The most striking property is that no function *EVER* falls off the end
> and returns. You *always* end up with a tail-call to a function that
> itself never returns.
Ahhhh.
> Another interesting property is that it makes passing arguments and
> passing back function results symmetrical. Why can you pass multiple
> arguments but not multiple results in most languages? Because that's
> the way the historical function call ABI is set up. Well, with CPS you
> never actually return, you just call the guy who is going to use your
> results
Ahhhhh. But wouldn't having a dynamic call stack make this the expensive
op?
> format-out(
> "factorial 5 is %=\n",
> block (continuation)
> fact(n, continuation)
> end
> )
What is "continuation"?
> C doesn't have closures. The fact that Dylan has closures implies that
> some data that looks as if it could be stored on the stack (and could be
> in C) in fact has to be stored on the heap. Closures in effect create
> "objects".
Hmmm, in many of my other trollings I've seen debates between closures and
blocks - if they're different. What's the closure here?
Maury
Follow-Ups:
References: