<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-05-30 14:15 GMT+05:30 Atticus <span dir="ltr"><<a href="mailto:atticus0@posteo.org" target="_blank">atticus0@posteo.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
> Like, -:eN  (e as in "escape" and "N" as in "nothing", meaning #\U0010ffff).<br>
<br>
</span>Would be really convenient but I can also put the configuration into my<br>
gambcini file.<br>
<span class=""><br>
> Atticus, you're forgetting that the "external representation" discussed<br>
> here regards only the escaping applied in the serialization of objects.<br>
<br>
</span>I dont know if I understand that correctly. I assumed we are discussing<br>
this change:<br>
<br>
with t8 or f8, before:<br>
(write "ü") -> "\374"<br>
(read port) -> "ü"<br>
<br>
with t8 or f8 after change:<br>
(write "ü") -> "ü"<br>
(read port) -> "ü"<br></blockquote><div><br></div><div>Right - what I meant was, remember that, if you desire to do output to the terminal in your application, you should *never* use |write|.</div><div><br></div><div>And, if you would write an application where a user inputs content from the terminal, then you should *never* use |read|.</div><div><br></div><div>|read| and |write| are not IO routines specifically, but object /de/serialization + IO combo routines.</div><div><br></div><div>I.e., |write| is not used for presentation, but to give you an absolute serialized representation in text form of an object's contents, and there human readability is secondary to technical correctness.</div><div><br></div><div>For instance, (write "ü") printing "\374" shows you that the string's character coding is correct (vs. for instance "\303\274" which would show you it's broken). If it prints out "ü", you have no idea.</div><div><br></div><div>Also, a good reason for escaping is that there would even be need of security considerations for not escaping special characters like  <a href="https://en.wikipedia.org/wiki/Unicode_control_characters">https://en.wikipedia.org/wiki/Unicode_control_characters</a> and <a href="https://en.wikipedia.org/wiki/Bi-directional_text#Unicode_bidi_support">https://en.wikipedia.org/wiki/Bi-directional_text#Unicode_bidi_support</a> . If there exists any sensible across-the-board way to handle those except for escaping them, and if there's anything more of the sort than these in particular in Unicode, is beyond my present knowledge.</div><div><br></div><div><br></div><div><br></div><div>The pure IO output routines are |display|,|print|, |read-substring|, |read-char|, and the pure IO intput routines are |read-char|, |read-line|, |read-subu8vector|.</div><div><br></div><div><br></div><div>I.e., with t8 or f8, (display "ü") -> "ü" already and it always did.</div><div><br></div><div><br></div><div>And in the light of this, probably if you want (write "ü") to specifically ouptut "ü" rather than "\374", then maybe/probably you are doing something wrong, as reflected by Marc through what he said in the previous email<br><br></div><div><br></div><div>2015-05-30 0:38 GMT+05:30 Marc Feeley <span dir="ltr"><<a href="mailto:feeley@iro.umontreal.ca" target="_blank">feeley@iro.umontreal.ca</a>></span>: <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">This [escaping of all >=128 chars] allows Scheme strings that are printed to be processed by external tools which only support ASCII.  For example, if you pretty-print to a file a function that contains the string "ü" you will end up with a file containing the sequence of 6 characters "\374" which any editor can edit. In other words, it makes minimal requirements on the features of external tools (not just editors, but email clients if you want to email some Scheme code, shell utilities, C compilers, other Scheme systems, etc).</blockquote></div><div><br></div><div><br></div><div>The only strict usecase I can see of having >=128 characters not escaped by default, is if you have a class full of elementary school kids with another language than English as mother tongue, who find it so confusing during basic programming classes that them typing in 'über is object-serialized as |\374ber|, that you need to do something about it.</div><div><br></div><div><br></div><div>This question of escaping we're discussing, is very similar to the discussion of if it's good practice to use unicode characters in variable names.</div><div><br></div><div>Until now I never saw any project do that.</div><div><br></div></div></div></div>