[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Andy Wingo
Subject: Re: [PATCH 2/5] [mingw]: Have compiled-file-name produce valid names.
Date: Mon, 02 May 2011 23:58:28 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

On Mon 02 May 2011 22:58, address@hidden (Ludovic Courtès) writes:

> Andy Wingo <address@hidden> 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!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]