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

[Nala Ginrut]

You raised this topic from string line reading to more general case. 😄

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.

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.

Best regards.

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

 

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