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

[Nala Ginrut <nalaginrut@gmail.com>]

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

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
>

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