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

[Maxime Devos <maximedevos@telenet.be>]

[-- Attachment #1: Type: text/plain, Size: 3554 bytes --]

>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


[-- Attachment #2: Type: text/html, Size: 5602 bytes --]