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

[Nala Ginrut <nalaginrut@gmail.com>]

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

I'm not going to pursued anyone here, just sharing my opinion about a patch
for line parsing in a text file.😄

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

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.

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.

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

This doesn't mean I against your idea.

Best regards.

On Mon, Dec 16, 2024, 19:52 Maxime Devos <maximedevos@telenet.be> wrote:

> >You raised this topic from string line reading to more general case. 😄
>
>
>
> Yes.
>
> >If so, the best way could be providing a general function to wrap rdelim
> for for-each-seg-delim, users may pass a delimiter to decide how to delim
> (even for bytevectors), and implement for-line-a-file base on it with
> unicode encoding.
>
> No, this is worse. This limits the procedure to delimiting.
>
> >However, personally I dare to doubt if we really need such general
> function, since general parsing may require looking backwards. This implies
> the char based checking delimiter will be more general.
> If we don't consider this, it's better to just consider strings with
> proper encoding to avoid over engineering.
>
> 'general parsing may require looking backwards’ does not imply ‘don’t need
> such general function’, and ‘don’t need such general function’ doesn’t
> imply ‘such a general function wouldn’t be useful’. Many parsers don’t need
> looking backwards. E.g., see all examples I mentioned in my mail.
>
> Also, you ‘general’ isn’t my ‘general’. Nowhere did I limit the procedure
> to delimiters and character-based things.
>
> For an example on how this could be used: in Scheme-GNUnet, a fiber is
> waiting on messages on some (stream) socket (SOCK_STREAM, not SOCK_DGRAM).
> Each message consists of ‘message type field + packet size field +
> information’. So, the fiber effectively iterates over all messages on the
> stream. The parser first reads the type and size (no looking backwards
> needed), then reads the remaining information and passes this information
> to the type-specific parser, which can now be acted upon.
>
> (IIRC, the control flow is technically a bit different (let loop with
> arguments, to avoid mutation, not that it really matters since there is
> state anyway in the ports), but it could have been implemented like this
> instead.)
>
> Copy of list of examples that don’t need looking backwards:
>
> This is overly specific to reading lines, and reading lines with rdelim.
> If you replace ‘read-line’ by an argument, the procedure becomes more
> general. For example, by passing ‘get-char’ you can act on each character,
> with ‘get-line’ I’m not sure what the difference would be, but apparently
> it’s not ‘read-line’ (?), if you give it a JSON reading+parsing proedure
> you iterate over all JSON objects, with get-u8 you iterate over bytes etc..
>
> Best regards,
> Maxime Devos
>

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