(Previous discussion continued)
Re: SRFI-109 (string quasi-literals) candidate Per Bothner 26 Mar 2013 18:49 UTC

Re: SRFI-109 (string quasi-literals) candidate Per Bothner 26 Mar 2013 18:49 UTC

On 03/26/2013 04:07 AM, John Cowan wrote:
> Per Bothner scripsit:
>
>> http://per.bothner.com/tmp/srfi-109/srfi-109.html

I updated the draft based on your suggestions.

> Under "Enclosed (unquoted) expressions" the statement that & is used
> for two different purposes is just confusing: it's used for *many*
> different purposes.

Changed.

> Under "Template processing" the reference to curly braces should be to
> square brackets.

Fixed.

> Under "Indentation and line-endings", there is no definition of what it
> means for a newline to be normalized.

Fixed.  I also tweaked the "Translation" section to make it explicit
that line-ending is mapped to \n.

> Under "Special characters" the text reads "Only the characters , , and
> '&'", which is a result of missing >s on the first two "code" start-tags.

Fixed.

> I think the user-defined end-token should be made first-class, using
> the "}END-TEXT!" syntax, unless there is a demonstrable problem with
> processing it.

This one I haven't resolved yet.  For one things I'd like to
trying implementing in Kawa whatever syntax we end up on.
Does anyone else have an opinion?  Is '!' a good character to
mark the end-token?  Any chance we might want to use '!'
for internationalized strings instead?
What about SRFI-108 - should we allow a user-defined end-token
there as well?  One might think so for consistency, but there may
be some ambiguity issues.

> Since you define a preferred style for tagnames, you should include the
> restriction that the letters and digits should be ASCII in the preferred
> style, not arbitrary Unicode.  Personally, I'd make this style the
> required style, not just preferred; it will help with portability.

What do you think of the way I changed it?
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/