On Wed, Mar 7, 2012 at 7:58 AM,  <oleg@okmij.org> wrote:
>
> Hello!
>
>        Sorry for a very late reply to your detailed message.

Sorry for the even later replies on my end - I've been
exceedingly busy, and I haven't had time yet to read
all of the helpful references you've sent to the list.

>> "Confusing" is rather subjective.  Exceptions and parameters
>> are defined in terms of call/cc and dynamic-wind, so the
>> semantics are at least unambiguous - parameters are in fact
>> strictly a library feature.
>
> One often desires an abstract specification of a feature to help
> reason with it. Luckily, dynamic binding has been studied for a long
> time, and several good semantic and syntactic theories are available.
> There are theories of delimited control, and theories of
> combining delimited control with dynamic binding. Alas, if we
> implement parameters and delimited control unaware of each other, the
> implementation does not agree with the specification. As my co-authors
> and I argued in 2006, either the implementation of dynamic binding has
> to be aware of delimited control, or delimited control has to be aware
> of dynamic binding. These features have to be implemented together.
>
>> The WG2 has already decided to include some form of delimited
>> continuation in the "Large" language, and is in fact looking for new
>> volunteers for that effort.  We'd be thrilled to have whatever help
>> you can contribute there.
>
> I am not sure that I have a large block of time to dedicate to that
> effort. If there are specific questions about delimited control, I
> will try to answer them promptly.

I'm sure any feedback would be appreciated.  I suspect the
biggest issue initially would be _which_ version of delimited
control to use, as there are several competing alternatives.
If there were only a single widespread alternative we might
have been able to include it in the small language.

>> For the R7RS "Small" language report, making call/cc optional is a
>> very big step, and we would need a better abstraction already
>> available and widely used.  I think as a standard the correct path
>> would be to make the best alternative possible available in R7RS
>> "Large", encourage its use, and then consider making call/cc optional
>> in R8RS.
>
> That seems like the best decision. It would be great if you consider
> rewording the section on call/cc. For example, there is a paragraph
> about history, going back to Landin's J. Alas, that history is a bit
> truncated, saying nothing about delimited control and particular cases
> of delimited control such as green threads, Concurrent ML-like
> threads, coroutines, generators. Since putting that much history into
> a report is improper, perhaps the section about call/cc can be
> abbreviated and extra material put into an appendix or other
> non-normative document.

Thanks, we'll revise that section.

>> I think the problem here is that the interaction of call/cc and
>> dynamic-wind itself can be confusing, and it is for this reason
>> that call/cc is not considered an every day tool but a basis for
>> defining simpler control operators.
>
> I do hope the Report will say at least a couple of words along these
> lines. The Report might have a non-normative addendum with a
> roadmap for the Large R7RS and R8RS, in which undelimited and delimited
> control will be discussed at greater extent (along with other planned
> features).
>
>> > Using call/cc has many practical drawbacks -- for example, huge
>> > resource leak. Capturing the whole continuation (where only a prefix
>> > is really needed) prevents objects referenced from the unneeded suffix
>> > of the continuations from being garbage collected.
>
>> I understand how this can be an issue in theory, but are there
>> real-world applications where this has been a problem?  It seems to me
>> that when using call/cc for delimited cont type control flow, the
>> suffix will remain constant and will be needed eventually anyway.
>> When using call/cc for undelimited control flow, this is something
>> that would not have been possible otherwise anyway, and is in a sense
>> a pay-as-you-go feature.
>
> Running our of memory does happen. Here is a simple
> test. Load the standard Danvy-Filinski implementation of shift in
> terms of call/cc into your Scheme system, and then run the following
> code
>
> (define (leak-test1 identity-thunk)
>  (let loop ((id (lambda (x) x)))
>      (loop (id (identity-thunk)))))
>
> (leak-test1 (lambda () (reset (shift f f))))
>
> On my system, using Petite Chez, the program crashes within a minute,
> after it allocated half a Gb and was asking for more. Can you spot
> the problem?

As I said, I understand that the leak exists - what I was
asking was whether there were any real-world applications
where this has actually been a problem?  I was positing
that typical shift/reset uses will tend to share the same
suffix and not leak.  It's a minor point, I was just wondering
if you had examples handy.

--
Alex

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports