RE: [PATCH] test-suite: Add tests for `for-rdelim-in-port`-related functions.

[Maxime Devos <maximedevos@telenet.be>]

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


>I think these procedures are handy in common situations. There has been a discussion about generalization. I have the feeling that such generalization either already exists in some SRFI or that one should put some deep thinking into how to represent flexible iteration in Scheme.

If one should put some deep thinking in how to represent flexible iteration, this almost equally applies to ‘for-rdelim-in-port’ too. All that might be different is ‘read-line’ and maybe ‘eof-object?’ being replacable, all other flexibility is independent on whether to generalise or not. Nowhere in this thread have I seen deep thinking about whether for-delimited-in-port should be some stream-like API, fold or reduce and whether there should be some early stop conditions.

About SRFI: the closest thing I found is port-transduce, but in most cases this seems to be an overgeneralisation. If you want some super general thing, you can use the SRFI or implement your own, if all you need is to _iterate_ a (for-object-in-port [reader] [proc] [port]) is much simpler to use and further generalisation (except maybe for eof condition checking) gets in the way.

>I don't think it would be bad to apply Adam's patch, though, or that placing it in (ice-9 rdelim) is unnatural.

Nobody claimed that its location was unnatural, and not being bad doesn’t mean it cannot be improved.

>If no one objects, I will apply the patch in a couple of days with the current naming scheme but modified by the following:

I do.

>+  (let ((port (open-output-file filename)))

Please don’t, a string output port is much cleaner. Avoids all issues with file I/O.

>+  (pass-if "for-line-in-file returns true upon completion"
>+    (for-line-in-file filename
>+                      (lambda (line)
>+                        (set! lines (cons line lines))))
>+    (equal? lines '("line3" "line2" "line1"))))

This ‘true upon completion’ is undocumented.
I don’t see a reason for it to return anything.

Also, you are assuming “\n” is a line delimiter. This is true under Unix according to the documentation. But it doesn’t say anything about non-Unix systems.

Best regards,
Maxime Devos

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