[racket] Reader constructor for #<path:....>

> >> Since there was no right answer, we decided not to pick either of them.
> >> The lack of a `read'able form is a weak hint to programmers that they
> >> need to look closely at the question.
> >
> > Thanks, I understand.
> > Maybe we could distinguish between `read'able and un`read'able paths?
>
> But there are no (guaranteed to be) readable paths because the
> underlying filesystem may use a bizarro encoding. (I think you're
> unlikely to run into problems with (7-bit) ascii paths, but I don't
> think that it is guaranteed.)
>
>
Hmm, that begins to be complex indeed...
But I'm stubborn, let's see where that can get:
I suppose Racket knows what kind of path-encoding exists on the system it
runs on.
Then it can say "Sorry, this path is supposed to be readable, but that has
no meaning on your bizarro filesystem encoding".
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.

Feature for most is still better than no feature, no? (I'm not talking about
the time/energy that that would require to implement)
Probably 90% of the paths could then be `read'able, but I may be mistaken.
Maybe I don't see the entire issue.

Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20100726/17a4e14f/attachment.html>