[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SRFI-109 (string quasi-literals) candidate

This page is part of the web mail archives of SRFI 109 from before July 7th, 2015. The new archives for SRFI 109 contain all messages, not just those from before July 7th, 2015.

On 03/26/2013 04:07 AM, John Cowan wrote:
Per Bothner scripsit:


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.


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


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.


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
per@xxxxxxxxxxx   http://per.bothner.com/