Email list hosting service & mailing list manager

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