From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.devel Subject: Re: r6rs libraries, round two Date: Sun, 31 May 2009 00:22:20 +0100 Message-ID: <878wkerxar.fsf@arudy.ossau.uklinux.net> References: <2bc5f8210905291331u7259389et26e2ad7d88b32f46@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1243725761 22879 80.91.229.12 (30 May 2009 23:22:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 30 May 2009 23:22:41 +0000 (UTC) Cc: guile-devel To: Julian Graham Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun May 31 01:22:37 2009 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MAXsn-00022Z-G6 for guile-devel@m.gmane.org; Sun, 31 May 2009 01:22:33 +0200 Original-Received: from localhost ([127.0.0.1]:41619 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MAXsm-0007uu-Ri for guile-devel@m.gmane.org; Sat, 30 May 2009 19:22:32 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MAXsj-0007uX-AO for guile-devel@gnu.org; Sat, 30 May 2009 19:22:29 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MAXsd-0007pu-Sw for guile-devel@gnu.org; Sat, 30 May 2009 19:22:28 -0400 Original-Received: from [199.232.76.173] (port=44481 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MAXsd-0007pr-N5 for guile-devel@gnu.org; Sat, 30 May 2009 19:22:23 -0400 Original-Received: from mail3.uklinux.net ([80.84.72.33]:55882) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MAXsc-0000YE-T9 for guile-devel@gnu.org; Sat, 30 May 2009 19:22:23 -0400 Original-Received: from arudy (host86-152-99-133.range86-152.btcentralplus.com [86.152.99.133]) by mail3.uklinux.net (Postfix) with ESMTP id 768511F6D5C; Sun, 31 May 2009 00:22:21 +0100 (BST) Original-Received: from arudy.ossau.uklinux.net (arudy [127.0.0.1]) by arudy (Postfix) with ESMTP id D80FA38013; Sun, 31 May 2009 00:22:20 +0100 (BST) In-Reply-To: <2bc5f8210905291331u7259389et26e2ad7d88b32f46@mail.gmail.com> (Julian Graham's message of "Fri\, 29 May 2009 16\:31\:52 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.4-2.6 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:8570 Archived-At: Julian Graham writes: > Hi Guilers, > > I'd like to take another stab at getting R6RS library support in, this > time by extending the capabilities of the module system. Here's what > I've got in mind to start with: > > 1. Add an optional `version' field to the module record type Sounds good. > * What's a good format here? We could mirror the requirements of R6RS > here (i.e., (v1 v2 ...) where vx is a whole number) or be more > flexible. Given that your objective is to get R6RS library support in, I'd say just stick to the R6RS format for now. It sounds like it will be fairly easy to extend this in future, if we want to. > For example, Apache Maven (I've got Java on the brain from > being at work) lets you specify the version of your project however > you want, but if you follow the convention its docs set out, it can do > things choose the "latest" version or match a version within a range. > We could do likewise. I can see the attraction of that, since I was experimenting two days ago with adding the SHA-1 of the Git HEAD commit to Guile's micro version - and it didn't work because of some restriction in libguile/version.c (which I didn't investigate). However, I still suggest just basic R6RS for now, because I'm sure we could compatibly add more options later. > 2. Add support for optional version arguments to `use-modules', > `resolve-module', etc. > > * Again, do we want to adhere strictly to R6RS-format version > references here or extend their syntax? As above, I suggest R6RS for now. > * Should we establish some rules for what you get when you don't > specify a version? Yes! The latest available? > Given what we've decided about loading multiple > versions of a library (i.e., you can't) I didn't follow why we decided that, but it feels wrong to me. (It seems to me that Guile should be able to handle loading ((foo) v1) and ((foo) v2) simultaneously as easily as it could handle loading ((foo-v1)) and ((foo-v2)) simultaneously.) I guess I should look up the previous thread, please let me know if you have a convenient reference. > and the existing behavior of > the module-loading functions (you get an already-loaded module if > one's available), conflicts seem possible: > > E.g., if not specifying a version equates to getting the "first > module" in the search path matching the name, then subsequent calls to > those functions that *do* specify a version reference may succeed or > fail based on the result of a prior call. Agree, and agree that this feels wrong. Regards, Neil