optional user-specified end-delimiters
Per Bothner
(16 Apr 2013 19:32 UTC)
|
Re: optional user-specified end-delimiters John Cowan (16 Apr 2013 21:46 UTC)
|
Re: optional user-specified end-delimiters
Per Bothner
(16 Apr 2013 23:25 UTC)
|
Re: optional user-specified end-delimiters
John Cowan
(17 Apr 2013 06:41 UTC)
|
Re: optional user-specified end-delimiters
Per Bothner
(17 Apr 2013 18:03 UTC)
|
Re: optional user-specified end-delimiters
John Cowan
(17 Apr 2013 18:08 UTC)
|
Re: optional user-specified end-delimiters John Cowan 16 Apr 2013 21:46 UTC
Per Bothner scripsit: > It seems reasonable to allow an integer label, so we allow starting > with a digit. Thus for simplicity we also allow hyphen, underscore, > or period. I think starting with a digit is just an extra complication, and we shouldn't have it. It's a special case that needs to be tested, documented, and learned separately. > (In an unrelated change, I think tagname-subsequent should allow > periods. XML compatibility is one reason.) +1 > extended-string-literal ::= "&" string-starttag? > "{" initial-ignored? string-literal-part* "}!" string-endtag? > string-starttag ::= "!" label > string-endtag ::= "!" label > > The string-endtag is required if the string-starttag is specified, > and of course the labels must match. I think the string-endtag should be label followed by "!" instead. That way all the content, including both labels, is between "!" and "!". > Note this chance means that an extended-string-literal must be > followed by a delimiter or end of input. > > For a named quasi-literal, we can use the constructor-name as an end-tag: > > &example{ > &|line1 > &|line2 > }example I am very much against this, for reasons given earlier: "}example" should not be distinct from "} example", since "}" is a delimiter. > You can add an explicit label: I think an explicit label is the way to go. > &example!23{ > &|line1 > &|line2 > }example!23 I'd change this to "}23!", modulo not allowing digit-strings. > If may occasionally be useful to make labels available for > semantic information. One example is as implicit "id" attributes. I think that is a very bad mistake. The labels should be purely syntactic and discardable, like the numbers used in #2# and #2= datum labels; it's all the same if you write #2=(a . #2#) or #333=(a . #333#), and the Lisp system does not have to distinguish. > There are some plausible alternatives. For example we can put the > end-tag just before the right brace. For named constructors we > could use: > > &cname{ > line1 > line2 > &cname} That won't fly, because "&cname" is a perfectly cromulent substring. I really dislike your other alternatives as well. -- John Cowan http://ccil.org/~cowan xxxxxx@ccil.org We want more school houses and less jails; more books and less arsenals; more learning and less vice; more constant work and less crime; more leisure and less greed; more justice and less revenge; in fact, more of the opportunities to cultivate our better natures. --Samuel Gompers