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, 28 Jun 2009 14:28:55 +0100 Message-ID: <87y6rcfpwo.fsf@arudy.ossau.uklinux.net> References: <2bc5f8210905291331u7259389et26e2ad7d88b32f46@mail.gmail.com> <878wkerxar.fsf@arudy.ossau.uklinux.net> <874ouzziqo.fsf@gnu.org> <2bc5f8210906271720u433803a1u5c6a843d3b042288@mail.gmail.com> 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: ger.gmane.org 1246195762 11805 80.91.229.12 (28 Jun 2009 13:29:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 28 Jun 2009 13:29:22 +0000 (UTC) Cc: Ludovic =?iso-8859-1?Q?Court=E8s?= , guile-devel@gnu.org To: Julian Graham Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Jun 28 15:29:15 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 1MKuRX-0001Na-1v for guile-devel@m.gmane.org; Sun, 28 Jun 2009 15:29:15 +0200 Original-Received: from localhost ([127.0.0.1]:38162 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MKuRW-0000Wv-5z for guile-devel@m.gmane.org; Sun, 28 Jun 2009 09:29:14 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MKuRQ-0000Wp-JW for guile-devel@gnu.org; Sun, 28 Jun 2009 09:29:08 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MKuRK-0000Wd-GU for guile-devel@gnu.org; Sun, 28 Jun 2009 09:29:06 -0400 Original-Received: from [199.232.76.173] (port=52593 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MKuRK-0000Wa-AV for guile-devel@gnu.org; Sun, 28 Jun 2009 09:29:02 -0400 Original-Received: from mail3.uklinux.net ([80.84.72.33]:50884) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MKuRG-0008AB-PO; Sun, 28 Jun 2009 09:28:59 -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 DF7F61FA7BA; Sun, 28 Jun 2009 14:28:56 +0100 (BST) Original-Received: from arudy.ossau.uklinux.net (arudy [127.0.0.1]) by arudy (Postfix) with ESMTP id 5C1FB3801F; Sun, 28 Jun 2009 14:28:56 +0100 (BST) In-Reply-To: <2bc5f8210906271720u433803a1u5c6a843d3b042288@mail.gmail.com> (Julian Graham's message of "Sat\, 27 Jun 2009 20\:20\:15 -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:8791 Archived-At: Julian Graham writes: > Hi Guilers, > > With the 1.9 series launched, I wanted to start thinking about R6RS > libraries again, since it would be awesome to have some semblance of > an implementation ready by October. Indeed, yes. I assume the objective here is to allow a Guile program or module to use a portable R6RS library; i.e., specifically, allowing `(use-modules ...)' or `#:use-module (...)' to resolve to an R6RS library. Is that correct? (In addition, I guess we could support `import' directly in contexts other than R6RS library code, i.e. in a top level program or Guile module. But it's not clear to me if that would provide any extra benefit.) >> I think such issues should lead us to have a `:version' option that does >> just what's needed for R6RS, and does not try to do anything smart >> (which could seem to be non-deterministic). =A0We could even go as far as >> discouraging its use in the manual. (I'm assuming this means a :version option to use-modules or #:use-module.) > Alright -- so, to summarize what (I think) has been decided: > > 1. Having more than one version of a module loaded at a time in a > single Guile process / VM is not going to be supported. Yes, at least as far as R6RS library modules are concerned. I've reviewed the relevant discussions on this now and am happy that there's no desire to support multiple live versions of R6RS libraries. I'd prefer not to rule this out, though, for any future versioning that we might add to (define-module ...). Is that feasible? > 2. Mixing load calls that specify version with load calls that do not > should produce deterministic behavior independent of the set of > already-loaded modules. (As described here: [1].) I think that's only possible if we impose some restrictions on how R6RS libraries can be imported... > R6RS says that the mechanism by which implementations match > version-less library references is implementation-dependent, but, in > order to avoid breaking rule number two, I think there's really only > one way to do it: > > The expander has to recursively examine all of the imports, starting > with the top-level program, and keep track of the version specifiers > it finds. That sounds like it requires us to `read' all of the program code, and all imported modules and libraries, before deciding which versions to use. Possible problems with that would be (i) reader macros that have non-trivial side effects; (ii) different possible versions of a library that themselves import different versions of another library, and so on. But on the other hand: - Once we're into R6RS library code, we're OK, because the R6RS layout requires all of the imports to be declared upfront; so we don't need to read the rest of the library code. - In a Guile module, we could specify that versioned imports can only be done by #:use-module expressions as part of the (define-module ...) form, and not support versioned imports by (use-modules ...). Then we'd only have to read the (define-module ...) form. - That just leaves the main program. For that we could invent a new form, like define-module but for the main program, and say that it has to cover all versioned imports. Hmm.. it seems this boils down to saying that we would partially deprecate `(use-modules ...)'. > In order for a program to be consistent with regard to > version, all of the version specifiers for a particular library name > must be prefixes of the most fully-specified version of that library. > If this is true, then once the most fully-specified version is > resolved, wildcard version specifiers can be resolved to that version. > > Unfortunately, depending on the order in which imports are processed, > this mechanism might need to examine the headers of several versions > of a particular library. So it's the most correct, but it may be > non-optimal. > > A lazier but potentially less load-thrashy alternative would be to > have wildcard versions match the latest available version of a library > OR an already-loaded version of that library if present. I can imagine a less clever approach, in which each import is considered as we come to it, and - if there's already a live module with that name - if it's version is compatible with the new import, it's used - if it's version isn't compatible, error - else load a live module as indicated by the new import (somehow - e.g. Andy's symlink approach). Now obviously this could render some programs unstartable. But that could be OK, so long as there was an easy fix for the program author, such as adding (use-modules ((the troublesome module) #:version (the right version))) near the top of the main program. It would be even more OK if we could provide a tool to help work out (the right version). But even with that tool, this less clever approach is a lot less nice than something that Just Works - which is what your suggestion above is. So I'd prefer your suggestion if we can make it work. Regards, Neil