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: Re: r6rs libraries, round two Date: Mon, 29 Jun 2009 14:01:19 -0400 Message-ID: <2bc5f8210906291101k728e0e81le78378b48aa495fd@mail.gmail.com> 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: 7bit X-Trace: ger.gmane.org 1246298503 22999 80.91.229.12 (29 Jun 2009 18:01:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Jun 2009 18:01:43 +0000 (UTC) Cc: =?ISO-8859-1?Q?Ludovic_Court=E8s?= , guile-devel@gnu.org To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Jun 29 20:01:36 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 1MLLAd-0007px-NT for guile-devel@m.gmane.org; Mon, 29 Jun 2009 20:01:36 +0200 Original-Received: from localhost ([127.0.0.1]:52431 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MLLAd-0002Y6-9I for guile-devel@m.gmane.org; Mon, 29 Jun 2009 14:01:35 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MLLAX-0002XZ-Ql for guile-devel@gnu.org; Mon, 29 Jun 2009 14:01:29 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MLLAT-0002Vt-Q1 for guile-devel@gnu.org; Mon, 29 Jun 2009 14:01:29 -0400 Original-Received: from [199.232.76.173] (port=38732 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MLLAT-0002Vo-Gn for guile-devel@gnu.org; Mon, 29 Jun 2009 14:01:25 -0400 Original-Received: from mail-ew0-f208.google.com ([209.85.219.208]:58315) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MLLAP-0007JJ-JY; Mon, 29 Jun 2009 14:01:21 -0400 Original-Received: by ewy4 with SMTP id 4so3230584ewy.42 for ; Mon, 29 Jun 2009 11:01:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hSL77WNc47UAAiYKdldkg5Pf1gx+KPXpekmPH9FY1n8=; b=CxrKIcXVj3b34NR+J9cVKnrIKRq47HmnW2wlINs/5/6BnXYiYKVG/4xQTLA0afYEhk 1etEipXj8MJeMm6wD8KiE1DUzYEUkfqSyIupLw4cIPI5mqWF+x1v9nuGk7pNAufbhNsb SD2WACEsq/DVmeBeEm+jITgOyGIT90HXLAubM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=B5MkTqDZ563C8sPBMoTb9Jgfo2mWlRtUM64u3CwW3zvY8S9iEfSWMmCDP3dP08+4cR UjnmwBDLaL7YPlWH3naZylb6eEYdtYdnHGeYaiMz8IlTnqFInCdNQtrc4K+RNTWmxxjy h6ZMfW+G3VS4O4HrzxI7FMRDjkUI3pUtYZMcs= Original-Received: by 10.210.35.10 with SMTP id i10mr2169022ebi.52.1246298479885; Mon, 29 Jun 2009 11:01:19 -0700 (PDT) In-Reply-To: X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:8796 Archived-At: Hi Andy, > Your solution of doing whole-program analysis is very much in the spirit > of R6RS, but it is not in the spirit of Lisp, in my opinion at least. Well, to be fair, it's not whole-program analysis -- as Neil pointed out, we only need to analyze the library and program "headers." But, sure, point taken. > I actually think that doing a whole-program analysis is actively harmful > to the future of Scheme. That's a bit hyperbolic, but it is my opinion. > To me, Lisp is about living, adaptable systems -- not about static > programs. There's no need to let mistakes on the part of the R6RS > editors take us farther down the static path. > > Fortunately, we can comply to the letter of the standard, and not the > spirit. > > Back to your question though, what did you think about my symlink > solution[1]? It's a fine way of handling version-less dependencies, but I don't see how it solves the determinism issue. Let's say my program (or code stream or script or whatever you want to call it) uses libraries from two different authors. Author A trusts his dependencies to remain stable and doesn't use version specifiers in his library references; author B does use them. If my code imports author A's library before author B's, and there's a version clash in their dependencies, what's the take-away for me, the user? Does this mean my code is not well-formed until I reverse the order of my imports? Should I not depend on author A's code at all? On author B's code? Do I have to patch my libraries before importing them? I'm approaching this project in my capacity as a developer with a fair number of dependencies (that I want manage as abstractly as I can) wanting to distribute and test my code on as many platforms as possible. From my point of view, the fact that there hasn't been a unified "module" format for Scheme is pretty frustrating. To the extent that R6RS has some traction among Scheme implementations, its library spec is attractive -- although, I recognize, for political more than technical reasons. At the same time, after months of poring over the minutiae of R6RS, I've come around to the position that it's got some serious defects. Is there some middle ground possible? The intentions of the R6RS editors with regard to libraries and programs being "static" seems pretty clear. And for certain use cases, that may be appropriate. But that doesn't mean that Guile modules need to behave that way. Would people be amenable to having two different ways of working with libraries / programs? I.e., the "mode" that Guile would be in when you ran an R6RS program would be different than when you were in the REPL. Maybe it'd even be a different language in the VM. And we could establish some prescribed mechanisms by which non-R6RS Guile code could use R6RS libraries (with caveats attached), and just not support the converse. I don't know -- this problem seems to get thornier the more we discuss it, but I still think it's worth solving. Sorry if I've missed the point on any of your comments. Regards, Julian