unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Maxime Devos <maximedevos@telenet.be>
To: Adam Faiz <adam.faiz@disroot.org>,
	 "guile-devel@gnu.org" <guile-devel@gnu.org>
Cc: Nala Ginrut <nalaginrut@gmail.com>, Ricardo Wurmus <rekado@elephly.net>
Subject: RE: [PATCH v2] rdelim: Add new procedure `for-line-in-file`.
Date: Mon, 16 Dec 2024 11:17:21 +0100	[thread overview]
Message-ID: <20241216111722.pNHK2D00E1dDhme01NHKfE@andre.telenet-ops.be> (raw)
In-Reply-To: <0c0bc19c-9b46-4da7-b200-3de0355949fa@disroot.org>

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


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

You could then define ‘for-line-in-file’ (for-line-in-port?) as a special case of the more general procedure.

This generalisation also allows for setting ‘handle-delim’, which currently you are not allowing (the user still shouldn’t choose ‘split’ though).

I’m not sure where the general port interface should be, maybe in https://www.gnu.org/software/guile/manual/html_node/Ports.html?

(Slightly more general is to also move eof-object? into an argument, but that seems too much generalisation. OTOH, it allows for ‘split’.)

Also, I’d rather keep opening files out of the procedure – avoids the text encoding issues (mentioned by Nala Ginrut), also convenient for sandboxed environment that don’t want to give access to the file system (or, at least, only use a special file opening procedure that does additional checks), and avoids conflation of file names with files and files with ports. (As written, it’s for file ports, but as implemented, it can be meaningfully used for other ports as well (e.g. networking sockets).) (Also the user might want to set CLOEXEC or other flags, or uncompress input, …)

Also, documentation is missing.

Best regards,
Maxime Devos

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

  parent reply	other threads:[~2024-12-16 10:17 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 [this message]
2024-12-16 10:29   ` Nala Ginrut
2024-12-16 10:52     ` Maxime Devos
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=20241216111722.pNHK2D00E1dDhme01NHKfE@andre.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).