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 Per Bothner 16 Apr 2013 23:25 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/