Hi, On Sun 01 May 2011 21:23, Noah Lavine <noah.b.lav...@gmail.com> writes:
>> Yep! Check that racket web page I linked to. You don't have to >> implement all of it, but it should be possible to implement, given the >> path abstraction. > > Okay, I've read it. It doesn't seem very complicated. Should we strive > for API compatibility? I don't see any programs needing it right now, > but maybe there would be in the future if we made them compatible. I don't think we need to be compatible, no. That said it does look pretty good. > I think of a path as a vector of "path elements", each of which > represents a directory except that the last one might represent a > file. I notice the Racket path library makes their path object > distinct from this - you can build a path from a list of path elements > with build-path, and turn a path into a list of path elements with > explode-path, but you can't take an actual path object and manipulate > its components (unless I've missed something). Do you think this is > the right way to think of it? I think that might be what you want sometimes, but it doesn't correspond to the underlying OS path concept. You could build such a thing on top of the byte arrays, but I don't think a vector (or list, ...) is always going to be what you want. I don't know. I would say to stick with byte arrays and strings on the lowest level. Cheers, Andy -- http://wingolog.org/
