Re: [Rd] callCC in 2.7.0
On Tue, 1 Apr 2008, Dr. Ferdinand Jamitzky wrote: > Anyway something like "yield" would be very nice to have. > Would it be hard to implement? Short answer: yes, it would be hard. Longer answer: R's interpreter is based on lots of recursive C calls. There are standard ways of implementing continuations in that sort of context, but they are not entirely portable (involves C stack copying), require assembly language programming on some platforms (register window flushing on sparc for example) and can be fairly inefficient. It might be possible to implement something more restricive that is sufficient for implementing generators, but I don't think it would be much easier given the current architecture. It is worth keeping this in mind if we make changes to the evaluator, but that is not likely to happen real soon. Some of us worked on something along these lines a while back in a branch called R-uthreads, but the cost of converting to that approach and the overhead of maintaining it seemed too high for the benefit, at least at the time. Best, luke > It could be in a similar way to scala where you can define for-comprehensions. > I really miss them in R. > best wishes > ferdinand > > On Tue, Apr 1, 2008 at 12:32 PM, Luke Tierney <[EMAIL PROTECTED]> wrote: >> No. First class continuations of the kind provided in scheme can be >> used as a means to implement generators, but downward-only >> continuations as currently provided in R are not sufficient for that. >> This version is intended only as a non-local exit mechanism. >> >> Best, >> >> luke >> >> On Mon, 31 Mar 2008, f.jamitzky wrote: >> >> > >> > callcc is similar to the "yield" keyword in python and c# >> > it lets you define e.g. a generator of lists of numbers. >> > >> > >> > >> > >> > Gabor Grothendieck wrote: >> >> >> >> Would anyone like to explain if callCC in R 2.7.0 gives >> >> anything that on.exit does not already provide? >> >> >> >> It seems that the exit condition once defined cannot >> >> be added to overridden whereas with on.exit multiple >> >> on.exit's add additional on.exits rather than being ignored. >> >> >> >> Is this important? >> >> >> >> __ >> >> R-devel@r-project.org mailing list >> >> https://stat.ethz.ch/mailman/listinfo/r-devel >> >> >> >> >> > >> > >> >> -- >> Luke Tierney >> Chair, Statistics and Actuarial Science >> Ralph E. Wareham Professor of Mathematical Sciences >> University of Iowa Phone: 319-335-3386 >> Department of Statistics andFax: 319-335-3017 >> Actuarial Science >> 241 Schaeffer Hall email: [EMAIL PROTECTED] >> Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu >> > > > > -- Luke Tierney Chair, Statistics and Actuarial Science Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: [EMAIL PROTECTED] Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] callCC in 2.7.0
Anyway something like "yield" would be very nice to have. Would it be hard to implement? It could be in a similar way to scala where you can define for-comprehensions. I really miss them in R. best wishes ferdinand On Tue, Apr 1, 2008 at 12:32 PM, Luke Tierney <[EMAIL PROTECTED]> wrote: > No. First class continuations of the kind provided in scheme can be > used as a means to implement generators, but downward-only > continuations as currently provided in R are not sufficient for that. > This version is intended only as a non-local exit mechanism. > > Best, > > luke > > On Mon, 31 Mar 2008, f.jamitzky wrote: > > > > > callcc is similar to the "yield" keyword in python and c# > > it lets you define e.g. a generator of lists of numbers. > > > > > > > > > > Gabor Grothendieck wrote: > >> > >> Would anyone like to explain if callCC in R 2.7.0 gives > >> anything that on.exit does not already provide? > >> > >> It seems that the exit condition once defined cannot > >> be added to overridden whereas with on.exit multiple > >> on.exit's add additional on.exits rather than being ignored. > >> > >> Is this important? > >> > >> __ > >> R-devel@r-project.org mailing list > >> https://stat.ethz.ch/mailman/listinfo/r-devel > >> > >> > > > > > > -- > Luke Tierney > Chair, Statistics and Actuarial Science > Ralph E. Wareham Professor of Mathematical Sciences > University of Iowa Phone: 319-335-3386 > Department of Statistics andFax: 319-335-3017 > Actuarial Science > 241 Schaeffer Hall email: [EMAIL PROTECTED] > Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu > -- # Dr. Ferdinand Jamitzky Leibniz Supercomputing Centre of the Bavarian Academy of Sciences and Humanities Boltzmannstraße 1 85748 Garching bei München Phone: ++49-89-35831-8727 Fax: ++49-89-35831-9700 Mobile: 0177 - 829 3 649 e-mail: [EMAIL PROTECTED] # __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] callCC in 2.7.0
Can I suggest some clarification of the help page for callCC plainly stating that it is intended to exit from a deeply nested set of calls. On a casual reading I thought the exact same thing as f.jamitsky. On Tue, Apr 1, 2008 at 6:32 AM, Luke Tierney <[EMAIL PROTECTED]> wrote: > No. First class continuations of the kind provided in scheme can be > used as a means to implement generators, but downward-only > continuations as currently provided in R are not sufficient for that. > This version is intended only as a non-local exit mechanism. > > Best, > > luke > > On Mon, 31 Mar 2008, f.jamitzky wrote: > > > > > callcc is similar to the "yield" keyword in python and c# > > it lets you define e.g. a generator of lists of numbers. > > > > > > > > > > Gabor Grothendieck wrote: > >> > >> Would anyone like to explain if callCC in R 2.7.0 gives > >> anything that on.exit does not already provide? > >> > >> It seems that the exit condition once defined cannot > >> be added to overridden whereas with on.exit multiple > >> on.exit's add additional on.exits rather than being ignored. > >> > >> Is this important? > >> > >> __ > >> R-devel@r-project.org mailing list > >> https://stat.ethz.ch/mailman/listinfo/r-devel > >> > >> > > > > > > -- > Luke Tierney > Chair, Statistics and Actuarial Science > Ralph E. Wareham Professor of Mathematical Sciences > University of Iowa Phone: 319-335-3386 > Department of Statistics andFax: 319-335-3017 >Actuarial Science > 241 Schaeffer Hall email: [EMAIL PROTECTED] > Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu > > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] callCC in 2.7.0
No. First class continuations of the kind provided in scheme can be used as a means to implement generators, but downward-only continuations as currently provided in R are not sufficient for that. This version is intended only as a non-local exit mechanism. Best, luke On Mon, 31 Mar 2008, f.jamitzky wrote: > > callcc is similar to the "yield" keyword in python and c# > it lets you define e.g. a generator of lists of numbers. > > > > > Gabor Grothendieck wrote: >> >> Would anyone like to explain if callCC in R 2.7.0 gives >> anything that on.exit does not already provide? >> >> It seems that the exit condition once defined cannot >> be added to overridden whereas with on.exit multiple >> on.exit's add additional on.exits rather than being ignored. >> >> Is this important? >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> >> > > -- Luke Tierney Chair, Statistics and Actuarial Science Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: [EMAIL PROTECTED] Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] callCC in 2.7.0
callcc is similar to the "yield" keyword in python and c# it lets you define e.g. a generator of lists of numbers. Gabor Grothendieck wrote: > > Would anyone like to explain if callCC in R 2.7.0 gives > anything that on.exit does not already provide? > > It seems that the exit condition once defined cannot > be added to overridden whereas with on.exit multiple > on.exit's add additional on.exits rather than being ignored. > > Is this important? > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- View this message in context: http://www.nabble.com/callCC-in-2.7.0-tp16382578p16395614.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] callCC in 2.7.0
Thanks. So its intended to jump straight out of deeply nested
calls without having to manage the unwinding.
On Sun, Mar 30, 2008 at 4:22 PM, Luke Tierney <[EMAIL PROTECTED]> wrote:
> On Sun, 30 Mar 2008, Gabor Grothendieck wrote:
>
> > Sorry it should be as follows:
> >
> > fib <- function(i, a = 0, b = 1) {
> > if (i == 0) b else fib(i-1, b, a+b)
> > }
> >
> > Now, how do we transform that to use callCC?
> >
> >
> > On Sun, Mar 30, 2008 at 1:42 PM, Gabor Grothendieck
> > <[EMAIL PROTECTED]> wrote:
> >> OK. Can you show code to implement the tail recursive version of
> >> fib using callCC in R, say.
> >>
> >> Here it is transformed to tail recursive style:
> >>
> >> fib <- function(i, a = 0, b = 1) {
> >> if (i == 0) a else fib(i-1, b, a+b)
> >>
> >> Now, how do I add callCC to all this so that the fib call
> >> presumably does not create a new stack instance?
>
> What makes you think callCC has anything to contribute here?
>
> The Wikipedia article Hadley cited says that using CPS effectively is
> difficult without tail call optimization, which R does not have and
> can't, at least not without some restrictions, because the stack is
> avialable via sys.xyz functions. It does _not_ say that having
> explicit continuations implies having tail call optimization.
>
> If you want to, you can rewrite your fib in CPS, something like
>
> fibCPS <- function(k, i, a = 0, b = 1) {
> if (i == 0) k(b) else fibCPS(k, i-1, b, a+b)
> }
>
> and you can then use callCC to bridge between the nonCPS and CPS
> world, e.g. with
>
> fib <- function(i) callCC(function(k) fibCPS(k, i, 0, 1))
>
> This will grow the stack just like any other recursion in R. A
> (minor) difference compared to your original fib is that the final
> exit happens in a single jump rather than a sequence of returns.
>
> The point of adding the current downward-only callCC to R is to
> provide a clean, lexically scoped non-local exit mechanism for exiting
> from complex, possibly recursive function calls. Dylan provides this
> as part of its 'block' construct (also as an exit or continuation
> function); Common Lisp has 'block'/'return-from' constructs that use
> lexically scoped block name symbols.
>
> For a slightly more realistic example than the ones currently in the
> help page: Here is some code that implements a simple binary tree data
> structure, and a function that visits the nodes of the tree and calls
> a specified function on the value in each node:
>
> mkTree <- function(value, left, right)
>list(isLeaf = FALSE, value = value, left = left, right = right)
> mkLeaf <- function(value) list(isLeaf = TRUE, value = value)
>
> visit <- function(node, fun) {
>if (node$isLeaf) fun(node$value)
>else {
>visit(node$left, fun)
>visit(node$right, fun)
>fun(node$value)
>}
> }
>
> A simple example tree:
>
> x <- mkTree(1, mkTree(2, mkLeaf(3), mkLeaf(4)),
>mkTree(5, mkLeaf(6), mkLeaf(7)))
>
> You can use visit() to print out the node values with
>
> > visit(x, print)
> [1] 3
> [1] 4
> [1] 2
> [1] 6
> [1] 7
> [1] 5
> [1] 1
> >
>
> If you want to use a function like visit() to traverse the tree but
> want the traversal to stop when some condition is met then you can
> either rewrite visit to allow for this, making it more complicated, or
> you can use a non-local exit. That is where callCC comes in. To
> print all values until you find one equal to 7 you can use
>
> > callCC(function(exit) {
> + fun <- function(value) {
> + if (value == 7) exit(NULL)
> + else print(value)
> + }
> + visit(x, fun)
> + })
> [1] 3
> [1] 4
> [1] 2
> [1] 6
> NULL
> >
>
> One can also imagine situations where this might be useful in a
> function passed to an optimizer like optim. Given that our 'break'
> only breaks out of one loop level, callCC can also be useful for
> breaking out of a set of nested loops.
>
> I first wrote this particular version of callCC when prototyping the
> tryCatch mechanism in pure R code where one needs a means to jump from
> a point where a condition is signaled to the point where the handler
> is established. The current tryCatch implementation does things
> differently because it needs to integrate with the error handling at
> the C level. Currently I use callCC in the constantFold function in
> codetools (which is why callCC was added when codetools became
> recommended). This use is similar to the tree example.
>
>
> luke
>
> >>
> >>
> >> On Sun, Mar 30, 2008 at 1:31 PM, Luke Tierney <[EMAIL PROTECTED]> wrote:
> >>> On Sun, 30 Mar 2008, Gabor Grothendieck wrote:
> >>>
> I think the only relationship to that is the name since
> it does not appear to allow one to leave a function
> in the middle of its processing and re-enter it back
> at that point -- which is what would be needed.
> >
Re: [Rd] callCC in 2.7.0
On Sun, 30 Mar 2008, Gabor Grothendieck wrote:
> Sorry it should be as follows:
>
> fib <- function(i, a = 0, b = 1) {
> if (i == 0) b else fib(i-1, b, a+b)
> }
>
> Now, how do we transform that to use callCC?
>
>
> On Sun, Mar 30, 2008 at 1:42 PM, Gabor Grothendieck
> <[EMAIL PROTECTED]> wrote:
>> OK. Can you show code to implement the tail recursive version of
>> fib using callCC in R, say.
>>
>> Here it is transformed to tail recursive style:
>>
>> fib <- function(i, a = 0, b = 1) {
>> if (i == 0) a else fib(i-1, b, a+b)
>>
>> Now, how do I add callCC to all this so that the fib call
>> presumably does not create a new stack instance?
What makes you think callCC has anything to contribute here?
The Wikipedia article Hadley cited says that using CPS effectively is
difficult without tail call optimization, which R does not have and
can't, at least not without some restrictions, because the stack is
avialable via sys.xyz functions. It does _not_ say that having
explicit continuations implies having tail call optimization.
If you want to, you can rewrite your fib in CPS, something like
fibCPS <- function(k, i, a = 0, b = 1) {
if (i == 0) k(b) else fibCPS(k, i-1, b, a+b)
}
and you can then use callCC to bridge between the nonCPS and CPS
world, e.g. with
fib <- function(i) callCC(function(k) fibCPS(k, i, 0, 1))
This will grow the stack just like any other recursion in R. A
(minor) difference compared to your original fib is that the final
exit happens in a single jump rather than a sequence of returns.
The point of adding the current downward-only callCC to R is to
provide a clean, lexically scoped non-local exit mechanism for exiting
from complex, possibly recursive function calls. Dylan provides this
as part of its 'block' construct (also as an exit or continuation
function); Common Lisp has 'block'/'return-from' constructs that use
lexically scoped block name symbols.
For a slightly more realistic example than the ones currently in the
help page: Here is some code that implements a simple binary tree data
structure, and a function that visits the nodes of the tree and calls
a specified function on the value in each node:
mkTree <- function(value, left, right)
list(isLeaf = FALSE, value = value, left = left, right = right)
mkLeaf <- function(value) list(isLeaf = TRUE, value = value)
visit <- function(node, fun) {
if (node$isLeaf) fun(node$value)
else {
visit(node$left, fun)
visit(node$right, fun)
fun(node$value)
}
}
A simple example tree:
x <- mkTree(1, mkTree(2, mkLeaf(3), mkLeaf(4)),
mkTree(5, mkLeaf(6), mkLeaf(7)))
You can use visit() to print out the node values with
> visit(x, print)
[1] 3
[1] 4
[1] 2
[1] 6
[1] 7
[1] 5
[1] 1
>
If you want to use a function like visit() to traverse the tree but
want the traversal to stop when some condition is met then you can
either rewrite visit to allow for this, making it more complicated, or
you can use a non-local exit. That is where callCC comes in. To
print all values until you find one equal to 7 you can use
> callCC(function(exit) {
+ fun <- function(value) {
+ if (value == 7) exit(NULL)
+ else print(value)
+ }
+ visit(x, fun)
+ })
[1] 3
[1] 4
[1] 2
[1] 6
NULL
>
One can also imagine situations where this might be useful in a
function passed to an optimizer like optim. Given that our 'break'
only breaks out of one loop level, callCC can also be useful for
breaking out of a set of nested loops.
I first wrote this particular version of callCC when prototyping the
tryCatch mechanism in pure R code where one needs a means to jump from
a point where a condition is signaled to the point where the handler
is established. The current tryCatch implementation does things
differently because it needs to integrate with the error handling at
the C level. Currently I use callCC in the constantFold function in
codetools (which is why callCC was added when codetools became
recommended). This use is similar to the tree example.
luke
>>
>>
>> On Sun, Mar 30, 2008 at 1:31 PM, Luke Tierney <[EMAIL PROTECTED]> wrote:
>>> On Sun, 30 Mar 2008, Gabor Grothendieck wrote:
>>>
I think the only relationship to that is the name since
it does not appear to allow one to leave a function
in the middle of its processing and re-enter it back
at that point -- which is what would be needed.
>>>
>>> The article conflates basic CPS with having first class continuations
>>> as in Scheme. The discussion about compilers and tail calls only
>>> requires downward-only continuations of the kind provided by R's
>>> current callCC. The user interface and coroutine discussion requires
>>> continuations that can be run outside of their creating context. The
>>> most sophisticated variant,
Re: [Rd] callCC in 2.7.0
OK. Can you show code to implement the tail recursive version of
fib using callCC in R, say.
Here it is transformed to tail recursive style:
fib <- function(i, a = 0, b = 1) {
if (i == 0) a else fib(i-1, b, a+b)
Now, how do I add callCC to all this so that the fib call
presumably does not create a new stack instance?
On Sun, Mar 30, 2008 at 1:31 PM, Luke Tierney <[EMAIL PROTECTED]> wrote:
> On Sun, 30 Mar 2008, Gabor Grothendieck wrote:
>
> > I think the only relationship to that is the name since
> > it does not appear to allow one to leave a function
> > in the middle of its processing and re-enter it back
> > at that point -- which is what would be needed.
>
> The article conflates basic CPS with having first class continuations
> as in Scheme. The discussion about compilers and tail calls only
> requires downward-only continuations of the kind provided by R's
> current callCC. The user interface and coroutine discussion requires
> continuations that can be run outside of their creating context. The
> most sophisticated variant, as provided in Scheme, also allows
> continuations to be run more than once. I don't think any of the
> examples in the Wikipedia article need that, but there is some
> interesting work on using that to model web browsing behavior.
>
> At any rate, there is plenty of precedent for using callCC as the name
> for the construct here even when the continuation is no longer valid
> outside of the creating callCC call. So the relationship is more than
> just the name.
>
> luke
>
> >
> > On Sun, Mar 30, 2008 at 12:04 PM, <[EMAIL PROTECTED]> wrote:
> >>
> >>> Would anyone like to explain if callCC in R 2.7.0 gives
> >>> anything that on.exit does not already provide?
> >>>
> >>> It seems that the exit condition once defined cannot
> >>> be added to overridden whereas with on.exit multiple
> >>> on.exit's add additional on.exits rather than being ignored.
> >>>
> >>> Is this important?
> >>
> >> It facilitates a completely different style of programming - see
> >> http://en.wikipedia.org/wiki/Continuation-passing_style
> >>
> >> --
> >> http://had.co.nz/
> >>
> >
>
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> --
> Luke Tierney
> Chair, Statistics and Actuarial Science
> Ralph E. Wareham Professor of Mathematical Sciences
> University of Iowa Phone: 319-335-3386
> Department of Statistics andFax: 319-335-3017
>Actuarial Science
> 241 Schaeffer Hall email: [EMAIL PROTECTED]
> Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] callCC in 2.7.0
On Sun, 30 Mar 2008, Gabor Grothendieck wrote: > I think the only relationship to that is the name since > it does not appear to allow one to leave a function > in the middle of its processing and re-enter it back > at that point -- which is what would be needed. The article conflates basic CPS with having first class continuations as in Scheme. The discussion about compilers and tail calls only requires downward-only continuations of the kind provided by R's current callCC. The user interface and coroutine discussion requires continuations that can be run outside of their creating context. The most sophisticated variant, as provided in Scheme, also allows continuations to be run more than once. I don't think any of the examples in the Wikipedia article need that, but there is some interesting work on using that to model web browsing behavior. At any rate, there is plenty of precedent for using callCC as the name for the construct here even when the continuation is no longer valid outside of the creating callCC call. So the relationship is more than just the name. luke > > On Sun, Mar 30, 2008 at 12:04 PM, <[EMAIL PROTECTED]> wrote: >> >>> Would anyone like to explain if callCC in R 2.7.0 gives >>> anything that on.exit does not already provide? >>> >>> It seems that the exit condition once defined cannot >>> be added to overridden whereas with on.exit multiple >>> on.exit's add additional on.exits rather than being ignored. >>> >>> Is this important? >> >> It facilitates a completely different style of programming - see >> http://en.wikipedia.org/wiki/Continuation-passing_style >> >> -- >> http://had.co.nz/ >> > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Luke Tierney Chair, Statistics and Actuarial Science Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: [EMAIL PROTECTED] Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] callCC in 2.7.0
I came across this in googling for continuations and was surprised when
I found it in R 2.7.0 and since I had not come across it before I assumed
it was added just now.
Can you explain how its intended to be used with an example
that is more realistic than in the example section.
On Sun, Mar 30, 2008 at 1:14 PM, Luke Tierney <[EMAIL PROTECTED]> wrote:
> On Sun, 30 Mar 2008, Gabor Grothendieck wrote:
>
> > Also in trying it out again it seems that its not like
> > on.exit but more like return:
>
> Yes -- if you can point out what in the documentation ever gave the
> idea it might be like on.exit then we can fix the documentation.
>
> >
> > F <- function(f) { f(10); print(2); f(20); 3}
> > callCC(F)
> >
> > acts the same as:
> >
> > F <- function() { return(10); print(2); f(20); 3}
> > F()
> >
> > and there is no documented way to restart F
> > at the point it left off so I assume it can't.
>
> The documentation descriped this as a downward-only version -- that is
> standard terminology for a callCC that produces continuations that are
> no longer valid after the callCC call exits.
>
> Not sure why your original question was about "callCC in 2.7.0" -- I
> believe callCC was added in 2.5.0, the same time as codetools became
> recommended, and hasn't changed since. It is not a function every R
> user needs to have in their repertoire, but it can be very useful in
> some situations.
>
> luke
>
> > On Sun, Mar 30, 2008 at 12:34 PM, Gabor Grothendieck
> > <[EMAIL PROTECTED]> wrote:
> >> I think the only relationship to that is the name since
> >> it does not appear to allow one to leave a function
> >> in the middle of its processing and re-enter it back
> >> at that point -- which is what would be needed.
> >>
> >>
> >> On Sun, Mar 30, 2008 at 12:04 PM, <[EMAIL PROTECTED]> wrote:
> >>>
> Would anyone like to explain if callCC in R 2.7.0 gives
> anything that on.exit does not already provide?
>
> It seems that the exit condition once defined cannot
> be added to overridden whereas with on.exit multiple
> on.exit's add additional on.exits rather than being ignored.
>
> Is this important?
> >>>
> >>> It facilitates a completely different style of programming - see
> >>> http://en.wikipedia.org/wiki/Continuation-passing_style
> >>>
> >>> --
> >>> http://had.co.nz/
> >>>
> >>
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> --
> Luke Tierney
> Chair, Statistics and Actuarial Science
> Ralph E. Wareham Professor of Mathematical Sciences
> University of Iowa Phone: 319-335-3386
> Department of Statistics andFax: 319-335-3017
>Actuarial Science
> 241 Schaeffer Hall email: [EMAIL PROTECTED]
> Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] callCC in 2.7.0
Sorry it should be as follows:
fib <- function(i, a = 0, b = 1) {
if (i == 0) b else fib(i-1, b, a+b)
}
Now, how do we transform that to use callCC?
On Sun, Mar 30, 2008 at 1:42 PM, Gabor Grothendieck
<[EMAIL PROTECTED]> wrote:
> OK. Can you show code to implement the tail recursive version of
> fib using callCC in R, say.
>
> Here it is transformed to tail recursive style:
>
> fib <- function(i, a = 0, b = 1) {
> if (i == 0) a else fib(i-1, b, a+b)
>
> Now, how do I add callCC to all this so that the fib call
> presumably does not create a new stack instance?
>
>
> On Sun, Mar 30, 2008 at 1:31 PM, Luke Tierney <[EMAIL PROTECTED]> wrote:
> > On Sun, 30 Mar 2008, Gabor Grothendieck wrote:
> >
> > > I think the only relationship to that is the name since
> > > it does not appear to allow one to leave a function
> > > in the middle of its processing and re-enter it back
> > > at that point -- which is what would be needed.
> >
> > The article conflates basic CPS with having first class continuations
> > as in Scheme. The discussion about compilers and tail calls only
> > requires downward-only continuations of the kind provided by R's
> > current callCC. The user interface and coroutine discussion requires
> > continuations that can be run outside of their creating context. The
> > most sophisticated variant, as provided in Scheme, also allows
> > continuations to be run more than once. I don't think any of the
> > examples in the Wikipedia article need that, but there is some
> > interesting work on using that to model web browsing behavior.
> >
> > At any rate, there is plenty of precedent for using callCC as the name
> > for the construct here even when the continuation is no longer valid
> > outside of the creating callCC call. So the relationship is more than
> > just the name.
> >
> > luke
> >
> > >
> > > On Sun, Mar 30, 2008 at 12:04 PM, <[EMAIL PROTECTED]> wrote:
> > >>
> > >>> Would anyone like to explain if callCC in R 2.7.0 gives
> > >>> anything that on.exit does not already provide?
> > >>>
> > >>> It seems that the exit condition once defined cannot
> > >>> be added to overridden whereas with on.exit multiple
> > >>> on.exit's add additional on.exits rather than being ignored.
> > >>>
> > >>> Is this important?
> > >>
> > >> It facilitates a completely different style of programming - see
> > >> http://en.wikipedia.org/wiki/Continuation-passing_style
> > >>
> > >> --
> > >> http://had.co.nz/
> > >>
> > >
> >
> > > __
> > > R-devel@r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/r-devel
> > >
> >
> > --
> > Luke Tierney
> > Chair, Statistics and Actuarial Science
> > Ralph E. Wareham Professor of Mathematical Sciences
> > University of Iowa Phone: 319-335-3386
> > Department of Statistics andFax: 319-335-3017
> >Actuarial Science
> > 241 Schaeffer Hall email: [EMAIL PROTECTED]
> > Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
> >
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] callCC in 2.7.0
On Sun, 30 Mar 2008, Gabor Grothendieck wrote:
> Also in trying it out again it seems that its not like
> on.exit but more like return:
Yes -- if you can point out what in the documentation ever gave the
idea it might be like on.exit then we can fix the documentation.
>
> F <- function(f) { f(10); print(2); f(20); 3}
> callCC(F)
>
> acts the same as:
>
> F <- function() { return(10); print(2); f(20); 3}
> F()
>
> and there is no documented way to restart F
> at the point it left off so I assume it can't.
The documentation descriped this as a downward-only version -- that is
standard terminology for a callCC that produces continuations that are
no longer valid after the callCC call exits.
Not sure why your original question was about "callCC in 2.7.0" -- I
believe callCC was added in 2.5.0, the same time as codetools became
recommended, and hasn't changed since. It is not a function every R
user needs to have in their repertoire, but it can be very useful in
some situations.
luke
> On Sun, Mar 30, 2008 at 12:34 PM, Gabor Grothendieck
> <[EMAIL PROTECTED]> wrote:
>> I think the only relationship to that is the name since
>> it does not appear to allow one to leave a function
>> in the middle of its processing and re-enter it back
>> at that point -- which is what would be needed.
>>
>>
>> On Sun, Mar 30, 2008 at 12:04 PM, <[EMAIL PROTECTED]> wrote:
>>>
Would anyone like to explain if callCC in R 2.7.0 gives
anything that on.exit does not already provide?
It seems that the exit condition once defined cannot
be added to overridden whereas with on.exit multiple
on.exit's add additional on.exits rather than being ignored.
Is this important?
>>>
>>> It facilitates a completely different style of programming - see
>>> http://en.wikipedia.org/wiki/Continuation-passing_style
>>>
>>> --
>>> http://had.co.nz/
>>>
>>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: [EMAIL PROTECTED]
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] callCC in 2.7.0
Also in trying it out again it seems that its not like
on.exit but more like return:
F <- function(f) { f(10); print(2); f(20); 3}
callCC(F)
acts the same as:
F <- function() { return(10); print(2); f(20); 3}
F()
and there is no documented way to restart F
at the point it left off so I assume it can't.
On Sun, Mar 30, 2008 at 12:34 PM, Gabor Grothendieck
<[EMAIL PROTECTED]> wrote:
> I think the only relationship to that is the name since
> it does not appear to allow one to leave a function
> in the middle of its processing and re-enter it back
> at that point -- which is what would be needed.
>
>
> On Sun, Mar 30, 2008 at 12:04 PM, <[EMAIL PROTECTED]> wrote:
> >
> > > Would anyone like to explain if callCC in R 2.7.0 gives
> > > anything that on.exit does not already provide?
> > >
> > > It seems that the exit condition once defined cannot
> > > be added to overridden whereas with on.exit multiple
> > > on.exit's add additional on.exits rather than being ignored.
> > >
> > > Is this important?
> >
> > It facilitates a completely different style of programming - see
> > http://en.wikipedia.org/wiki/Continuation-passing_style
> >
> > --
> > http://had.co.nz/
> >
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] callCC in 2.7.0
I think the only relationship to that is the name since it does not appear to allow one to leave a function in the middle of its processing and re-enter it back at that point -- which is what would be needed. On Sun, Mar 30, 2008 at 12:04 PM, <[EMAIL PROTECTED]> wrote: > > > Would anyone like to explain if callCC in R 2.7.0 gives > > anything that on.exit does not already provide? > > > > It seems that the exit condition once defined cannot > > be added to overridden whereas with on.exit multiple > > on.exit's add additional on.exits rather than being ignored. > > > > Is this important? > > It facilitates a completely different style of programming - see > http://en.wikipedia.org/wiki/Continuation-passing_style > > -- > http://had.co.nz/ > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] callCC in 2.7.0
> Would anyone like to explain if callCC in R 2.7.0 gives > anything that on.exit does not already provide? > > It seems that the exit condition once defined cannot > be added to overridden whereas with on.exit multiple > on.exit's add additional on.exits rather than being ignored. > > Is this important? It facilitates a completely different style of programming - see http://en.wikipedia.org/wiki/Continuation-passing_style -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] callCC in 2.7.0
Would anyone like to explain if callCC in R 2.7.0 gives anything that on.exit does not already provide? It seems that the exit condition once defined cannot be added to overridden whereas with on.exit multiple on.exit's add additional on.exits rather than being ignored. Is this important? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
