Bug #1302
closedStrange behavior of callcc
Description
=begin
The code runs "[0].map" with a block which uses callcc to stop the execution of map and return the continuation. Later this continuation is called three times with three different values. The expected behavior is that these calls should result in three different computations. Each computation being the mapping with the corresponing value. Instead, the result is very strange.
=end
Files
Updated by Sarwen (Christophe Calves) over 15 years ago
- File testcallcc.scm testcallcc.scm added
=begin
I did the same code in scheme. I tried under drscheme and petite-chez-scheme, both give the same result:
x1 = (1)
x2 = (2)
x3 = (3)
as expected.
To run the code:
petite --script testcallcc.scm
=end
Updated by Sarwen (Christophe Calves) over 15 years ago
=begin
I just tried on ruby 1.8
ruby -v¶
ruby 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux]
There is the same bug.
=end
Updated by nobu (Nobuyoshi Nakada) over 15 years ago
=begin
Hi,
At Thu, 19 Mar 2009 04:33:40 +0900,
Christophe Calves wrote in [ruby-core:22933]:
The code runs "[0].map" with a block which uses callcc to
stop the execution of map and return the continuation. Later
this continuation is called three times with three different
values. The expected behavior is that these calls should
result in three different computations. Each computation
being the mapping with the corresponing value. Instead, the
result is very strange.
I don't consider it a bug.
This is caused by the implementation of Enumerable#map, not
callcc. And the difference between callcctest.rb and
testcallcc.scm would be resulted in because of the difference
between Ruby's Array and Scheme's list.
--
Nobu Nakada
=end
Updated by Sarwen (Christophe Calves) over 15 years ago
- File callcctest_demo_map.rb callcctest_demo_map.rb added
=begin
Hi
Thank you very much. I realized some tests that show what's going on. The code runs the above code with 5 different impelementations of Array.map. When i did the first test, i made the assertion that, on contrary to array.map! whish is not persistent, array.map would be persistent. Actually it is in most usages but apparently not when the continuation is run more than once.
I think that in the test, x1 being obtained by a map ( [0].map { .... } ), it would be good that x1 would not be modified the way it is. That is to include in the standard library one of the two last maps in the following code as a persistent-guaranteed map. They are certainly less efficient but avoid susprises when playing with continuations.
=end