From: Maxime Devos <maximedevos@telenet.be>
To: Nala Ginrut <nalaginrut@gmail.com>
Cc: Adam Faiz <adam.faiz@disroot.org>,
"guile-devel@gnu.org" <guile-devel@gnu.org>,
Ricardo Wurmus <rekado@elephly.net>
Subject: RE: [PATCH v2] rdelim: Add new procedure `for-line-in-file`.
Date: Mon, 16 Dec 2024 11:52:06 +0100 [thread overview]
Message-ID: <20241216115207.pNs52D00j1dDhme01Ns6nW@baptiste.telenet-ops.be> (raw)
In-Reply-To: <CAPjoZoezJpUazKKbXKgkZVAnhh5gs9F=VfWn=GuZF-M0tmHA+w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2412 bytes --]
>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: 4526 bytes --]
next prev parent reply other threads:[~2024-12-16 10:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-16 6:14 [PATCH v2] rdelim: Add new procedure `for-line-in-file` Adam Faiz
2024-12-16 7:41 ` Nala Ginrut
2024-12-16 10:17 ` Maxime Devos
2024-12-16 10:29 ` Nala Ginrut
2024-12-16 10:52 ` Maxime Devos [this message]
2024-12-16 11:06 ` Nala Ginrut
2024-12-16 12:00 ` Maxime Devos
2024-12-16 12:33 ` Nala Ginrut
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241216115207.pNs52D00j1dDhme01Ns6nW@baptiste.telenet-ops.be \
--to=maximedevos@telenet.be \
--cc=adam.faiz@disroot.org \
--cc=guile-devel@gnu.org \
--cc=nalaginrut@gmail.com \
--cc=rekado@elephly.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).