Email list hosting service & mailing list manager


optional end delimiters Per Bothner 27 Mar 2013 16:37 UTC

[Sent to both srfi-108 and srfi-109 lists, with follow-ups
to the srfi-108 list.]

We have been discussion whether to add optional end delimters
to SRFI-109 strings, for example:

&!END-TEXT{
   one two three
   uno dos tres
}END-TEXT!

On reflection, such end delimiters may be equally valuable
for named literals, including document processing.  In that
case it makes sense to allow the tagname as an end delimiter.
This is done in XML: <tag>...</tag>.
It is also common on document processing (markup) languages,
including Scribe, LaTeX and texinfo:

\begin{example}
\end{example}

@begin example
@end example

This makes it easier to "match up delimiters" and it can
help catch errors, especially for long bodies.

I suggest allowing an optional '&tagname' before the ending '}'.

&para{
Sentence1.
Sentence 2.
&para}

It is an error if the ending tagname doesn't match the start tagname.

This makes for easy parsing, without ambiguities.

Alternatively, having the end tag follow the '}'
is possible, but the parsing is more complex, and it
seems difficult to avoid ambiguities.  For example:

&para{
Sentence1.
Sentence 2.
}para

or:

...
}para!

or:
...
}!para

Having the end delimiter start with '}' makes it easier to
find it (especially on the start of the line), but the syntax
and parsing becomes less obvious.

The SRFI-109 (string) syntax should be designed in conjuction
with this.  For example, if we go with the:

&para{
...
&para}

syntax, then a "matching" SRFI-109 syntax might be:

&!END{
...
!END}
--
	--Per Bothner
xxxxxx@oracle.com   xxxxxx@bothner.com   http://per.bothner.com/