The faces icons are my speaking freedom as part of text. I grown up in a
dictatorship place, they don’t even let me stop typing faces 😁 and no one
told me smile faces make things worse. It is interesting to hear it first
time in my life.

“Well enough to go” means there is enough efforts to show and should be
respected to stick to the original purpose. And the parser arguments could
be in another thread for people who interested. I’m 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’t mean it’s good enough to be merged, of course. The 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 <maximedevos@telenet.be> wrote:

> >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
>
>
>