Ben Giddings wrote:

> On Friday, August 8, 2003, at 12:07  AM, Jim Weirich wrote:
>
>> Ahh, that's where the confusion is!  Callcc doesn't stand for "call
>> continuation".  It is short for "call with current continuation".   In
>> other words, it calls a function passing in the current continuation.
>
>
> I actually understood that -- I just found it confusing.  Offhand, I 
> can't think of other Ruby classes that don't have a constructor, and 
> can only be created by a method in an unrelated class or module.  
> Besides, it doesn't precisely call a function passing the current 
> continuation, it yields to a block, passing in the current 
> continuation, if I understand things.
>
>> Actually, to me it seems that the Continuation.new syntax is the one
>> that is deceptive.  For callcc doesn't create a NEW continuation, it
>> just makes the existing continuation for the block available.  All
>> function calls have a continuation (its the code that is executed when
>> the function returns).  Callcc just makes that already existing
>> continuation available.
>
>
> Right, but I'd argue that it is creating a "Continuation".  An object 
> of that class is being created, one which encapsulates the appropriate 
> state when callcc is used.  It's true that an abstract continuation is 
> created behind the scenes whenever a function is called, it's just 
> that that process is internal to the interpreter, and not available to 
> programs.
>
> I don't think that Continuation.new is deceptive in how it acts, 
> although it is somewhat deceptive in how it is implemented. 


Perhaps Continuation.new isn't the right method name.

Maybe Continuation.capture, or something of that sort?

And if I may play devil's advocate, Proc instances can be made from the 
Kernel.proc or
Kernel.lambda methods, although I admit that there is Proc.new that does 
the same thing.
MatchData objects are never constructed directly, as they are only the 
result of regular
expression matching.  It's not unheard of, or even particularly 
uncommon, to have object
oriented systems where certain objects are never constructed directly by 
a constructor,
but are made by other methods in the class or even in another class. For 
an example of
the latter, look at the Image class back in the Java 1.1 days.  Back 
then, the only ways
to get an Image object were to call Toolkit.getImage() or 
Component.createImage(). I'm
not saying that's a good design decision, but it does happen.

If you ask me, Kernel.callcc does make a lot of sense, since what you're 
effectively doing
is calling a function (okay, a proc, but they're similar) in a special 
way, which is related
to the more low-level aspects of the interpreter and such.  Then again, 
Proc.new exists,
and it has to create a closure, which seems fairly low level. But, I'm 
getting off topic.

That doesn't mean that callcc is intuitive for everyone, though, so if 
it helps you to move
the functionality to Continuation, then it's a good idea, at least for you.

Regards,

- Dan