<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"> >> Since there was no right answer, we decided not to pick either of them.<br> >> The lack of a `read'able form is a weak hint to programmers that they<br> >> need to look closely at the question.<br> ><br> > Thanks, I understand.<br> > Maybe we could distinguish between `read'able and un`read'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're<br> unlikely to run into problems with (7-bit) ascii paths, but I don'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'm stubborn, let'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 "Sorry, this path is supposed to be readable, but that has no meaning on your bizarro filesystem encoding".<br>Then you can focus on most common file-systems and most common `read'able paths, like those using plain 8-bit ascii (I think), and have #<readable-path:...> that can be read on such common systems, otherwise raise a read-error exception (as it does now) on other systems, and also have #<unreadable-path:...> which always raise such an exception.<br> <br>Feature for most is still better than no feature, no? (I'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'able, but I may be mistaken.<br> Maybe I don't see the entire issue.<br><br>Laurent<br>