Very well… I concede :).

John

> On Dec 28, 2017, at 09:51, Matthew Butterick <m...@mbtype.com> wrote:
> 
> 
>> On Dec 27, 2017, at 10:15 PM, 'John Clements' via Racket Users 
>> <racket-users@googlegroups.com> wrote:
>> 
>> Again, there may be a reason why this is a bad idea, but I don’t think I’ve 
>> heard it yet :).
> 
> Speaking as a user of nonprinting characters, I expect them to, you know, not 
> print ;)
> 
> 
> 
>> People may need to learn this, but when it’s easy to eliminate a source of 
>> errors, it should be eliminated. In this case, it seems not-too-difficult to 
>> display this symbol in a different way, and doing this for the set of 
>> nonprinting characters would appear to represent a reasonable compromise 
>> position.
> 
> Justin's right: this problem is endemic within Unicode. Many codepoints have 
> ambiguously similar visual representations (sometimes by coincidence, 
> sometimes by design). For this reason, in terms of unit tests, you can't (and 
> probably shouldn't) trust your eyes.
> 
> Moreover, isn't it already "not-too-difficult to display this symbol in a 
> different way"? The printed char representation will always be unambiguous:
> 
> #lang racket 
> 
> (define bad-symbol (string->symbol "\uFEFFhello")) 
> (string->list (symbol->string bad-symbol)) ; '(#\uFEFF #\h #\e #\l #\l #\o)
> 
> (define regular-symbol 'hello) 
> (string->list (symbol->string regular-symbol)) ; '(#\h #\e #\l #\l #\o)
> 
> 



-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to