From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Nala Ginrut Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH v2] rdelim: Add new procedure `for-line-in-file`. Date: Mon, 16 Dec 2024 21:33:32 +0900 Message-ID: References: <0c0bc19c-9b46-4da7-b200-3de0355949fa@disroot.org> <20241216111722.pNHK2D00E1dDhme01NHKfE@andre.telenet-ops.be> <20241216115207.pNs52D00j1dDhme01Ns6nW@baptiste.telenet-ops.be> <20241216130013.pQ0C2D00P1dDhme01Q0C65@xavier.telenet-ops.be> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000001eddb70629626416" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30869"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Adam Faiz , "guile-devel@gnu.org" , Ricardo Wurmus To: Maxime Devos Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Mon Dec 16 13:34:28 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 1tNAIt-0007ti-HM for guile-devel@m.gmane-mx.org; Mon, 16 Dec 2024 13:34:27 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tNAII-0001t6-AK; Mon, 16 Dec 2024 07:33:50 -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 1tNAIF-0001se-7M for guile-devel@gnu.org; Mon, 16 Dec 2024 07:33:47 -0500 Original-Received: from mail-pl1-x62f.google.com ([2607:f8b0:4864:20::62f]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tNAIC-0002Jz-Vh for guile-devel@gnu.org; Mon, 16 Dec 2024 07:33:46 -0500 Original-Received: by mail-pl1-x62f.google.com with SMTP id d9443c01a7336-21634338cfdso47229245ad.2 for ; Mon, 16 Dec 2024 04:33:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734352423; x=1734957223; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=hp6PIlJXs9RBzgSWUXH9tbuAW8cuEVZER+Et8xIBosU=; b=FqRDgxnJHT+LhwAl0LDjpi0OHvYQ/2RqUHrmsjTa2pK2Qb3WQT/8yI+5mcsxpncQ6O HHGFT3k+M+gq9gHUVMO/eWtD3QdwBWqY6qcfCOnK/O3AbRL/e8kmGfwsp7LMrSpLsv7o YYDm0621r320rT68ehLJzNt+zHO5LCbJ4E1YwzgJ4yqvEx9v9eGbh707Jx7YWQIeF0td Dto3ki0IG/P2006ypPFpav3/gDULpKiCio42ZKSmYHu1QmZ94m96kG1K/wWn+zOIpj7C +J+NLtVIKmHqIzdkmH49htIg/Z5sjFaCKkuD2OmC49yOQyquE2zLjk7QmvTUe4ieKvtV 1qbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734352423; x=1734957223; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hp6PIlJXs9RBzgSWUXH9tbuAW8cuEVZER+Et8xIBosU=; b=NjAee15LOTTpaWrQkMP93wk3069ngWyrvppY5t63se26HWrd96q4T9aIFJ0c3kviH2 W3ZYI2hM6oHaGaqm2VPNkc7vIWatjGylIIJzGYNG6r7NE4SsDcWf+yDcwfjt4gj+QOlm 6hdbcvwM98FPMairKKRwlAz+HRXxb0AhYFV1vvzNJP6v+/QPedzz2Ue8EVN3chdN96Ot 5GRqZ7HvbuyeLWxSRL6xZat7Aiz6DIk/Bk8i4hdsHOHNzJqmobDTdLhf8b+og910LU2e qrJEvCXl3cVY5BZ4Ty2J8rwKfGDubGDMpCxFlA9PHBLQvWqOwJtsc7LaL8xV2QpYVuFq t2Ag== X-Forwarded-Encrypted: i=1; AJvYcCVoD6Ymr/1jPong8RI2d9VtJGckSJi1DbUTcH0mElxrSCVZaN9xsPSbeflxVvDKwvHnzLSwYp4KQar8mg==@gnu.org X-Gm-Message-State: AOJu0YyeROdrKouEhIhieN8thAmTyJvZ4goF2C3xnuYcUBR7jusOXLuT KYnHNNeIUf6wH3kAZDpjzKc3hXh3PxiMM6l4RfaDo2MaUO6nyCW3K8dVbgpKXblBnFyMxfs/Sgq VLN9wKzpLpNfBenG2LjeUXKIofXM= X-Gm-Gg: ASbGncsI9c8Lvv5IKZdQFRiu1Jg1xTcdxkryM81TUbGil7DcQSiOOKZvC/djniatOIb 6dIUA4OFiUHafKD2wNNo3HthZY0uxrfIFJFyIfQ== X-Google-Smtp-Source: AGHT+IEtGuWWsn2ymrH9J0tG/V9TI0w1WkF59UIvv5EFTKlHHo3MBsC2h8rfQnooUqmpFf726505NVD1VUmekaqkjoU= X-Received: by 2002:a17:902:d484:b0:215:b190:de6 with SMTP id d9443c01a7336-218929ee8d6mr130878165ad.3.1734352423539; Mon, 16 Dec 2024 04:33:43 -0800 (PST) In-Reply-To: <20241216130013.pQ0C2D00P1dDhme01Q0C65@xavier.telenet-ops.be> Received-SPF: pass client-ip=2607:f8b0:4864:20::62f; envelope-from=nalaginrut@gmail.com; helo=mail-pl1-x62f.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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_NONE=-0.0001, SPF_HELO_NONE=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:22830 Archived-At: --0000000000001eddb70629626416 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The faces icons are my speaking freedom as part of text. I grown up in a dictatorship place, they don=E2=80=99t even let me stop typing faces =F0=9F= =98=81 and no one told me smile faces make things worse. It is interesting to hear it first time in my life. =E2=80=9CWell enough to go=E2=80=9D means there is enough efforts to show a= nd should be respected to stick to the original purpose. And the parser arguments could be in another thread for people who interested. I=E2=80=99m the people who = is interested in the original line delimited reader, which may not be completed enough to be called as a regular parser. It doesn=E2=80=99t mean it=E2=80=99s good enough to be merged, of course. T= he argument around the original topic is always welcome and respect the time of people get involved in the topic. Best regards. On Reiwa 6 Dec 16, Mon at 21:00 Maxime Devos wrote= : > >I'm not going to pursued anyone here, just sharing my opinion about a > patch 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 > others parsers have priority to occupy a general API. > > Nowhere did I propose 'letting other parsers have priority to occupy a > general API=E2=80=99. There is no priorisation here, only an option for c= hoice. > 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 fro= m > scratch for many reasons, rather than finding ans adapting to a general > function buried deep under document. > > The specific function is buried deep =E2=80=93 it=E2=80=99s undocumented,= you 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 > location 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 very least, it=E2=80=99s= better > than being undocumented. > > Nowhere did I propose 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 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 perspectiv= e. > Beauty is still a value worth to go. I can agree with this. But I don't u= se > 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 o= n > usefulness, and (implicitly) on how straightforward it is to generalise i= t > (making it more useful, can be used by more people, avoids having to > implement other variants since the general version already does it). > > As a parser writer, I have little interest in using the =E2=80=98read-lin= e=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 lin= e > function that can be understand and reviewex easy by most people. I belie= ve > 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 generalisation is trivial, so > this is entirely on topic. It=E2=80=99s the same topic, just broader. Als= o, the > general version can also be understood and easily reviewed by most people= , > and I haven=E2=80=99t seen evidence to the contrary. > > I think 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 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 tr= ivial. > > Best regards, > Maxime Devos > > > --0000000000001eddb70629626416 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The faces icons are my speaking freedom as part of text. = I grown up in a dictatorship place, they don=E2=80=99t even let me stop typ= ing faces =F0=9F=98=81 and no one told me smile faces make things worse. It= is interesting to hear it first time in my life.
=E2=80=9CWell enough to go=E2=80=9D means there i= s enough efforts to show and should be respected to stick to the original p= urpose. And the parser arguments could be in another thread for people who = interested. I=E2=80=99m the people who is interested in the original line d= elimited reader, which may not be completed enough to be called as a regula= r parser.

It doesn=E2=80= =99t mean it=E2=80=99s good enough to be merged, of course. The argument ar= ound the original topic is always welcome and respect the time of people ge= t involved in the topic.

Best regards.


On Reiwa 6 Dec 16, Mon at 21= :00 Maxime Devos <maximedevos@= telenet.be> wrote:

>I'm not going = to pursued anyone here, just sharing my opinion about a patch for line pars= ing in a text file.=F0=9F=98=84

Then maybe y= ou should stop it with the faces (=E2=80=9C=F0=9F=98=84=E2=80= =9D) and strawmen. The faces just make things w= orse.

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

Nowhere did I propose 'letting other parsers have priority t= o occupy a general API=E2=80=99. There is no priorisation here, only an opt= ion 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 procedur= e, if it=E2=80=99s in (ice-9 ports) there would probably be some inconvenie= nt 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 function b= uried 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.

No= where did I propose burying the general function. In fact, I proposed a loc= ation 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.<= /p>

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

Also, the general function is as much as parser as the sp= ecific function =E2=80=93 it just repeats a single parser (read-line in spe= cific case, the passed procedure in the general case) over the whole port.<= u>

>Here's my opinion, = as a parser writer, I have no interest to use it, but I can say it still lo= oks beautiful from functional programming perspective. Beauty is still a va= lue worth to go. I can agree with this. But I don't use this function.<= br>>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 implement other variants since the ge= neral 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 li= nes.

>So if we can be ba= ck to the original topic, a patch for parsing text line function that can b= e understand and reviewex easy by most people. I believe the author's e= ffort and my suggestions are well enough to go. =F0=9F=98=84

There is nothing to go back to. The original patch did n= ot 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 fi= le is a special case of iterating over more general things and the method o= f 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 seen = evidence to the contrary.

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

(*) I.e., while it technically does p= arse 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 trivial.

Best regards,
Maxime Devos

=C2=A0

--0000000000001eddb70629626416--