RE: [PATCH v2] rdelim: Add new procedure `for-line-in-file`.

[Maxime Devos]

>I'm not going to pursued anyone here, just sharing my opinion about a patch 
>for line parsing in a text file.😄
Then maybe you should stop it with the faces (“😄”) 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’. There is no priorisation here, only an option for choice. Maybe you could 
even let ‘read-line’ be the default (with optional arguments) (depending on 
where you put the procedure, if it’s in (ice-9 ports) there would probably be 
some inconvenient dependency issue – I don’t 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 buried deep under document.
The specific function is buried deep – it’s 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’t at all ‘deep’, and surely better than 
the somewhat obscure (ice-9 rdelim). At the very least, it’s 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 – 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 implement 
other variants since the general version already does it).
As a parser writer, I have little interest in using the ‘read-line’ 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. 😄
There is nothing to go back to. The original patch did not parse lines(*), it 
only read them and left the actual parsing to ‘proc’/’body’. 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’s the same topic, just broader. Also, the general version can also be 
understood and easily reviewed by most people, and I haven’t seen evidence to 
the contrary.
I think they _aren’t_ well enough to go, since I haven’t heard a good argument 
yet for _not_ generalising it.
(*) I.e., while it technically does parse something (extract line from text), 
it doesn’t parse the line itself (which in many cases will need to happen), and 
‘recognising a line as a line’ is kind of trivial.
Best regards,
Maxime Devos