From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: Fixing the slib mess Date: Tue, 23 Oct 2012 14:01:22 -0400 Message-ID: <87y5ixxe31.fsf@tines.lan> References: <87mwze18gu.fsf@tines.lan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1351015317 16029 80.91.229.3 (23 Oct 2012 18:01:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 23 Oct 2012 18:01:57 +0000 (UTC) Cc: guile-devel To: mikael@djurfeldt.com Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Oct 23 20:02:05 2012 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TQine-00014R-SO for guile-devel@m.gmane.org; Tue, 23 Oct 2012 20:01:58 +0200 Original-Received: from localhost ([::1]:41733 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TQinX-0004rP-C8 for guile-devel@m.gmane.org; Tue, 23 Oct 2012 14:01:51 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:37543) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TQinP-0004r1-06 for guile-devel@gnu.org; Tue, 23 Oct 2012 14:01:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TQinK-00030I-Sa for guile-devel@gnu.org; Tue, 23 Oct 2012 14:01:42 -0400 Original-Received: from world.peace.net ([96.39.62.75]:38762) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TQinK-000305-PE for guile-devel@gnu.org; Tue, 23 Oct 2012 14:01:38 -0400 Original-Received: from 209-6-91-212.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.91.212] helo=tines.lan) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TQinC-0002CU-5w; Tue, 23 Oct 2012 14:01:30 -0400 In-Reply-To: (Mikael Djurfeldt's message of "Tue, 23 Oct 2012 10:23:01 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 96.39.62.75 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:15025 Archived-At: Hi Mikael, Mikael Djurfeldt writes: > On Mon, Oct 22, 2012 at 11:51 PM, Mark H Weaver wrote: >> It might be easier to handle this with 'define-syntax-parameter' and >> 'syntax-parameterize'. The idea would be that within slib, 'define' >> would be a syntax parameter. Its default expansion would turn it into >> 'define-public', and also parameterize 'define' to mean 'base:define' >> within the body. If needed, you could also define 'let' and maybe some >> other things to parameterize 'define' within the body. >> >> Another option would be to make 'export' a syntax parameter, and >> parameterize it to a no-op within lexical contours such as 'define' and >> 'let'. >> >> What do you think? > > Correct me if I'm wrong, but doesn't this involve re-defining the > syntax for all forms with bodies (in order to introduce the > syntax-parameterize form)? Yes, I guess it would, although perhaps you could come up with a smaller set of forms that would be sufficient for slib. I'm surprised that slib doesn't have a mechanism for making this job easier for Scheme systems that support modules. It seems like generating the list of exports should not be so difficult. Why doesn't slib use something like 'define-public' to facilitate this? Anyway, here's another idea: after requiring a new slib package, iterate over the entire list of top-level bindings in the slib module and export everything. What do you think? One more thing: ideally, any logic that peeks into Guile internals or is likely to change between Guile versions should be in slib.scm, and anything that's likely to change between slib versions should be in guile.init. Does that make sense? Thanks, Mark