[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: threads & dynamic environment & continuations
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
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!