From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Julian Graham Newsgroups: gmane.lisp.guile.devel Subject: r6rs libraries, round two Date: Fri, 29 May 2009 16:31:52 -0400 Message-ID: <2bc5f8210905291331u7259389et26e2ad7d88b32f46@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1243629120 7368 80.91.229.12 (29 May 2009 20:32:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 29 May 2009 20:32:00 +0000 (UTC) To: guile-devel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri May 29 22:31:58 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 1MA8k9-0000rm-Vp for guile-devel@m.gmane.org; Fri, 29 May 2009 22:31:58 +0200 Original-Received: from localhost ([127.0.0.1]:36536 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MA8k9-0006oE-3U for guile-devel@m.gmane.org; Fri, 29 May 2009 16:31:57 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MA8k6-0006nw-KZ for guile-devel@gnu.org; Fri, 29 May 2009 16:31:54 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MA8k5-0006ni-FO for guile-devel@gnu.org; Fri, 29 May 2009 16:31:53 -0400 Original-Received: from [199.232.76.173] (port=57107 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MA8k5-0006nf-An for guile-devel@gnu.org; Fri, 29 May 2009 16:31:53 -0400 Original-Received: from ey-out-1920.google.com ([74.125.78.146]:16091) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MA8k4-00080G-Vq for guile-devel@gnu.org; Fri, 29 May 2009 16:31:53 -0400 Original-Received: by ey-out-1920.google.com with SMTP id 5so107480eyb.24 for ; Fri, 29 May 2009 13:31:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=+gjhcraIQvIV3T8v41NgNcfixdmtVhfmrM3e7stMmkU=; b=llMHNGcLTf98hSJ/wuwrEqluIlQa+ClmOcV8YgFAwdqIOARsQFX2FsVKYwM8mLThkI 8oPqriQQVDlDUvePhHErVqN1AdBe9Wqg+hdVO4tdYeIY6pWNaLUD5gAIxuBRBfr0HosT b1QJss4FI3AfpscPk8RVKH7MVAfNdkWdgwVCE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=bhhMWu1OSi08npcfZOx2JIw6RwmBNhYmDibGyG6qKe2nL7IzMstyEarTpMtnJ6Bqp3 newBUKDgphKInTpHEbEeXb41ccsqxZuUjzEr0IPv26bvpU9tkUirkhwOCrsYHAvyCRyN 6jZzuNiHoeY9IX/tOA5NrRHuGF09lOBSTKveo= Original-Received: by 10.216.29.208 with SMTP id i58mr1047267wea.85.1243629112068; Fri, 29 May 2009 13:31:52 -0700 (PDT) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) 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:8563 Archived-At: 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 * 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. 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. 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? * Should we establish some rules for what you get when you don't specify a version? Given what we've decided about loading multiple versions of a library (i.e., you can't) 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. Regards, Julian