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

On Mon, Jul 26, 2010 at 8:46 AM, Laurent <laurent.orseau at gmail.com> wrote:
>
>> >> 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.

I believe that this amounts to doing option 2 from Matthew's earlier
message. If you know you're not moving to a different filesystem, it
is safe to use path->bytes to marshall things (but not safe in
general).

In any case, I'm still in agreement with Matthew that if it can fail
in mysterious ways, the "weak hint" is the right design choice (altho
it has been a pain for me in the past too).

Robby