I put an updated version of SRFI-109 here:
http://per.bothner.com/tmp/srfi-109/srfi-109.html

Before I ask the editors to update srfi.schemers.org,
I'd like a see if anyone has any options on some open
"Discussion" item, before I remove them.  See the draft
for context:

(1) "Discussion: It may be useful to allow an option to use a
user-defined token, following a marker character - for example!"

I'm leaning towards dropping this, though I might keep a mention
as a possible future or implementation extension.

(1a) If someone has a preferred syntax for such an extension, that would
be useful to know.

(2) "Discussion: How about initial and final newlines?"

Not sure what the right answer is here.  The Kawa implementation
includes the initial newline in the result string; however that feels
wrong.  I.e.

(define onetwothree &{
      &|one two three
      &|uno dos tres
})

This seems like the natural way to write a 2-line string;
having to add an intial line-continuation marker &- seems
ugly.

Perhaps we can change the rule for &| - it deletes any
prior whitespace in that line. It *also* deletes the prior
newline if this is an initial newline.

(4) "Discussion: The above example is a bit ugly; it might be reasonable
to allow comments before the line-start marker:"

What do people think?  It makes the parsing a little more complicated,
but it seems useful.  And would we allow multi-line nested comments?

(define abc &{
   &| line1
   #|there is some special about this,
   so we need a multi-line comment |# &| line2
   &| line3})

This looks complicated. My inclination is to drop this
for now; it could be a feature of a future extension.

(5) "Discussion: Similar to Scheme character literals, a single-character
could name that character."

I.e. "&" followed by a single character followed by ";"
is equivalent to that literal character.  Is this convenient
enough to make up for adding yet more weird syntax?

(6)  "Discussion: Should we also support the standard string
single-character slash escapes in some form?"

I.e. &\n for newline.

(7) "Discussion: It may be reasonable to move format support to a
separate SRFI, where we could also cover string localization."

I think we certainly want to defer string localization (I don't
have time to deal with it right now), and I think we want to
make format specifiers an optional feature.  I'm not sure
whether and how to mention these optional/future features.
I think it makes sense to mention then in the context of a
rationale, to point to future directions.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/