[This ticket was originally about string escapes, but commenters have been talking about symbol escapes instead.]
R6RS provides character escapes in symbols of the form \xnnnn;, where nnnn is 1-5 hex digits. Do we accept this extension? Do we also allow |...| to escape a whole symbol or a part of one?
Providing |...| escapes for symbols (but not allowing them to escape spaces) deals with much of that.
Replying to [comment:2 cowan]:
Providing |...| escapes for symbols (but not allowing them to escape spaces) deals with much of that.
What do you mean by not allowing |...| to escape spaces?
By "not escaping spaces" I mean that |foo bar| is invalid syntax rather than (as in PLT, Gauche, MIT, Gambit, Chicken, Kawa, SISC, Chez, Ikarus, Scheme 9, Scheme 7) the symbol whose string name is "foo bar". This prevents an unpaired | from turning the rest of the program into a giant symbol, and aids readability as explained in the R6RS rationale. If you want that symbol, write foo\x20;bar or foo\{20}bar or whatever we decide on for local escaping.
I think the general point of || is to avoid the need for \x20; in the first place.
As far as I'm concerned, it's much more important to be able to import the identifier FOO from a case-preserving module into a case-folding one as |FOO| rather than \x46;\x4F;\x4F;.
I would consider them the same basic issue. It's a literal block escape for scheme values. Why should we limit what goes between them? Arbitrarily limiting them to non space characters is just that, arbitrary. What about \x0;? TAB? I mean, a missing " will capture a whole bunch, and a missing | is no different.
Replying to [comment:7 cowan]:
It seems that there is an unfortunate consequence of using Trac for the purpose of discussing language design issues. I am fine with the string escapes, but there is a side effect in another area - namely symbols, where the string escapes are less than pleasing.
The WG voted to accept this feature.
The thing is that those escapes make the printable form of symbols *fugly*. At least in Larceny - and as I recall Will explaining it, the Larceny behavior is strongly implied (if not actually mandatory) by R6RS.
I think this area needs work.