Very well… I concede :). John
> On Dec 28, 2017, at 09:51, Matthew Butterick <[email protected]> wrote: > > >> On Dec 27, 2017, at 10:15 PM, 'John Clements' via Racket Users >> <[email protected]> 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
