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

From: Laurent (laurent.orseau at gmail.com)
Date: Mon Jul 26 10:24:15 EDT 2010

On Mon, Jul 26, 2010 at 16:15, Robby Findler <robby at eecs.northwestern.edu>wrote:

> 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).
>
>
Ok, thank you both for your answers.

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

Posted on the users mailing list.