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: Sun, 1 May 2011 15:23:41 -0400 Message-ID: References: <1297784103-18322-1-git-send-email-janneke-list@xs4all.nl> <1297784103-18322-3-git-send-email-janneke-list@xs4all.nl> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1304277831 12134 80.91.229.12 (1 May 2011 19:23:51 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 1 May 2011 19:23:51 +0000 (UTC) Cc: Jan Nieuwenhuizen , guile-devel@gnu.org To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun May 01 21:23:47 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 1QGcF8-000825-Oc for guile-devel@m.gmane.org; Sun, 01 May 2011 21:23:47 +0200 Original-Received: from localhost ([::1]:34460 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QGcF8-0004mG-5W for guile-devel@m.gmane.org; Sun, 01 May 2011 15:23:46 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:37254) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QGcF5-0004m0-CC for guile-devel@gnu.org; Sun, 01 May 2011 15:23:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QGcF4-00028R-GI for guile-devel@gnu.org; Sun, 01 May 2011 15:23:43 -0400 Original-Received: from mail-vw0-f41.google.com ([209.85.212.41]:59926) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QGcF4-00028N-CQ for guile-devel@gnu.org; Sun, 01 May 2011 15:23:42 -0400 Original-Received: by vws4 with SMTP id 4so4954683vws.0 for ; Sun, 01 May 2011 12:23:41 -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=fBsZc0kqQXwlJWuoa+EmlEaDOccdiBMOZiQW3eAWheA=; b=oa/HCa6PE9qMGP+1zoLhxm+LL/xZVQ+GqnBeaDK7BA33aarl38NQe+3LyjZhDJKY/2 2HHNDqedbeiOjtRVq1TjBxqAOV+XP5R1Wq+niBJ7T562TZMxHC031Zgk0EtDbhxbYSQb +NLOlzJPxyv+xmeI3C+9DxrGlazQzFtyc2rHA= 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=Qk0K3u14V7FgmkNYAqJIpn6Vdvpc7c6kMekh1JW+a3Mraom6s9/PUJfXt2+SRZiNmN FHV7jO1JS3YTvunGDyI4btbrHQeDW6MDM5z6wIbev2cLuuGHySLsDd1fvZvp2mvmSyFw J4vTF/3w6wZwpagKGVAnPuC85QHiWqXdup04U= Original-Received: by 10.52.175.103 with SMTP id bz7mr3404425vdc.178.1304277821683; Sun, 01 May 2011 12:23:41 -0700 (PDT) Original-Received: by 10.52.163.5 with HTTP; Sun, 1 May 2011 12:23:41 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: LGva9cZGDwPy5PmvQqLcpxgdp6w 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:12391 Archived-At: > Yep! =A0Check that racket web page I linked to. =A0You 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 :) =A0This is not the case. =A0To the OS, paths are > NUL-terminated byte arrays, with some constraints about their > composition, but which are not necessarily representable as strings. =A0I= t > 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