Opened 6 years ago

Closed 6 years ago

#273 closed defect (wontfix)

Decide whether the presence of non-ASCII characters in symbols requires escaping or using vertical bars when output by `write'.

Reported by: aag Owned by: alexshinn
Priority: major Milestone:
Component: WG1 - Core Keywords:


In the section <Output>, in the description of `write', we say:

Symbols that contain non-ASCII characters are escaped either with inline hex escapes or with vertical bars.

Is this right? Shouldn't implementations that support Unicode be allowed to write symbols that contain non-ASCII characters without treating them specially?

The invariant we want to establish is that read' can read what write' has written.

The question for this ticket is whether the standard should require that that invariant hold only in the same implementation, or across implementations.

If we stick with the existing language, we get interoperability across implementations.

If we change the language to allow any non-whitespace character supported by the implementation to be written unescaped and without vertical bars, we lose interoperability across implementations, but gain the ability of the implementation to display symbols containing Unicode characters in a natural manner.

Change History (5)

comment:1 Changed 6 years ago by aag

Alex points out:

If some other implementation doesn't support the Greek
subset of Unicode, then they wouldn't support it even
if it were escaped.

comment:2 Changed 6 years ago by cowan

Alex is mistaken as things stand. See #274.

comment:3 Changed 6 years ago by cowan

UnicodeCowan 15 doesn't fly; it winds up assigning the pname "a
xbb0;b" to the symbol a\xbb0;b as well as a\x5c;xbb0\x3b;b, which is intolerable.

So I withdraw my objections.

comment:4 Changed 6 years ago by cowan

I'm closing this ticket because we no longer have to decide this.

comment:5 Changed 6 years ago by cowan

  • Resolution set to wontfix
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.