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)
|
On 04/16/2013 02:46 PM, John Cowan wrote: > 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. I'm fine with that. >> 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 "!". I assume you mean: &!END{content}END! See below why I think that is awkward. >> 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. Not sure I understand why. (I don't remember seeing the earlier reasons.) I don't see "}" listed as a <delimiter> in either R6RS or R7RS draft 8. Regardless, whether it is a <delimiter> is irrelevant - the question is what can follow the "}". Your suggested syntax does have "}TAG!" different from "} TAG!". >> 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. It would be nice to be able use "example" as an end-label, without having to explicitly declare it. Many markup languages have this, though not optional as I'm suggesting: @example foo @end example or XML: <example> foo </example> If you really dislike: &example{ &|line1 &|line2 }example Then we could require "!": &example{ &|line1 &|line2 }example! With an explicit label either: &example!n23{ &|line1 &|line2 }example!n23! or &example!n23{ &|line1 &|line2 }!n23! This gets a little messy, I think, which is why I think what I proposed works better, IMO: &!label{content}!label &example{content}example &example!label{content}!label &example!label{content}example!label ; probably less useful >> 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. Given the lack of a strong use-case, I'm fine leaving this out. We can always add it later. >> 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. No, it's not, since "&" is an escape character in <content>. > I really dislike your other alternatives as well. I agree - let's focus on the label *following* the "}". -- --Per Bothner xxxxxx@bothner.com http://per.bothner.com/