Some ramblings about continuation marks Chris Hanson (13 Jun 2023 21:51 UTC)
(missing)
Fwd: Some ramblings about continuation marks Marc Nieper-Wißkirchen (23 Jun 2023 06:23 UTC)
Re: Some ramblings about continuation marks Philip McGrath (22 Jun 2023 21:21 UTC)
Re: Some ramblings about continuation marks Marc Nieper-Wißkirchen (23 Jun 2023 06:22 UTC)

Some ramblings about continuation marks Chris Hanson 13 Jun 2023 21:51 UTC

I've been learning about continuation marks so that I can implement
them in MIT/GNU Scheme, and I've run across some things I'd like to
discuss.  There are two things: the first is my understanding of the
underlying model, which seems to be different from the one presented;
the second is some quirks about the interface.

Let me prefix the following by saying that I'm not asking for the SRFI
to be changed.  I'm simply looking for some clarity and discussion
about the choices.  Perhaps a future alternative SRFI may come of
this, if there's anything worthwhile here.

1.

Trying to understand the model shown in the code was very confusing,
mostly because of the complicated rules about the FLAG value, which is
supposed to indicate whether the expression being evaluated is in
tail-recursive position.  In the process, I came up with an
alternative model in which the flag is unnecessary.

In the alternative model, the MARKS value is a list of frames, as in
the example code.  Each mark frame is the mark set of the
corresponding continuation frame.  When a continuation frame is
created, it contains the value of MARKS at that point, after which
MARKS is updated by pushing a new empty mark set at the beginning.
When a continuation frame is invoked, MARKS is restored to the stored
value.

Now, the model I describe suffers from creating many empty frames when
continuation marks are used sparingly, so I'd apply a simple
optimization.  When a continuation frame is created, instead of
changing MARKS, it is left as is.  Then, which a continuation mark is
set, the value of MARKS is compared to the one stored in the topmost
continuation frame, and if they're the same, a new mark frame is
created.  This avoids creating empty mark frames, and pushes some of
the cost onto the use of marks.

This seems to me to be a very simple and valid model for continuation
marks, but I'd like some feedback from those who've spent more time
thinking about it than I have.

2.

As for the interface, I have two nits.  While I understand that one
goal of this SRFI is compatibility with Racket, I think that the
original design is flawed.

First, WITH-CONTINUATION-MARK doesn't really make sense, as it misuses
the WITH- pattern generally used in Scheme.  This pattern generally
implies that some change is valid for a particular extent that is
delimited by the WITH- form.  But that's not the case for
with-continuation-mark: once the change is made, it persists past the
end of the form until the enclosing continuation frame is invoked.  As
such, it would make more sense to have SET-CONTINUATION-MARK! which
more clearly indicates what's happening.  As a bonus, the latter
syntax is simpler.

Second, two different names are used for the set of continuation
marks.  The procedure CURRENT-CONTINUATION-MARKS retrieves them, and
CONTINUATION-MARKS? tests for such an object.  But when interrogating
the sets, CONTINUATION-MARK-SET->*** are used.  So what does the
latter mean?  Is CONTINUATION-MARK-SET an alias for
CONTINUATION-MARKS, or is it saying that the parameters specify a
subset of the marks and the procedure is returning those?  And if the
latter, it seems that the procedure CONTINUATION-MARK-SET->LIST*
should be called CONTINUATION-MARK-SETS->LISTS.

Again, I'd appreciate hearing feedback about this.

Thanks,
Chris