[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: threads & dynamic environment & continuations

This page is part of the web mail archives of SRFI 18 from before July 7th, 2015. The new archives for SRFI 18 contain all messages, not just those from before July 7th, 2015.



     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