I have repaired the sample implementation of SRFI 147 by changing
it to use the string ":continuation" instead of the identifier
:continuation.  That kind of change is not quite trivial, because

Thank you very much.

In my fork of the SRFI 147 repository

https://github.com/mnieper/srfi-147

I tried to fix the sample implementation as well so that it works for Larceny (should someone use the externally provided library).

In contrast to Will's fix, I continued to use a bound symbol (abbreviated from :continuation to :c) as the sentinel because the string ":continuation" could be forged by code using SRFI 147. (In particular, SRFI 147 should be able to eat itself.)

There is one place where macro rules are generated that use :c, namely here:

https://github.com/mnieper/srfi-147/blob/master/srfi/147.scm#L135

And there is one place where :c is added to a list of literals, namely here:

https://github.com/mnieper/srfi-147/blob/master/srfi/147.scm#L121

So I had to ensure that the same identifier :c (in the sense of bound-identifier=?) is being used. That's why :c is passed around in syntax-rules-aux.

Modulo bug-fixing, I intend to deliver this as a fix for SRFI 147, but not before SRFI 148 will have been fixed because it is a great test-bed for SRFI 147.

Marc

--

P.S.: Should SRFI 147 ever become a part of (scheme base) in Larceny, I think it is only fair when Larceny changes the semantics for let(rec)-syntax as defined by SRFI 147 to the R6RS-compatible (splicing) semantics of Larceny.

If Will could give me a hint on this, I would recode SRFI 148 more defensively (i.e. taking care of (let () ...) wrappers around let(rec)-syntax.