From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Maxim Cournoyer Newsgroups: gmane.lisp.guile.bugs Subject: bug#66046: Relative includes in R7RS define-library seem broken Date: Mon, 06 Nov 2023 13:48:01 -0500 Message-ID: <87h6lylnvi.fsf@gmail.com> References: <6C8500AC-6352-4849-A2C9-2DFEB34F21D5@nonceword.org> <87cywmzqbj.fsf@ngyro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9520"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 66046@debbugs.gnu.org, Daphne Preston-Kendal To: Timothy Sample Original-X-From: bug-guile-bounces+guile-bugs=m.gmane-mx.org@gnu.org Mon Nov 06 19:48:45 2023 Return-path: Envelope-to: guile-bugs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1r04eT-0002GJ-8y for guile-bugs@m.gmane-mx.org; Mon, 06 Nov 2023 19:48:45 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r04eC-000423-11; Mon, 06 Nov 2023 13:48:28 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r04eA-00041i-27 for bug-guile@gnu.org; Mon, 06 Nov 2023 13:48:26 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r04e9-0000Sk-Qp for bug-guile@gnu.org; Mon, 06 Nov 2023 13:48:25 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1r04ek-0007xO-A3 for bug-guile@gnu.org; Mon, 06 Nov 2023 13:49:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Maxim Cournoyer Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Mon, 06 Nov 2023 18:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66046 X-GNU-PR-Package: guile Original-Received: via spool by 66046-submit@debbugs.gnu.org id=B66046.169929653030512 (code B ref 66046); Mon, 06 Nov 2023 18:49:02 +0000 Original-Received: (at 66046) by debbugs.gnu.org; 6 Nov 2023 18:48:50 +0000 Original-Received: from localhost ([127.0.0.1]:40705 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r04eY-0007w0-2P for submit@debbugs.gnu.org; Mon, 06 Nov 2023 13:48:50 -0500 Original-Received: from mail-oi1-x22d.google.com ([2607:f8b0:4864:20::22d]:52234) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r04eV-0007v7-1w for 66046@debbugs.gnu.org; Mon, 06 Nov 2023 13:48:48 -0500 Original-Received: by mail-oi1-x22d.google.com with SMTP id 5614622812f47-3b566ee5f1dso3115499b6e.0 for <66046@debbugs.gnu.org>; Mon, 06 Nov 2023 10:48:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699296483; x=1699901283; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=6f/rlFK45lRZLZe4N8SrCI+x2aCgVaaFdJ14Ima4+/M=; b=Q44UQNnXyzx8HJFxoci+trxGmVfuJsAUNyQ8rea0izRX73sIyFO3RZ7SQAJTUbK8IH +a4IcD6BydW0pw2gMg0aDbe1CXswTGFScRXk8fvS8TiP9DdIUXj1HeW368nCaGz1mWfR uy/6Ah7U2QJ6xUawsyTgHrKBMvTSI+EyXeWCdqX/W+DiqKhdAFo3yY8FAb0DaDyjaUle JO7NfGepg7+row35aSkRR1NM7L2+YzQQPDnma06KgLEALIFIu15LAOvI1b0Mq7M4atYb o/Qbblg3Nrtb+3tVO/XFQV+TklAVrJm2yTqmDdvWqPEyq8C8GQuxIBBY1Mg+28jMCdwq ZCHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699296483; x=1699901283; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=6f/rlFK45lRZLZe4N8SrCI+x2aCgVaaFdJ14Ima4+/M=; b=OrPYXNQaEkyTARqAsnBEume1DNeXKpM7RYjLwArvCF1kDEgBWtM1+xntIaUU10rMRP dKKXTiNlNRCAruVAVXbHPPRYMmQLgXoabCOr2IVJ87bjJg8DGJeNYarp8E0MXjdyWsBq Q9F3HfvCuAZkd6bXZlEzTvJ7sxsT+UwiiCPg7GHFL4DKIuSuoHrubeg1X7D5RHv/dy92 amww/nIuSfkdaKzaZzp/CdxSE1iWHXnlDBGlDLer4cpdHxRPVtAYnx0O4sQcdD4S/PAT +XNrWjW2L/69yDvaUJWx3HWn61FHD6bCv9/yCj+ZaNEPGq9KGWtw7hYkYcf2TYI0KNJK 8zwg== X-Gm-Message-State: AOJu0YxXYCboqPWcP19wn/OGGCbBkeCtSQITlwniKYQSQcZgejywR3AG x2MIIGSoBVhjT0tSixESs+t6m6lkjFQ= X-Google-Smtp-Source: AGHT+IE+esU2w5figwNhSXG600od30y9LQSkfIxPV2UE2cJhcj+OIqRbc/Z+zw9mxgkiSzuA2qBevQ== X-Received: by 2002:a05:6808:4191:b0:3ad:fcd5:3dd6 with SMTP id dj17-20020a056808419100b003adfcd53dd6mr32327037oib.13.1699296483342; Mon, 06 Nov 2023 10:48:03 -0800 (PST) Original-Received: from hurd (dsl-10-130-87.b2b2c.ca. [72.10.130.87]) by smtp.gmail.com with ESMTPSA id l15-20020ad44bcf000000b0065afbb39b2dsm3660559qvw.47.2023.11.06.10.48.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Nov 2023 10:48:02 -0800 (PST) In-Reply-To: <87cywmzqbj.fsf@ngyro.com> (Timothy Sample's message of "Mon, 06 Nov 2023 12:31:28 -0600") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane-mx.org@gnu.org Original-Sender: bug-guile-bounces+guile-bugs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.lisp.guile.bugs:10688 Archived-At: Hi, I also encountered that problem while working on adding new SRFIs to Guile. Timothy Sample writes: > Hi Daphne, > > Daphne Preston-Kendal writes: > >> A standard layout for R7RS libraries is to have an .sld file >> containing the library import and export declarations with a parallel >> .scm file with the same name in the same directory, which the .sld >> file (include ...)s. >> >> [...] >> >> Guile supports looking for .sld files before .scm files if started in >> --r7rs mode. However, in this case, it will not find the .scm file if >> it=E2=80=99s included from the .sld file. > > This is currently causing me problems, too, so I will look into writing > and submitting a patch. > > We are technically following R7RS, which says the lookup strategy is > =E2=80=9Cimplementation-specific=E2=80=9D. However, it goes on to say: = =E2=80=9Cimplementations > are encouraged to search for files in the directory which contains the > including file [...].=E2=80=9D This is perfectly reasonable, and like yo= u say, > part of an established pattern for portable code. That's what Guile does (it attempts to locate the directory of the including source file), but helas, it happens after the file port corresponding to the including file has been relativized, which appears ot strip the prefix of its file name that is in the load path. e.g.: ../module/srfi/srfi-151.scm --> srfi/srfi-151.scm This NEWS entry describes the '%file-port-name-canonicalization' which is used in 'compile-file' and friends: --8<---------------cut here---------------start------------->8--- ** New fluid: `%file-port-name-canonicalization' =20=20=20=20 This fluid parameterizes the file names that are associated with file ports. If %file-port-name-canonicalization is 'absolute, then file names are canonicalized to be absolute paths. If it is 'relative, then the name is canonicalized, but any prefix corresponding to a member of `%load-path' is stripped off. Otherwise the names are passed through unchanged. In addition, the `compile-file' and `compile-and-load' procedures bind %file-port-name-canonicalization to their `#:canonicalization' keyword argument, which defaults to 'relative. In this way, one might compile "../module/ice-9/boot-9.scm", but the path that gets residualized into the .go is "ice-9/boot-9.scm". --8<---------------cut here---------------end--------------->8--- Perhaps there's a better way to avoid baking a bad reference in the .go file without changing fundamental truths about file names, as this is what breaks 'include'. I tried setting the original file name to a parameter in compile-file and compile-file-load, but given 'include' is a syntax, this cannot work. I'll try studying if an alternative to stripping can be used to avoid baking bad file names in .go files. --=20 Thanks, Maxim