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