On Mon 02 May 2011 22:58, l...@gnu.org (Ludovic Courtès) writes: > Andy Wingo <wi...@pobox.com> writes: > >> Basically I think the plan should be to add scm_from_locale_path, >> scm_from_raw_path, etc to filesys.[ch], and change any >> pathname-accepting procedure in Guile to accept path objects, producing >> them from strings when given strings, and pass the bytevector >> representation to the raw o/s procedures like `open' et al. > > Seems to like a disjoint type “just for Windows” would be overkill, no?
Maybe you're right; hummm! I have added a kind racketeer on Cc; perhaps if he has time, he might have some thoughts in this regard. :-) > Bigloo has just one variable, ‘file-separator’, which is either #\/ or > #\\ [1]. The funny thing is that this doesn't matter at all. Well, I mean that it's valid to construct pathnames with / as the separator on Windows, as / and \ are equivalent there. I still think that we need at least the ability to pass a bytevector as a path name, on GNU systems; and that if we can do so, then any routine that needs to deal with a path name would then need to deal in byte vectors in addition to strings, and at that point perhaps it is indeed useful to have a path library. > Vicinities in SLIB/SCM are similar, with ‘vicinity:suffix?’ > abstracting over slash vs. backslash [2]. I’m not sure how they handle > MS-DOS volume names. I don't think that they do handle volume names; at least, from what I could see in the API description there. Good questions! A -- http://wingolog.org/
