Carrier names should not contain semicolons

[t0mpr1c3]

The specification for carrier names is that they are arbitrary strings separated by spaces.

It may be problematic for parsers if a carrier name contains a semicolon, because the parser may think that part of the carrier name is a comment.

It may also be preferable to use whitespace (which includes tabs) rather than spaces as the delimiter.

[ixchow]

The design goal for knitout is to be easy to interact with programmatically; it is generally easier to split on a single character than a character class, thus the explicit definition of exactly single-space-separated carrier names. (It also seems unlikely that a ; would trick a parser, given that the header is already in a comment!)

For what it's worth, every machine-specific backend is much more strict about carrier naming, generally requiring strings corresponding to base-10 integers between 1 and the number of carriers on the machine.

Perhaps an outliner: the SRY backend actually uses more complicated carrier naming, using blobs like 01,11/21,31 to name the four carriers parked on rail 1. But, like the others, it specifies exactly the names that can be used and checks the header for strict equality.

[t0mpr1c3]

(It also seems unlikely that a ; would trick a parser, given that the header is already in a comment!)

There are at least two parsers under this account that fail. I suggest that it is easier to adjust the overly broad Knitout spec than rewrite the non-compliant parsers, but clearly it's your call. :)

[ixchow]

As per textiles-lab/fenced-tangle-supplemental#9

I would say that the parser is operating correctly. It can both be true that it is valid to name a carrier with a ; and that a valid parser will trim the last half of any operation involving that carrier.

[ixchow]

Thinking a bit more deeply here, I think the thing I want to avoid is any additional implementation burden for folks writing parsers in order to work around special cases.

Particularly, I have the following goals:

• I don't want to make parser authors do any additional work when parsing the Carriers header. (Thus: I would prefer not to place any conditions on carrier names in this location)
• I don't want to make parser authors do extra work when dealing with comments. (Thus: ; is always the comment character.)
• I do want to allow backends to be flexible in their interpretation of the Carriers header.

I believe that the current specification, as written, is unambiguous about what putting a ; in a carrier name will do: it will be fine in the carriers header ("these names can be any string") and then indicate a comment during instruction parsing ("The operation is everything up to the first ';' character, the comment is everything after").

I think the correct fix here is to be explicit in the spec about what parsers already do:

• they place more strict limitations (or, in some cases, different interpretations) on the Carriers header.
• they will not deal gracefully with a ; in a carrier name.

[ixchow]

(And, yes, deeper reflection suggests that I closed this issue too early! Apologies, and thank you for raising the consequence!)

[ixchow]

Commit e1466bd is an attempt to address this issue. It changes the ;;Carriers: header definition to include multi-carrier-per-rail definition (as per the SRY backend); and revises carrier names to ban space, comma, and semicolon. It also makes it clear that backends can be more strict than the specification.