Re: [PATCH 2/5] [mingw]: Have compiled-file-name produce valid names.

[Noah Lavine]

> 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.

> Ah, I see you are under the delusion that paths are composed of
> characters :)  This is not the case.  To the OS, paths are
> NUL-terminated byte arrays, with some constraints about their
> composition, but which are not necessarily representable as strings.  It
> is nice to offer the ability to convert to and from strings, when that
> is possible, but we must not assume that it is indeed possible.

Thanks! However, I'm also under a somewhat different delusion, which
the Racket docs disagree with. 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'd say that my way of thinking makes more sense if you think that a
filesystem is really just a directed acyclic graph (well, usually
acyclic), and a path is a list of graph nodes. I can't quite see what
the alternative model is, but I have a feeling there's another way of
thinking where Racket's path library makes more sense.

> 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.
>
> Then for a lot of the utilities, we can add (ice-9 paths) or something,
> and implement most of the utility functions in Scheme.

Sounds like a plan.

Noah