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: include can't work Date: Sat, 16 Nov 2013 22:19:01 -0500 Message-ID: <87txfb90m2.fsf@netris.org> References: <1384501247.11916.8.camel@Renee-desktop.suse> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1384658400 16114 80.91.229.3 (17 Nov 2013 03:20:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 17 Nov 2013 03:20:00 +0000 (UTC) Cc: guile-devel@gnu.org To: Nala Ginrut Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Nov 17 04:20:05 2013 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 1Vhsu3-0001ie-7G for guile-devel@m.gmane.org; Sun, 17 Nov 2013 04:20:03 +0100 Original-Received: from localhost ([::1]:37866 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vhsu2-0003dY-J0 for guile-devel@m.gmane.org; Sat, 16 Nov 2013 22:20:02 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56621) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vhstp-0003dO-Ip for guile-devel@gnu.org; Sat, 16 Nov 2013 22:19:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vhsti-0008Cd-1Y for guile-devel@gnu.org; Sat, 16 Nov 2013 22:19:49 -0500 Original-Received: from world.peace.net ([96.39.62.75]:46728) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vhsth-0008CR-Tq for guile-devel@gnu.org; Sat, 16 Nov 2013 22:19:41 -0500 Original-Received: from 209-6-91-212.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.91.212] helo=yeeloong) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1VhstQ-0001Ep-Oy; Sat, 16 Nov 2013 22:19:24 -0500 In-Reply-To: <1384501247.11916.8.camel@Renee-desktop.suse> (Nala Ginrut's message of "Fri, 15 Nov 2013 15:40:47 +0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x 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:16736 Archived-At: Nala Ginrut writes: > I encountered a bug while trying include some file: > --------------------------cut------------------------ > scheme@(guile-user)> (include "aa.scm") > While compiling expression: > ERROR: In procedure string-length: Wrong type argument in position 1 > (expecting string): #f > --------------------------end------------------------ The problem is that when the filename passed to 'include' is a relative pathname, it interprets that pathname relative to the directory of the file containing the 'include' form. In this case, the 'include' form is not in a file at all, so that can't work. Obviously the error message should be improved, but the upshot is this: if you want to use 'include' from the REPL, or from some other port with no associated filename, then you must pass it an absolute pathname. In this case, I suppose the intuitive expectation is that the filename should be interpreted relative to the current working directory of the Guile process, but that is totally different than how 'include' is expected to work in the usual case. Personally, I think it would be a mistake to muddy the semantics of 'include' to support these two very different uses. When you're at the REPL, why not just use 'load' instead? Thoughts? Mark