From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Marius via "Bug reports for GUILE, GNU's Ubiquitous Extension Language" Newsgroups: gmane.lisp.guile.bugs Subject: bug#72347: Mismatch between documentation and real implementation of list-index Date: Mon, 29 Jul 2024 13:26:44 +0000 Message-ID: <04C1F491-4AE7-46F4-88FC-B20ECF0752EB@disroot.org> References: <18A0D20D-B19C-44AF-8BE7-486CE2DF6844@disroot.org> Reply-To: Marius 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="5941"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 72347@debbugs.gnu.org To: Tomas Volf <~@wolfsden.cz> Original-X-From: bug-guile-bounces+guile-bugs=m.gmane-mx.org@gnu.org Mon Jul 29 15:28:23 2024 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 1sYQQJ-0001Ll-38 for guile-bugs@m.gmane-mx.org; Mon, 29 Jul 2024 15:28:23 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sYQPp-00088b-Ax; Mon, 29 Jul 2024 09:27:53 -0400 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 1sYQPm-0007xs-Cj for bug-guile@gnu.org; Mon, 29 Jul 2024 09:27:50 -0400 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 1sYQPm-000376-4G for bug-guile@gnu.org; Mon, 29 Jul 2024 09:27:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:References:In-Reply-To:From:Date:To:Subject; bh=yicGXj7ToVHgV1YakpcCDkQcusm6hWve4S0UgYRrQe4=; b=WqTegZA0FYQfBIv5adHnDfmDnmREQZE26IuK/4GrCkf3DZOTwHnTVhfiE+C/gjCWZ6txK9oYEhd5xedfTtbjL39gpndoBb7T+K0q5uluQPTH9/bmaFOdaoulhcCb2thrp2XQNjKabqf6n0dF0K4CSV56HDIWSOlDrczNzQB+VU8mc/q/pAQYQ6ny1YkBrd9rG5WPzsajrmpBseaZrCK82jnJaXHDfMYew4VahIDC+6+oTeT5uoRXIoGXRcArLmzEyvX8Frw2pBF7J2K+UlNmPh0nwg4Jk0NzPCqwvdMovyAxdlqV7YoZJy1TrFmyOq4PT2haBvcuuSBSr/qn4JRCUQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sYQPy-0003yH-Ll for bug-guile@gnu.org; Mon, 29 Jul 2024 09:28:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Marius Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Mon, 29 Jul 2024 13:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72347 X-GNU-PR-Package: guile Original-Received: via spool by 72347-submit@debbugs.gnu.org id=B72347.172225962915198 (code B ref 72347); Mon, 29 Jul 2024 13:28:02 +0000 Original-Received: (at 72347) by debbugs.gnu.org; 29 Jul 2024 13:27:09 +0000 Original-Received: from localhost ([127.0.0.1]:45129 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sYQP7-0003x4-3I for submit@debbugs.gnu.org; Mon, 29 Jul 2024 09:27:09 -0400 Original-Received: from layka.disroot.org ([178.21.23.139]:53486) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sYQP2-0003wt-NI for 72347@debbugs.gnu.org; Mon, 29 Jul 2024 09:27:07 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by disroot.org (Postfix) with ESMTP id 5632A411E5; Mon, 29 Jul 2024 15:26:50 +0200 (CEST) X-Virus-Scanned: SPAM Filter at disroot.org Original-Received: from layka.disroot.org ([127.0.0.1]) by localhost (disroot.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Lv5h7g7t3OG; Mon, 29 Jul 2024 15:26:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1722259609; bh=UwY8mkdn2d1rBU97I/myAs5XvVcRyussR/XHdk8AARI=; h=Date:From:To:CC:Subject:In-Reply-To:References; b=S6s7Kmk8QUS2dpwtIb+D6JTuui2hZfdlDxM636jJEsMmt6ZBFovFehZN6WPI8DL3x bRjAG1NsjceGPwITXtPUc5AsOBC3Eo3NjWvxCn27ljFHrCnRqQIntKXDQKDmEUZBd+ DBAlE/KhLDzFP9mXo7i7WshYCXJFJLctvdRVi0vK6uNO2yG0/ISPzVbBHkSSWcYNOU cIbe+c9vSEV4kN00dlmIKN65A9x5/jsVyF4BkBPkm3PNxhjfsSe4WeMHcpQxu1TNbD ouKUE1RNIl7DYJdYJNU9wSmou8ByeaL+U9qRCDtjCG9TOu8A7o+iIbkAWdfAobsxbm vBrJHvFfC8c7g== In-Reply-To: Autocrypt: addr=mariusgr@disroot.org; keydata= mQINBGS1j68BEADba422smkwUlrzTfPMzt5Ac0k/9s6yRpREK/08LK1kMSq0Q+f5We95sQltvoK+ oF9OJEllemyj4HK5Boj3N+IyGzSQwMyneM+BFAOHysU0Tmo0Kpu0Vro0plTV3xakyfi+wEkVwxVq 3Jg9SyxzzNpFk0kOP3vzzZPtlic23vcBIzmOd/EFmxvPJ6QWAPC473neiqrEaIE1hJ6adOVP6vtt 758zzgesSY3yOlBgc/GsOStGkNrNaujnx9vo9tXBDYyh0gqTwZRkUs7QFf1gVCs36V1kbKR8XqIU tpiJ/MrGuYQZ/Yz+MDEvLwv4BLKI/p+yFT+u6ORFYU4iYee1Iu3FKylK3f4OthxeJ3SPlVC6TR5Y O2GaFONesxCWf6phey05MbxwVmYLfLAly9KKsFww2+KFUReycBnx9l3Q8hBScWN7CoTN6rKbaQCM /ob6HRwvPnmXS0t6R1YJEptyW9gf0NkUBRa6dusQA8PwuvLIKmhYJSGwvxIY5+b0mnhuq9Dn8vLi lt0qH9lZVgB56j5mhSrjIbk2k3tBUjxYUj0m0JVRFtOdQbUp7RzZY9jTxzhyRNZ/nQHnbtJiF4VE PqMb5NMKKXfqk4RpilIKLUlsjIrJk6YbuDYn0BirbwICGuG7NXtoG2rcHjAY0yrZlNXbgjKo08Dx ZFwkUpB4rj5Q9wARAQABtDhNYXJpdXMgR3V0acOpcnJleiBSb2NhIChQZXJzb25hbCkgPG1hcml1 c2dyQGRpc3Jvb3Qub3JnPokCTgQTAQoAOBYhBHsR+KwpKiDzXNvVZmB6oLBP/om2BQJkta3B 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:10913 Archived-At: Thank you for the quick response, El 29 de julio de 2024 10:28:00 UTC, Tomas Volf <~@wolfsden=2Ecz> escribi= =C3=B3: >Hello, > >On 2024-07-29 00:34:14 +0000, Marius via Bug reports for GUILE, GNU's Ubi= quitous Extension Language wrote: >> Good evening, >> >> I don't know if this is actually a Guile bug or a documentation bug, bu= t I'm currently learning Guile from the "Guile reference manual" and I've f= ound a mismatch between what the documentation says and what "my" guile doe= s=2E I use Guile 3=2E0=2E9=2E >> >> In my Guile instance (from what I can deduce), last-index is a procedur= e that returns the index of the first element of a list that matches with a= s-expresion=2E >> >> For example: >> >> (list-index '(1 2 3) 3) -> 2 >> (list-index '(height width) 'width) -> 1 >> >> But the documentation says otherwise (): >> >> list-index pred lst1 lst2 =2E=2E=2E >> >> Returns the index of the first set of elements, one from each of lst1 l= st2 =2E=2E=2E, which satisfies pred=2E > >This is documentation for SRFI-1, and that is not available by default (a= t least >not fully), you need to (use-modules) it=2E See below=2E > >> >> >> If I try to run list-index examples (from the documentation) I get an e= rror because it doesn't know how to deal with a procedure as the first argu= ment=2E >> >> >> I'm missing something? I understand that list-index it's defined in SRF= I-1 and maybe a Guile definition is shadowing the SRFI-1 definition=2E But = where is the Guile documentation for this shadowing list-index? In the Guil= e Reference Manual list-index it's only described inside SRFI-1 module=2E > >It seems that Guile provides 2 different list-index procedures=2E One de= fined in >the ice-9/boot-9=2Escm, and one in the srfi-1 module=2E By default the b= oot-9's one >is available=2E > > $ guile -q > GNU Guile 3=2E0=2E9 > Copyright (C) 1995-2023 Free Software Foundation, Inc=2E > > Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'= =2E > This program is free software, and you are welcome to redistribute it > under certain conditions; type `,show c' for details=2E > > Enter `,help' for help=2E > scheme@(guile-user)> list-index > $1 =3D # > scheme@(guile-user)> ,use (srfi srfi-1) > scheme@(guile-user)> list-index > $2 =3D # > >Notice that by importing srfi-1 the list-index changes to the documented = one=2E > >You are right that the "default" list-index indeed does not seem to be >documented=2E It also uses `eq?' for comparisons and does not allow chan= ging >that=2E > >I hope this sheds some light on the problem=2E > >Tomas Yes, that makes sense=2E But this arises another question=2E The Guile man= ual states that some SRFI procedures are native to Guile by default (I imag= ine that that means that they are defined in ice-9/boot=2Escm)=2E This is e= xplained in (section 7=2E5=2E1 in the manual)=2E All of this is in regar= ds documentation: In the manual there are procedures that are both explained in the their AP= I reference section and in the SRFI section=2E When that is the case, it me= ans that the guile default implementation (ice-9) differs from the SRFI (mo= st of the time it's because of the order of arguments)=2E But if the proced= ure it's ONLY present in the SRFI documentation part then it should mean th= at it's implemented following the SRFI standard only, no? The problem is that it seems like there are some procedures (named as in S= RFI) that are implemented by default in guile (via ice-9 module) but aren't= documented in API reference section of the manual=2E Instead they are only= documented in the SRFI section of the manual=2E This is very confusing for= anyone using the Guile reference manual as a "reference manual" because yo= u suddenly get procedures that do not follow the behavior that the manual i= s telling you that should follow=2E Again from the manual it's understood that if a procedure from SRFI is def= ined in the default Guile (ice-9) then it's implemented following the SRFI = standard (cite: "The second reason is that some features defined in SRFIs h= ad been implemented in Guile before the developers started to add SRFI impl= ementations as modules")=2E That's true unless in the API reference section= of the manual the procedure is defined in another way=2E Since list-index is only documented in SRFI section but the default list-i= ndex (ice-9) does not follow the SRFI convention then I still think this is= a bug=2E A documentation bug=2E Adding list-index inside the API documenta= tion (list section) would solve this=2E Then it would be clear that the def= ault list-index implementation differs from the SRFI=2E > >-- >There are only two hard things in Computer Science: >cache invalidation, naming things and off-by-one errors=2E Thank you, Marius