Regarding my proposal to add with-unique-continuation-mark and use it for the implementation of parameterize and in SRFI155 where the tail-call-detection mark is set -- this works to satisfy the bounded-space tests. I tested it thoroughly today. But as I feared, it has a measurable performance impact on parameterize, even when I push all the heavy lifting into C code. I threw that code away.
So, in the end, I come back full-circle to the prior solution which involves explicit reduction where (srfi 155)'s code previously calls (current-dynamic-extent).
1) Where the DELAY macro invokes (current-dynamic-extent), the saved extent needs to be reduced to minimize the storage associated with all parameters and to reduce marks associated with the tail-call-detection key.
2) Since the forcing-extent is saved in a parameter, the same reduction must be done on that saved extent as well.
Let's assume for the moment that the (srfi 155) is the only client of (srfi 154) that requires this special feature. The time cost of the reduction is significant, so we don't want every call to (current-dynamic-extent) to incur this workload by default.
So, we need an extra special API function from (srfi 154) or an internals library it depends on:
(reduced-dynamic-extent extent tail-call-detection-key)
where tail-call-detection-key is the key used inside SRFI155 for tail-call detection in force. The procedure returns a new extent object with the minimization for parameters and reduction for the tail-call-detection marks. Since at most one new tail-mark is added per call to force, it is sufficient for reduced-dynamic-extent to remove at most 1 instance of the tail-call mark. However, since arbitrarily many parameterizations could occur in delayed expressions, the reduction for parameters needs to be to some fixed maximum # of parameter versions per parameter (I use 1 as that maximum).
Since this is for (srfi 155) only -- and I cannot envision anyone else needing it, except perhaps a later variant on (srfi 155), I don't really see any value in adding this to (srfi 154)'s specification. Already, there's no chance in hell this can be implemented with portable code, so there's little value in forcing the community to add reduced-dynamic-extent to their (srfi 154) implementation -- it's really only of interest to (srfi 155) implementors.
I've edited my (srfi 154) and (srfi 155) code and added it to a fork of the srfi-155 repo at:
In summary, I think the best bet is to leave the (srfi 155) _document_ alone (except there's a "their" which should be "there" ;-)). Accomplishing bounded-space requirements is an implementation detail.
There is ONE suggestion I could make though for the official (srfi 154) api -- a weakness of (current-dynamic-extent) is that it cannot reproduce the tail-call behavior associated with continuation marks, unless it is called in tail context itself, which is rarely useful. The continuation of the call to current-dynamic-extent will usually be to initialize an argument to another procedure call or to bind/assign a variable. Either way that's never in tail context, -- in your (srfi 157) parlance, "flag" is always #f. An alternative is:
where f is procedure which takes one argument. I could see this as either a replacement or addition to current-dynamic-extent which is trivial to implement in terms of the above.