threads & dynamic environment & continuations
shivers@xxxxxx
(12 May 2000 01:20 UTC)
|
Re: threads & dynamic environment & continuations
Marc Feeley
(12 May 2000 01:55 UTC)
|
Re: threads & dynamic environment & continuations
shivers@xxxxxx
(12 May 2000 18:14 UTC)
|
Re: threads & dynamic environment & continuations
Marc Feeley
(12 May 2000 18:38 UTC)
|
Re: threads & dynamic environment & continuations
shivers@xxxxxx
(12 May 2000 18:44 UTC)
|
Re: threads & dynamic environment & continuations
Matthias Felleisen
(12 May 2000 02:46 UTC)
|
Re: threads & dynamic environment & continuations shivers@xxxxxx (12 May 2000 02:58 UTC)
|
Re: threads & dynamic environment & continuations shivers@xxxxxx 12 May 2000 02:58 UTC
It is well understood in the SML/NJ community (which has been grabbing continuations, dealing with dynamically bound exceptions, and hacking threads for > 10 years), that the dynamic environment is *part of the continuation*. So throwing to a continuation discards the current dynamic environment, and installs the one packaged up with the continuation to which we are throwing. CALL/CC grabs the dynamic environment at the point of call and packages it up when it builds the reified continuation. This tops it off. Do you know how call/cc-continuations made it into Smell of New Jersey? Thru Bruce Duba, who with Dan and me had studied call/cc and interactions with the dynamic environment for four or five years in Indiana. If he had written his d'n dissertation, everyone would know where this stuff comes from. Instead he put callcc into this monstrosity of a so-called language, and gave these guys the funnest part of Scheme to play with. And you know what? Unless one of us reviews their papers, they don't even acknowledge what we knew before they were born-again call/ccers. They have added nothing to our knowledge baout call/cc. I even gave the type to Griffin. Mentioning them here is .... hm, insulting. :) Hey, it's not like I wasn't around when call/cc was put into Scheme! I think I can vaguely recall (only now that you have mentioned it in detail) you telling me the story of this transfer path a while ago. I didn't recall it when I wrote the above, tho. Interesting! I also agree with Marc on values. Throw them out. Now. They screwed up spidey so bad, it's not funny. You know, I *like* multiple values. You can't throw them out unless you throw out multiple parameters, too! ML (1/1) or R5RS (n/n). The middle ground (n/1) is inconsistent; it's sitting down between two stools. I like mv's because they can be passed back in the registers -- no consing of intermediate data structures. I like 'em because the run time & static type checkers can give you help -- your client won't mistakenly rip apart some list that *wasn't* a "multiple value." I like 'em because they are symmetric with the multiple parameters of LAMBDA. However, this is a (fun) flamefest that should be moved off of the SRFI-18 list onto comp.lang.scheme. Shame on you, Marc, for salting your moderation of this review discussion with such tantalizing bait! -Olin