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 17 Apr 2013 06:41 UTC

Per Bothner scripsit:

> I assume you mean:
>   &!END{content}END!

Yes, that's what I meant.  But on reflection I agree that this is bad.

> >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.

That's because it is undefined altogether.  It doesn't make sense to
define something as a delimiter and then say it doesn't actually have
any function.  But in the context of these SRFIs, { and } clearly act
as delimiters, not as identifier characters.

> Regardless, whether it is a <delimiter> is irrelevant - the question
> is what can follow the "}".  Your suggested syntax does have
> "}TAG!" different from "} TAG!".

Yes, and since terminal ! is part of regular Scheme identifiers (though
not tags as defined here), it doesn't make sense to postpose it.

> &!label{content}!label
> &example{content}example
> &example!label{content}!label
> &example!label{content}example!label  ; probably less useful

The more I think about these, the less I think any of them are all that
useful.  XML are what it is (and so is LaTeX and other self-delimiting
markup schemes), but I don't think their ideas need to be pervasive: the
increasing popularity of JSON (which is just S-expressions with braces)
over XML shows that.

I am not one to say "Well, it's bad for the unaided user, but it's
all right if you have the right tools", but I think paren-counting
(brace-counting, etc.)  tools are a price we already pay in Scheme, and I
think we should avoid further complicating something that is already very
bell-and-whistle-filled with all these alternative delimitation schemes.
Let's just stick to "} matches { and ] matches [" and that's all there
needs to be to it.

--
John Cowan                                   xxxxxx@ccil.org
        "You need a change: try Canada"  "You need a change: try China"
                --fortune cookies opened by a couple that I know