>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
