<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
&gt;&gt; Since there was no right answer, we decided not to pick either of them.<br>
&gt;&gt; The lack of a `read&#39;able form is a weak hint to programmers that they<br>
&gt;&gt; need to look closely at the question.<br>
&gt;<br>
&gt; Thanks, I understand.<br>
&gt; Maybe we could distinguish between `read&#39;able and un`read&#39;able paths?<br>
<br>
</div>But there are no (guaranteed to be) readable paths because the<br>
underlying filesystem may use a bizarro encoding. (I think you&#39;re<br>
unlikely to run into problems with (7-bit) ascii paths, but I don&#39;t<br>
think that it is guaranteed.)<br>
<font color="#888888"><br></font></blockquote><div><br>Hmm, that begins to be complex indeed...<br>But I&#39;m stubborn, let&#39;s see where that can get:<br>I suppose Racket knows what kind of path-encoding exists on the system it runs on.<br>

Then it can say &quot;Sorry, this path is supposed to be readable, but that has no meaning on your bizarro filesystem encoding&quot;.<br>Then you can focus on most common file-systems and most common `read&#39;able paths, like those using plain 8-bit ascii (I think), and have #&lt;readable-path:...&gt; that can be read on such common systems, otherwise raise a read-error exception (as it does now) on other systems, and also have #&lt;unreadable-path:...&gt; which always raise such an exception.<br>

<br>Feature for most is still better than no feature, no? (I&#39;m not talking about the time/energy that that would require to implement)<br></div></div>Probably 90% of the paths could then be `read&#39;able, but I may be mistaken.<br>