<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">Brandon Allbery <<a href="mailto:allbery.b@gmail.com" class="">allbery.b@gmail.com</a>>:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 30, 2016 at 9:50 PM, Manuel M T Chakravarty <span dir="ltr" class=""><<a href="mailto:chak@justtesting.org" target="_blank" class="">chak@justtesting.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">Firstly, we have</div><div class=""><br class=""></div><div class=""> isPrint :: Char -> Bool</div><div class=""><br class=""></div><div class="">Are you saying that this type is wrong?</div><div class=""><br class=""></div><div class="">Secondly, how often do you feed the output of ’show’ to ’read’ in another locale versus how often is everybody whose whole life is outside of ASCII (i.e., not anglo-centric people) bothered by this shortcoming? (*)</div><div class=""><br class=""></div><div class="">Moreover, the argument on the ticket was that changing the current implementation would go against the standard. Now that I am saying, the current implementation is not conforming to the standard, the standard suddenly doesn’t seem to matter. Personally, I would say, when we wrote that standard, we knew what we were doing.</div></blockquote></div><br class="">The standard I am aware of is the Report, which deliberately limited the output to the subset which is guaranteed to be usable in all locales. show conforms to this; apparently people want it to *not* conform, and in a way which requires some locale to become the One True Locale.</div></div></div></blockquote><div><br class=""></div><div>Where does it say that in the Report?</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra">isPrint is, as per the language Report, based on what Char is --- which is Unicode codepoints. Using it for output — or for input, for that matter --- gets you into locale issues because nobody anywhere guarantees that Unicode codepoints that pass isPrint are representable in every locale. isPrint is not the place to verify that a character can actually be displayed in the current locale.</div></div></div></blockquote><div><br class=""></div>Yet, this is apparently what the report requires.</div><div><br class=""></div><div>IMHO, it also makes sense. We have seen that either set up (the current or using ’isPrint’) has imperfections. However, getting \<number> is rarely helpful, whereas using ’isPrint’ is going to be helpful most of the time.</div><div><br class=""></div><div>Manuel</div><div><br class=""></div></body></html>