From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Noah Lavine Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH 2/5] [mingw]: Have compiled-file-name produce valid names. Date: Tue, 17 May 2011 12:59:16 -0400 Message-ID: References: <1297784103-18322-1-git-send-email-janneke-list@xs4all.nl> <1297784103-18322-3-git-send-email-janneke-list@xs4all.nl> <87r58gzuoy.fsf@gnu.org> <87vcxsycds.fsf@gnu.org> <87wri7ru80.fsf@netris.org> <87zkn2stsf.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1305652292 3156 80.91.229.12 (17 May 2011 17:11:32 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 17 May 2011 17:11:32 +0000 (UTC) Cc: Andy Wingo , Mark H Weaver , guile-devel@gnu.org To: =?ISO-8859-1?Q?Ludovic_Court=E8s?= Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue May 17 19:11:28 2011 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QMNnr-00009p-HY for guile-devel@m.gmane.org; Tue, 17 May 2011 19:11:27 +0200 Original-Received: from localhost ([::1]:51470 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMNnr-0004Wr-0C for guile-devel@m.gmane.org; Tue, 17 May 2011 13:11:27 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:43093) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMNc7-0007k6-Bc for guile-devel@gnu.org; Tue, 17 May 2011 12:59:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMNc6-00020J-2a for guile-devel@gnu.org; Tue, 17 May 2011 12:59:19 -0400 Original-Received: from mail-vw0-f41.google.com ([209.85.212.41]:55661) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMNc5-00020C-R5; Tue, 17 May 2011 12:59:17 -0400 Original-Received: by vws4 with SMTP id 4so649691vws.0 for ; Tue, 17 May 2011 09:59:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=k1lnnsHn6MP+jvDFdMXYPr/IsrgIJhmaKfMjqfPhqOU=; b=Z0NX0kI2gKI7yprrG9Eaz45lw53SGA8gKfY8kywaQbw1tRij4M33JEAf/kWz2/yN7M zRySkUquwQA+WlbJVLCIJv+R+XUweIHYRQvEdqJ7AjaohJYZQ0QynNGbt/OKb7niSQnr MTHmDwmBRNG3w0At1QjIMP++JVisE2WTQgE3M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=pqW/G4PIxfzUVTgIqhmE1WqSap3wT27Kd3M6dMPgmpkyHIp67MtQmWH7o/Arn9QRcN ROSf4brdIqxRHz/QRCoWWWAynkjt48PxwmI697ls5sVYK+CNAvMUvdaMDPWQExcVbpNU 93pfZWMyDc3DSR+1+ykFcgZcH08gy88i/Qx5M= Original-Received: by 10.52.71.148 with SMTP id v20mr1219642vdu.266.1305651556822; Tue, 17 May 2011 09:59:16 -0700 (PDT) Original-Received: by 10.52.162.225 with HTTP; Tue, 17 May 2011 09:59:16 -0700 (PDT) In-Reply-To: <87zkn2stsf.fsf@gnu.org> X-Google-Sender-Auth: -mcu4FN9fIs0ndp8kL5mHqAztA4 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.212.41 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:12500 Archived-At: Hello all, I've been scanning some file api documentation and wondering what we could do that would translate across platforms reliably. I've been thinking of sort of concentric circles of operations, where the inner circles can easily be supported in a cross-platform way, and the outer ones require more and more hackery. What do you think of the following? Group 1: Treat pathnames as opaque objects that come from outside APIs and can only be used by passing them to APIs. We can support these in a way that will be compatible everywhere. Operations: open file, close file, stat file. In order to be useful, we might also provide a "command-line-argument->file" operation, but probably no reverse operation. Group 2: treat pathnames as vectors of opaque path components Operations: list items in a directory Group 3: now we need to care about encoding Operations: string->path, path->string. This will be much harder than groups 1 and 2. I think group 1 by itself would allow for most command-line programs that people want to write. If you add group 2, you could write find, ls, cat, and probably others. You need group 3 to write grep and a web server. My thought right now is that group 3 is going to have a complex API if we really want to get encodings right. Our goal should be that this complexity doesn't affect group 1 and group 2, which really should have very simple APIs. Now, some thoughts on group 3: Mark is right that paths are basically just strings, even though occasionally they're not. I sort of like the idea of the PEP-383 encoding (making paths strings that can potentially contain unused codepoints, which represent non-character bytes), but would that make path strings break under some Guile string operations? Also, when we convert strings to paths, we need to know what encoding the local filesystem uses. That will usually be UTF-8, but potentially might not be, correct? If we can auto-discover the correct encoding, we might be able to keep all of that in the background and just pretend that we can convert Guile strings to file system paths in a clean way. Noah On Wed, May 4, 2011 at 5:24 AM, Ludovic Court=E8s wrote: > Hi Noah, > > Noah Lavine writes: > >> The reason this strangeness enters is that path strings are actually >> lists (or vectors) encoded as strings. Conceptually, the path >> ~/Desktop/Getting\ a\ Job is the list ("~" "Desktop" "Getting a Job"). >> In this representation, there are no escapes and no separators. It >> always seemed cleaner to me to think about it that way. > > Agreed. > > However, POSIX procedures deal with strings, so you still need to > convert to a string at some point. =A0So I think there are few places > where you could really use anything other than strings to represent file > names=97unless all of libguile is changed to deal with that, which seems > unreasonable to me. > > MIT Scheme=92s API goes this route, but that=92s heavyweight and can hard= ly > be retrofitted in a file-name-as-strings implementation, I think: > . > >> I said this is similar to the (web) module because of all of the >> discussion there of how HTTP encodes data types in text, and how it's >> better to think of a URI as URI type rather than a special string, >> etc. > > Yes. > > Thanks, > Ludo=92. >