From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Maxime Devos Newsgroups: gmane.lisp.guile.devel Subject: RE: [PATCH] test-suite: Add tests for `for-rdelim-in-port`-related functions. Date: Fri, 20 Dec 2024 10:15:30 +0100 Message-ID: <20241220101533.qxFY2D00e2kJuzj01xFZgG@baptiste.telenet-ops.be> References: <43ad0b39-03cf-b648-3bc9-8c4a064519a8@disroot.org> <8e113f49-c1dc-313b-e65a-24a73c5b887a@disroot.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_CDB56626-8571-4720-95BD-BF8CABA7C9C3_" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16938"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Adam Faiz , guile-devel , Ricardo Wurmus , Tomas Volf <~@wolfsden.cz> To: "mikael@djurfeldt.com" , Nala Ginrut Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Fri Dec 20 10:16:16 2024 Return-path: Envelope-to: guile-devel@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 1tOZ7G-00047h-C4 for guile-devel@m.gmane-mx.org; Fri, 20 Dec 2024 10:16:14 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tOZ6j-0005GU-31; Fri, 20 Dec 2024 04:15:41 -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 1tOZ6h-0005F3-SW for guile-devel@gnu.org; Fri, 20 Dec 2024 04:15:39 -0500 Original-Received: from baptiste.telenet-ops.be ([2a02:1800:120:4::f00:13]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tOZ6f-0000rw-MV for guile-devel@gnu.org; Fri, 20 Dec 2024 04:15:39 -0500 Original-Received: from [IPv6:2a02:1811:8c0e:ef00:f87b:b2ea:4352:aa46] ([IPv6:2a02:1811:8c0e:ef00:f87b:b2ea:4352:aa46]) by baptiste.telenet-ops.be with cmsmtp id qxFY2D00e2kJuzj01xFZgG; Fri, 20 Dec 2024 10:15:33 +0100 Importance: normal X-Priority: 3 In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r24; t=1734686133; bh=fvLQDJrl7wQWhhe6tWy7AfXX4Ap0dMfgintbKt9ZgZM=; h=Message-ID:MIME-Version:To:Cc:From:Subject:Date:In-Reply-To: References:Content-Type:From; b=LJfKabCJIHPyUhR5yNjb80zb8ick7HZpxcTaQDXU7Nfdqn24rYaZ6oCuAFHPBFBNm PuMcOZJQjWM1K9JpylgmM3RhRr0LGJnKyvFwo6rYSSg/+CK9RWFAhEpDP+GNX1xPta rAKLQdXxlS6e2cg8IlKJAFntnpqur4oFiCaRj3/xMadBoNmrWIr7TAs4optnx31ecR IsxoCVlNPQWvvmpLcND6oGz/3LzcCB9Ixx5EPxUma/FPKnplOnGBqB8VN3YQ8T3rrG rYCpJJOrf6676a+XTJQl7eBJpPQtvg+DHlkiEZehL7pH+604K3eKYL1OR3iHeckEZr BDzunJksSe2Xw== Received-SPF: pass client-ip=2a02:1800:120:4::f00:13; envelope-from=maximedevos@telenet.be; helo=baptiste.telenet-ops.be X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.lisp.guile.devel:22840 Archived-At: --_CDB56626-8571-4720-95BD-BF8CABA7C9C3_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" >I think these procedures are handy in common situations. There has been a = discussion about generalization. I have the feeling that such generalizatio= n either already exists in some SRFI or that one should put some deep think= ing into how to represent flexible iteration in Scheme. If one should put some deep thinking in how to represent flexible iteration= , this almost equally applies to =E2=80=98for-rdelim-in-port=E2=80=99 too. = All that might be different is =E2=80=98read-line=E2=80=99 and maybe =E2=80= =98eof-object?=E2=80=99 being replacable, all other flexibility is independ= ent on whether to generalise or not. Nowhere in this thread have I seen dee= p thinking about whether for-delimited-in-port should be some stream-like A= PI, fold or reduce and whether there should be some early stop conditions. About SRFI: the closest thing I found is port-transduce, but in most cases = this seems to be an overgeneralisation. If you want some super general thin= g, you can use the SRFI or implement your own, if all you need is to _itera= te_ a (for-object-in-port [reader] [proc] [port]) is much simpler to use an= d further generalisation (except maybe for eof condition checking) gets in = the way. >I don't think it would be bad to apply Adam's patch, though, or that placi= ng it in (ice-9 rdelim) is unnatural. Nobody claimed that its location was unnatural, and not being bad doesn=E2= =80=99t mean it cannot be improved. >If no one objects, I will apply the patch in a couple of days with the cur= rent naming scheme but modified by the following: I do. >+=C2=A0 (let ((port (open-output-file filename))) Please don=E2=80=99t, a string output port is much cleaner. Avoids all issu= es with file I/O. >+=C2=A0 (pass-if "for-line-in-file returns true upon completion" >+=C2=A0 =C2=A0 (for-line-in-file filename >+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 (lambda (line) >+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 (set! lines (cons line lines)))) >+=C2=A0 =C2=A0 (equal? lines '("line3" "line2" "line1")))) This =E2=80=98true upon completion=E2=80=99 is undocumented. I don=E2=80=99t see a reason for it to return anything. Also, you are assuming =E2=80=9C\n=E2=80=9D is a line delimiter. This is tr= ue under Unix according to the documentation. But it doesn=E2=80=99t say an= ything about non-Unix systems. Best regards, Maxime Devos --_CDB56626-8571-4720-95BD-BF8CABA7C9C3_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

 

>I think these proce= dures are handy in common situations. There has been a discussion about gen= eralization. I have the feeling that such generalization either already exi= sts in some SRFI or that one should put some deep thinking into how to repr= esent flexible iteration in Scheme.

 

If one should put some deep thinking in how to represent fle= xible iteration, this almost equally applies to =E2=80=98for-rdelim-in-port= =E2=80=99 too. All that might be different is =E2=80=98read-line=E2=80=99 a= nd maybe =E2=80=98eof-object?=E2=80=99 being replacable, all other flexibil= ity is independent on whether to generalise or not. Nowhere in this thread = have I seen deep thinking about whether for-delimited-in-port should be som= e stream-like API, fold or reduce and whether there should be some early st= op conditions.

 

About = SRFI: the closest thing I found is port-transduce, but in most cases this s= eems to be an overgeneralisation. If you want some super general thing, you= can use the SRFI or implement your own, if all you need is to _iterate<= /i>_ a (for-object-in-port [reader] [proc] [port]) is much simpler to use a= nd further generalisation (except maybe for eof condition checking) gets in= the way.

 

>I don't= think it would be bad to apply Adam's patch, though, or that placing it in= (ice-9 rdelim) is unnatural.

 

Nobody claimed that its location was unnatural, and not being bad = doesn=E2=80=99t mean it cannot be improved.

 

>If no one objects, I will apply the patch in a= couple of days with the current naming scheme but modified by the followin= g:

 =

I do.

 

>= +  (let ((port (open-output-file filename)))

 

Please don=E2=80=99t, a string output port is = much cleaner. Avoids all issues with file I/O.

 

>+  (pass-if "for-line-in-file retur= ns true upon completion"
>+    (for-line-in-file filen= ame
>+                  =     (lambda (line)
>+          &nb= sp;             (set! lines (cons line lines)= )))
>+    (equal? lines '("line3" "line2&quo= t; "line1"))))

 

This =E2=80=98true upon completion=E2=80=99 is undocumented.=

I don=E2=80=99t see a re= ason for it to return anything.

<= span lang=3DEN-GB> 

Also, you are assuming =E2=80=9C\n=E2=80=9D is a line delimiter.= This is true under Unix according to the documentation. But it doesn=E2=80= =99t say anything about non-Unix systems.

 

Best regards,

Maxime Devos

= --_CDB56626-8571-4720-95BD-BF8CABA7C9C3_--