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 v2] rdelim: Add new procedure `for-line-in-file`. Date: Mon, 16 Dec 2024 13:00:13 +0100 Message-ID: <20241216130013.pQ0C2D00P1dDhme01Q0C65@xavier.telenet-ops.be> References: <0c0bc19c-9b46-4da7-b200-3de0355949fa@disroot.org> <20241216111722.pNHK2D00E1dDhme01NHKfE@andre.telenet-ops.be> <20241216115207.pNs52D00j1dDhme01Ns6nW@baptiste.telenet-ops.be> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_C4B8D835-3889-4C9C-963F-3FB2F33EA16A_" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10673"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Adam Faiz , "guile-devel@gnu.org" , Ricardo Wurmus To: Nala Ginrut Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Mon Dec 16 13:00:50 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 1tN9mL-0002ZR-DL for guile-devel@m.gmane-mx.org; Mon, 16 Dec 2024 13:00:49 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tN9lv-0006OP-2h; Mon, 16 Dec 2024 07:00:23 -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 1tN9lt-0006O1-EJ for guile-devel@gnu.org; Mon, 16 Dec 2024 07:00:21 -0500 Original-Received: from xavier.telenet-ops.be ([2a02:1800:120:4::f00:14]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tN9lq-0005Tn-8N for guile-devel@gnu.org; Mon, 16 Dec 2024 07:00:21 -0500 Original-Received: from [IPv6:2a02:1811:8c0e:ef00:2ca3:f220:8d70:df09] ([IPv6:2a02:1811:8c0e:ef00:2ca3:f220:8d70:df09]) by xavier.telenet-ops.be with cmsmtp id pQ0C2D00P1dDhme01Q0C65; Mon, 16 Dec 2024 13:00:13 +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=1734350413; bh=4N8YMxOQTHyY+54FsnyZ/DaKRb1tZ7KWspmGdQjLWjA=; h=Message-ID:MIME-Version:To:Cc:From:Subject:Date:In-Reply-To: References:Content-Type:From; b=ixE3nE41knkeAMp5mjYb6VWf/fxY3REOR9vuMOsiNpR76bsSEWHarGbYGGQvpmn4+ RJHatYZwDaNRKIVHQuyw8zWuQgYMdfCmAj4y1VfkQuUFTIRy+3bKhycTeQLybeVlu+ gdTQQAKzOn5QtDdNHqNkq0GIP1kmC3W5roW8EuaB9bY1R3J99GxvuH6ykBreOdfCyg /tzeqici8Lwa7703GZD+hCUobU3At6/AbhliUTL09wBIcoYpOECraGaKW/f2KfWhKp 2wjAeZ9aDKgSq4HNzpBTid2n1KjJWet5aYPj80q2R0fscVRoXVCb2quw/XmpxaF4R4 0fArA33lCWHuw== Received-SPF: pass client-ip=2a02:1800:120:4::f00:14; envelope-from=maximedevos@telenet.be; helo=xavier.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:22828 Archived-At: --_C4B8D835-3889-4C9C-963F-3FB2F33EA16A_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" >I'm not going to pursued anyone here, just sharing my opinion about a patc= h for line parsing in a text file.=F0=9F=98=84 Then maybe you should stop it with the faces (=E2=80=9C=F0=9F=98=84=E2=80= =9D) and strawmen. The faces just make things worse. >Yes, some of the parsers don need backwards, but it also doesn't mean othe= rs parsers have priority to occupy a general API.=20 Nowhere did I propose 'letting other parsers have priority to occupy a gene= ral API=E2=80=99. There is no priorisation here, only an option for choice.= Maybe you could even let =E2=80=98read-line=E2=80=99 be the default (with = optional arguments) (depending on where you put the procedure, if it=E2=80= =99s in (ice-9 ports) there would probably be some inconvenient dependency = issue =E2=80=93 I don=E2=80=99t expect this side-remark would work out well= ). >To my experience, a parser author like me prefer to write own parser from = scratch for many reasons, rather than finding ans adapting to a general fun= ction buried deep under document. The specific function is buried deep =E2=80=93 it=E2=80=99s undocumented, y= ou have to read the implementation of (ice-9 rdelim) or things like that to= discover the existence. Nowhere did I propose burying the general function. In fact, I proposed a l= ocation on where to place it, that isn=E2=80=99t at all =E2=80=98deep=E2=80= =99, and surely better than the somewhat obscure (ice-9 rdelim). At the ver= y least, it=E2=80=99s better than being undocumented. Nowhere did I propose removing the special case. The special case could sti= ll be defined in (ice-9 rdelim), but this time implemented in terms of the = general function. Also, the general function is as much as parser as the specific function = =E2=80=93 it just repeats a single parser (read-line in specific case, the = passed procedure in the general case) over the whole port. >Here's my opinion, as a parser writer, I have no interest to use it, but I= can say it still looks beautiful from functional programming perspective. = Beauty is still a value worth to go. I can agree with this. But I don't use= this function. >Of course I speak only for myself as a potential existing user. Nowhere did I say it has to be done because of beauty. The argument was on = usefulness, and (implicitly) on how straightforward it is to generalise it = (making it more useful, can be used by more people, avoids having to implem= ent other variants since the general version already does it). As a parser writer, I have little interest in using the =E2=80=98read-line= =E2=80=99 specific variant. Most of the parsing I do is not based on lines. >So if we can be back to the original topic, a patch for parsing text line = function that can be understand and reviewex easy by most people. I believe= the author's effort and my suggestions are well enough to go. =F0=9F=98=84 There is nothing to go back to. The original patch did not parse lines(*), = it only read them and left the actual parsing to =E2=80=98proc=E2=80=99/=E2= =80=99body=E2=80=99. Also, iterating over lines in a file is a special case= of iterating over more general things and the method of doing the generali= sation is trivial, so this is entirely on topic. It=E2=80=99s the same topi= c, just broader. Also, the general version can also be understood and easil= y reviewed by most people, and I haven=E2=80=99t seen evidence to the contr= ary. I think they _aren=E2=80=99t_ well enough to go, since I haven=E2=80=99t he= ard a good argument yet for _not_ generalising it. (*) I.e., while it technically does parse something (extract line from text= ), it doesn=E2=80=99t parse the line itself (which in many cases will need = to happen), and =E2=80=98recognising a line as a line=E2=80=99 is kind of t= rivial. Best regards, Maxime Devos --_C4B8D835-3889-4C9C-963F-3FB2F33EA16A_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

>I'm not goin= g to pursued anyone here, just sharing my opinion about a patch for line pa= rsing in a text file.😄

= Then maybe you should stop it with the faces (=E2=80=9C😄=E2=80=9D)= and strawmen. The faces just make things worse.<= o:p>

>Yes, some of the parsers don= need backwards, but it also doesn't mean others parsers have priority to o= ccupy a general API.

Nowhere di= d I propose 'letting other parsers have priority to occupy a general API=E2= =80=99. There is no priorisation here, only an option for choice. Maybe you= could even let =E2=80=98read-line=E2=80=99 be the default (with optional a= rguments) (depending on where you put the procedure, if it=E2=80=99s in (ic= e-9 ports) there would probably be some inconvenient dependency issue =E2= =80=93 I don=E2=80=99t expect this side-remark would work out well).

>To my experience, a parser author = like me prefer to write own parser from scratch for many reasons, rather th= an finding ans adapting to a general function buried deep under document.

The specific function is buried d= eep =E2=80=93 it=E2=80=99s undocumented, you have to read the implementatio= n of (ice-9 rdelim) or things like that to discover the existence.

Nowhere did I propose burying the genera= l function. In fact, I proposed a location on where to place it, that isn= =E2=80=99t at all =E2=80=98deep=E2=80=99, and surely better than the somewh= at obscure (ice-9 rdelim). At the very least, it=E2=80=99s better than bein= g undocumented.

Nowhere did I pr= opose removing the special case. The special case could still be defined in= (ice-9 rdelim), but this time implemented in terms of the general function= .

Also, the general function is = as much as parser as the specific function =E2=80=93 it just repeats a sing= le parser (read-line in specific case, the passed procedure in the general = case) over the whole port.

>H= ere's my opinion, as a parser writer, I have no interest to use it, but I c= an say it still looks beautiful from functional programming perspective. Be= auty is still a value worth to go. I can agree with this. But I don't use t= his function.
>Of course I speak only for myself as a potential exist= ing user.

Nowhere did I say it h= as to be done because of beauty. The argument was on usefulness, and (impli= citly) on how straightforward it is to generalise it (making it more useful= , can be used by more people, avoids having to implement other variants sin= ce the general version already does it).

As a parser writer, I have little interest in using the =E2=80=98r= ead-line=E2=80=99 specific variant. Most of the parsing I do is not based o= n lines.

>So if we can be bac= k to the original topic, a patch for parsing text line function that can be= understand and reviewex easy by most people. I believe the author's effort= and my suggestions are well enough to go. 😄

There is nothing to go back to. The original patch d= id not parse lines(*), it only read them and left the actual parsing to =E2= =80=98proc=E2=80=99/=E2=80=99body=E2=80=99. Also, iterating over lines in a= file is a special case of iterating over more general things and the metho= d of doing the generalisation is trivial, so this is entirely on topic. It= =E2=80=99s the same topic, just broader. Also, the general version can also= be understood and easily reviewed by most people, and I haven=E2=80=99t se= en evidence to the contrary.

I t= hink they _aren=E2=80=99t_ well enough to go, since I haven=E2=80=99= t heard a good argument yet for _not_ generalising it.

(*) I.e., while it technically does parse som= ething (extract line from text), it doesn=E2=80=99t parse the line itself (= which in many cases will need to happen), and =E2=80=98recognising a line a= s a line=E2=80=99 is kind of trivial.

Best regards,
Maxime Devos

 

= --_C4B8D835-3889-4C9C-963F-3FB2F33EA16A_--