[PATCH 1/2] rdelim: Add new procedure `for-rdelim-in-port`.

[PATCH 1/2] rdelim: Add new procedure `for-rdelim-in-port`.

[Adam Faiz]

From 302159fe61d9df526911ead8ea6ad823ad8b0443 Mon Sep 17 00:00:00 2001
From: AwesomeAdam54321 <adam.faiz@disroot.org>
Date: Sun, 15 Dec 2024 23:48:30 +0800
Subject: [PATCH 1/2] rdelim: Add new procedure `for-rdelim-in-port`.

* module/ice-9/rdelim.scm (for-rdelim-in-port): Add it.
(for-delimited-in-port): Define as a specialised `for-rdelim-in-port`.
(for-line-in-file): Define as a specialised `for-delimited-in-port`.

These procedures provide a backbone for parsing, with domain-specific
logic implemented as a separate procedure to be passed as an argument.
---
 module/ice-9/rdelim.scm | 35 ++++++++++++++++++++++++++++++++++-
 1 file changed, 34 insertions(+), 1 deletion(-)

diff --git a/module/ice-9/rdelim.scm b/module/ice-9/rdelim.scm
index d2cd081d7..0bbaaf904 100644
--- a/module/ice-9/rdelim.scm
+++ b/module/ice-9/rdelim.scm
@@ -23,7 +23,10 @@
 ;;; similar to (scsh rdelim) but somewhat incompatible.
 
 (define-module (ice-9 rdelim)
-  #:export (read-line
+  #:export (for-delimited-in-port
+            for-line-in-file
+            for-rdelim-in-port
+            read-line
             read-line!
             read-delimited
             read-delimited!
@@ -206,3 +209,33 @@ characters to read.  By default, there is no limit."
 	      line)
       (else
        (error "unexpected handle-delim value: " handle-delim)))))
+
+(define* (for-rdelim-in-port port proc rdelim-proc
+                             #:key (stop-pred eof-object?))
+  "Call PROC for every (RDELIM-PROC PORT) in PORT until STOP-PRED returns #t.
+RDELIM-PROC has to advance through PORT with every call."
+  (let loop ((rdelim (rdelim-proc port)))
+    (cond ((stop-pred rdelim)
+           (close-port port))
+          (else
+           (proc rdelim)
+           (loop (rdelim-proc port))))))
+
+(define* (for-delimited-in-port port proc
+			        #:key (delims "\n") (handle-delim 'trim))
+  "Call PROC for every delimited line in PORT until the eof-object is reached."
+  (for-rdelim-in-port port proc
+		      (lambda (port)
+			(read-delimited delims port handle-delim))))
+
+(define* (for-line-in-file file proc
+                           #:key (encoding #f) (guess-encoding #f))
+  "Call PROC for every line in FILE until the eof-object is reached.
+FILE must be a filename string.
+
+The line provided to PROC is guaranteed to be a string."
+  (call-with-input-file
+      file
+    (lambda (port)
+      (for-delimited-in-port port proc))
+    #:encoding encoding #:guess-encoding guess-encoding))
-- 
2.41.0

[PATCH 2/2] doc: Add documentation for `for-rdelim-in-port` and, related procedures.

[Adam Faiz]

From b271d059615571d0d50027758494b8dbb5e8625e Mon Sep 17 00:00:00 2001
From: AwesomeAdam54321 <adam.faiz@disroot.org>
Date: Mon, 16 Dec 2024 22:55:41 +0800
Subject: [PATCH 2/2] doc: Add documentation for `for-rdelim-in-port` and
 related procedures.

* doc/ref/api-io.texi (for-rdelim-in-port): Document API.
(for-delimited-in-port): Likewise.
(for-line-in-file): Likewise.
---
 doc/ref/api-io.texi | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/doc/ref/api-io.texi b/doc/ref/api-io.texi
index 79bc9e9d6..23e316c27 100644
--- a/doc/ref/api-io.texi
+++ b/doc/ref/api-io.texi
@@ -984,6 +984,28 @@ used.  This procedure is equivalent to:
 @end lisp
 @end deffn
 
+@deffn {Scheme Procedure} for-rdelim-in-port port proc rdelim-proc @
+        [#:stop-pred=eof-object?]
+For every unit provided by @code{(rdelim-proc port)}, provide
+this unit(rdelim) to @var{proc} to be processed. This will continue throughout
+@var{port} until @var{stop-pred} returns @code{#t}.
+@var{stop-pred} is @code{eof-object?} by default.
+@var{rdelim-proc} has to advance through @var{port} with every call made to it.
+@end deffn
+
+@deffn {Scheme Procedure} for-delimited-in-port port proc @
+        [#:delims=''\n''] [#:handle-delim='trim]
+Call @var{proc} for every line delimited by @var{delims} in @var{port}.
+@end deffn
+
+@deffn {Scheme Procedure} for-line-in-file file proc @
+        [#:encoding=#f] [#:guess-encoding=#f]
+Call @var{proc} for every line in @var{file}.
+@var{file} must be a filename string.
+
+The line provided to @var{proc} is guaranteed to be a string.
+@end deffn
+
 @node Default Ports
 @subsection Default Ports for Input, Output and Errors
 @cindex Default ports
-- 
2.41.0

Re: [PATCH 1/2] rdelim: Add new procedure `for-rdelim-in-port`.

[Nala Ginrut]

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

Thanks for the work!
I didn’t find anything to be picky about yet in the implementation.

Now there are two things could go further.
1. About the port closing, I don’t insist on my previous suggestion right
now. There may be arguments against it by folks. I’m fine with any.

2. To complete a promising patch, it’s better to have test cases. You may
take a look at the existing tests to learn how.

Best regards.

On Reiwa 6 Dec 17, Tue at 0:22 Adam Faiz <adam.faiz@disroot.org> wrote:

> From 302159fe61d9df526911ead8ea6ad823ad8b0443 Mon Sep 17 00:00:00 2001
> From: AwesomeAdam54321 <adam.faiz@disroot.org>
> Date: Sun, 15 Dec 2024 23:48:30 +0800
> Subject: [PATCH 1/2] rdelim: Add new procedure `for-rdelim-in-port`.
>
> * module/ice-9/rdelim.scm (for-rdelim-in-port): Add it.
> (for-delimited-in-port): Define as a specialised `for-rdelim-in-port`.
> (for-line-in-file): Define as a specialised `for-delimited-in-port`.
>
> These procedures provide a backbone for parsing, with domain-specific
> logic implemented as a separate procedure to be passed as an argument.
> ---
>  module/ice-9/rdelim.scm | 35 ++++++++++++++++++++++++++++++++++-
>  1 file changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/module/ice-9/rdelim.scm b/module/ice-9/rdelim.scm
> index d2cd081d7..0bbaaf904 100644
> --- a/module/ice-9/rdelim.scm
> +++ b/module/ice-9/rdelim.scm
> @@ -23,7 +23,10 @@
>  ;;; similar to (scsh rdelim) but somewhat incompatible.
>
>  (define-module (ice-9 rdelim)
> -  #:export (read-line
> +  #:export (for-delimited-in-port
> +            for-line-in-file
> +            for-rdelim-in-port
> +            read-line
>              read-line!
>              read-delimited
>              read-delimited!
> @@ -206,3 +209,33 @@ characters to read.  By default, there is no limit."
>               line)
>        (else
>         (error "unexpected handle-delim value: " handle-delim)))))
> +
> +(define* (for-rdelim-in-port port proc rdelim-proc
> +                             #:key (stop-pred eof-object?))
> +  "Call PROC for every (RDELIM-PROC PORT) in PORT until STOP-PRED returns
> #t.
> +RDELIM-PROC has to advance through PORT with every call."
> +  (let loop ((rdelim (rdelim-proc port)))
> +    (cond ((stop-pred rdelim)
> +           (close-port port))
> +          (else
> +           (proc rdelim)
> +           (loop (rdelim-proc port))))))
> +
> +(define* (for-delimited-in-port port proc
> +                               #:key (delims "\n") (handle-delim 'trim))
> +  "Call PROC for every delimited line in PORT until the eof-object is
> reached."
> +  (for-rdelim-in-port port proc
> +                     (lambda (port)
> +                       (read-delimited delims port handle-delim))))
> +
> +(define* (for-line-in-file file proc
> +                           #:key (encoding #f) (guess-encoding #f))
> +  "Call PROC for every line in FILE until the eof-object is reached.
> +FILE must be a filename string.
> +
> +The line provided to PROC is guaranteed to be a string."
> +  (call-with-input-file
> +      file
> +    (lambda (port)
> +      (for-delimited-in-port port proc))
> +    #:encoding encoding #:guess-encoding guess-encoding))
> --
> 2.41.0
>

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

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

[Adam Faiz]

From 258d20a9665e6f845a167258c33374a00e734885 Mon Sep 17 00:00:00 2001
From: AwesomeAdam54321 <adam.faiz@disroot.org>
Date: Tue, 17 Dec 2024 12:20:52 +0800
Subject: [PATCH] test-suite: Add tests for `for-rdelim-in-port`-related
 functions.

* test-suite/tests/ports.test: Add test cases for
`for-delimited-in-port` and `for-line-in-file`.
---
 test-suite/tests/ports.test | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/test-suite/tests/ports.test b/test-suite/tests/ports.test
index bec5e356c..15d515f1f 100644
--- a/test-suite/tests/ports.test
+++ b/test-suite/tests/ports.test
@@ -2089,6 +2089,28 @@
           (not (string-index (%search-load-path (basename (test-file)))
                              #\\))))))
 
+(let ((lst '())
+      (lines '())
+      (string "line1\nline2\nline3")
+      (filename (test-file)))
+  (call-with-input-string
+      "A\0B\0C"
+    (lambda (port)
+      (pass-if "for-delimited-in-port returns true upon completion"
+        (for-delimited-in-port port
+                               (lambda (entry)
+                                 (set! lst (cons entry lst)))
+                               #:delims "\0")
+        (equal? lst '("C" "B" "A")))))
+  (let ((port (open-output-file filename)))
+    (display string port)
+    (close-port port))
+  (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"))))
+
 (delete-file (test-file))
 
 ;;; Local Variables:
-- 
2.46.0

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

[Nala Ginrut]

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

The preferred activity in your design is more like for-each family, say,
handle the result inside the proc without return result. So maybe it should
be named as for-each-*-in-file, which is more understandable in the first
glance.
Best regards.

On Tue, Dec 17, 2024, 13:31 Adam Faiz <adam.faiz@disroot.org> wrote:

> From 258d20a9665e6f845a167258c33374a00e734885 Mon Sep 17 00:00:00 2001
> From: AwesomeAdam54321 <adam.faiz@disroot.org>
> Date: Tue, 17 Dec 2024 12:20:52 +0800
> Subject: [PATCH] test-suite: Add tests for `for-rdelim-in-port`-related
>  functions.
>
> * test-suite/tests/ports.test: Add test cases for
> `for-delimited-in-port` and `for-line-in-file`.
> ---
>  test-suite/tests/ports.test | 22 ++++++++++++++++++++++
>  1 file changed, 22 insertions(+)
>
> diff --git a/test-suite/tests/ports.test b/test-suite/tests/ports.test
> index bec5e356c..15d515f1f 100644
> --- a/test-suite/tests/ports.test
> +++ b/test-suite/tests/ports.test
> @@ -2089,6 +2089,28 @@
>            (not (string-index (%search-load-path (basename (test-file)))
>                               #\\))))))
>
> +(let ((lst '())
> +      (lines '())
> +      (string "line1\nline2\nline3")
> +      (filename (test-file)))
> +  (call-with-input-string
> +      "A\0B\0C"
> +    (lambda (port)
> +      (pass-if "for-delimited-in-port returns true upon completion"
> +        (for-delimited-in-port port
> +                               (lambda (entry)
> +                                 (set! lst (cons entry lst)))
> +                               #:delims "\0")
> +        (equal? lst '("C" "B" "A")))))
> +  (let ((port (open-output-file filename)))
> +    (display string port)
> +    (close-port port))
> +  (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"))))
> +
>  (delete-file (test-file))
>
>  ;;; Local Variables:
> --
> 2.46.0
>

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

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

[Mikael Djurfeldt]

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

Do others think this as well? To me, the shorter names which Adam selected
seem more palatable. Otherwise they get a bit long.

Den tis 17 dec. 2024 06:11Nala Ginrut <nalaginrut@gmail.com> skrev:

> The preferred activity in your design is more like for-each family, say,
> handle the result inside the proc without return result. So maybe it should
> be named as for-each-*-in-file, which is more understandable in the first
> glance.
> Best regards.
>
> On Tue, Dec 17, 2024, 13:31 Adam Faiz <adam.faiz@disroot.org> wrote:
>
>> From 258d20a9665e6f845a167258c33374a00e734885 Mon Sep 17 00:00:00 2001
>> From: AwesomeAdam54321 <adam.faiz@disroot.org>
>> Date: Tue, 17 Dec 2024 12:20:52 +0800
>> Subject: [PATCH] test-suite: Add tests for `for-rdelim-in-port`-related
>>  functions.
>>
>> * test-suite/tests/ports.test: Add test cases for
>> `for-delimited-in-port` and `for-line-in-file`.
>> ---
>>  test-suite/tests/ports.test | 22 ++++++++++++++++++++++
>>  1 file changed, 22 insertions(+)
>>
>> diff --git a/test-suite/tests/ports.test b/test-suite/tests/ports.test
>> index bec5e356c..15d515f1f 100644
>> --- a/test-suite/tests/ports.test
>> +++ b/test-suite/tests/ports.test
>> @@ -2089,6 +2089,28 @@
>>            (not (string-index (%search-load-path (basename (test-file)))
>>                               #\\))))))
>>
>> +(let ((lst '())
>> +      (lines '())
>> +      (string "line1\nline2\nline3")
>> +      (filename (test-file)))
>> +  (call-with-input-string
>> +      "A\0B\0C"
>> +    (lambda (port)
>> +      (pass-if "for-delimited-in-port returns true upon completion"
>> +        (for-delimited-in-port port
>> +                               (lambda (entry)
>> +                                 (set! lst (cons entry lst)))
>> +                               #:delims "\0")
>> +        (equal? lst '("C" "B" "A")))))
>> +  (let ((port (open-output-file filename)))
>> +    (display string port)
>> +    (close-port port))
>> +  (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"))))
>> +
>>  (delete-file (test-file))
>>
>>  ;;; Local Variables:
>> --
>> 2.46.0
>>
>

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

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

[Mikael Djurfeldt]

[-- Attachment #1: Type: text/plain, Size: 3316 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.

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

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 think "in-port" is redundant and slightly confusing and ambiguous (c.f.
"input") and would replace it with "from-port" to conform with other
procedure names (such as with-input-from-port). On the other hand,
"line-in-file" feels natural despite the existence of with-input-from-file.

On Tue, Dec 17, 2024 at 8:21 AM Mikael Djurfeldt <mikael@djurfeldt.com>
wrote:

> Do others think this as well? To me, the shorter names which Adam selected
> seem more palatable. Otherwise they get a bit long.
>
> Den tis 17 dec. 2024 06:11Nala Ginrut <nalaginrut@gmail.com> skrev:
>
>> The preferred activity in your design is more like for-each family, say,
>> handle the result inside the proc without return result. So maybe it should
>> be named as for-each-*-in-file, which is more understandable in the first
>> glance.
>> Best regards.
>>
>> On Tue, Dec 17, 2024, 13:31 Adam Faiz <adam.faiz@disroot.org> wrote:
>>
>>> From 258d20a9665e6f845a167258c33374a00e734885 Mon Sep 17 00:00:00 2001
>>> From: AwesomeAdam54321 <adam.faiz@disroot.org>
>>> Date: Tue, 17 Dec 2024 12:20:52 +0800
>>> Subject: [PATCH] test-suite: Add tests for `for-rdelim-in-port`-related
>>>  functions.
>>>
>>> * test-suite/tests/ports.test: Add test cases for
>>> `for-delimited-in-port` and `for-line-in-file`.
>>> ---
>>>  test-suite/tests/ports.test | 22 ++++++++++++++++++++++
>>>  1 file changed, 22 insertions(+)
>>>
>>> diff --git a/test-suite/tests/ports.test b/test-suite/tests/ports.test
>>> index bec5e356c..15d515f1f 100644
>>> --- a/test-suite/tests/ports.test
>>> +++ b/test-suite/tests/ports.test
>>> @@ -2089,6 +2089,28 @@
>>>            (not (string-index (%search-load-path (basename (test-file)))
>>>                               #\\))))))
>>>
>>> +(let ((lst '())
>>> +      (lines '())
>>> +      (string "line1\nline2\nline3")
>>> +      (filename (test-file)))
>>> +  (call-with-input-string
>>> +      "A\0B\0C"
>>> +    (lambda (port)
>>> +      (pass-if "for-delimited-in-port returns true upon completion"
>>> +        (for-delimited-in-port port
>>> +                               (lambda (entry)
>>> +                                 (set! lst (cons entry lst)))
>>> +                               #:delims "\0")
>>> +        (equal? lst '("C" "B" "A")))))
>>> +  (let ((port (open-output-file filename)))
>>> +    (display string port)
>>> +    (close-port port))
>>> +  (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"))))
>>> +
>>>  (delete-file (test-file))
>>>
>>>  ;;; Local Variables:
>>> --
>>> 2.46.0
>>>
>>

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

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

[Mikael Djurfeldt]

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

Adam,

Thanks for your patches! Applied now.

Best regards,
Mikael

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

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

[Maxime Devos]

[-- 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 --]

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

[Nala Ginrut]

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

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

RnRs defined read-line to handle different newline properly. My original
idea is to stick to a pure line string reader iterator helper function. So
we can just use read-line to make things simpler. The more general
implementation has to consider this issue out of the standard API.
The proposed generalisation could introduce extra complexity and seems like
over engineering. But as I said, it's still beautiful way to go and I don't
against such an effort. Only if we can spend extra effort to make it work
properly.

Alright, I just elaborate my opinion before in case any misunderstanding of
my previous words. Let's face the problem.

I remember there's way to detect the current platform on the fly, so that
we can test for each supported OS.
How about Guile wrapped (uname), I used it in GNU Artanis to detect the
kernel version. But there's also brief OS info.

I don't think we need to handle Windows case, since nowadays there's WSL
and people like to run GNU things on WSL.

Best regards.

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

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

[Maxime Devos]

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

>>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.
>RnRs defined read-line to handle different newline properly. 

It’s named (ice-9 rdelim) not (rnrs rdelim). Perhaps (ice-9 rdelim) could defer to RnRS, but its documentation currently doesn’t. (If it does defer, it also needs to document what additional newline separators it recognises.)

>My original idea is to stick to a pure line string reader iterator helper function. So we can just use read-line to make things simpler. The more general implementation has to consider this issue out of the standard API.

What issue? You aren’t mentioning any bug in this paragraph, and the feature missing is also covered by the general interface (since it is general). If you are referring to the newline thing: naturally, a general API _wouldn’t_ have to consider what the behaviour of read-line is or should be, since it is up to the caller to decide what behaviour (and hence, which passed procedure) they want. (Except where used in the test cases -- to test the general interface, some specific reader needs to be passed.)

>The proposed generalisation could introduce extra complexity and seems like over engineering. But as I said, it's still beautiful way to go and I don't against such an effort. Only if we can spend extra effort to make it work properly.

What extra complexity, and what extra effort, and what doesn’t work properly about it? The generalisation I proposed:

• does not introduces any complexity – in fact, it’s less, since it does not have to have any knowledge about the ‘settings’ of (ice-9 rdelim)
• is not any more work than the specific application - in fact, it is slightly less, because of the previous point (or about equal since a single (and only a single) extra argument needs to be passed)
• in another sense, there is no extra work, since its implementation is already provided
• in another sense, there is _less_ work, since generalisations are more broadly usable (instead of having to re-implement the thing for each differerent reader(get-u8,read-json,read-line,etc.), now you could use the generalisation for all of them)
• it is a fairly minimal generalisation and this generalisation has various uses, so there is no overengineering.

I keep hearing claims about complexity, over-engineering, extra work, but nobody actually says what the complexity, over-engineering or extra work _is_.

As I’ve written the above kind of response (in less detail) multiple times, yet I keep hearing “but brr complexity/…, and no I’m not telling you what this supposed complexity/… is, and I’m ignoring the evidence(not just disagreeing on some particular points, but _ignoring_)”, by now I have to assume malice  (“proof by assertion” / “… ad nauseam” is a fallacy, and not the kind to make by accident).

Like, in all the time that was spent claiming without evidence that this is overengineered, and claiming that it’s too much work/... while ignoring evidence to the contrary, the zero-additional-effort zero-additional-complexity generalisation could have been integrated in the patch and in Guile, and other things in Guile could perhaps have been improved as well.

If you keep doing this I’m going to shorten future responses to things like ‘This ignores previous evidence to the contrary, and is simply ad nauseum.’, as apparently there is some selective hearing going on so a full response is not worth the effort.

> Alright, I just elaborate my opinion before in case any misunderstanding of my previous words. Let's face the problem.

>I remember there's way to detect the current platform on the fly, so that we can test for each supported OS.
>How about Guile wrapped (uname), I used it in GNU Artanis to detect the kernel version. But there's also brief OS info.

Guile already has knows what system it is on, see e.g. %host-type. There is no need for an additional syscall at runtime.

This seems overly complicated, extra work and overengineerd, compared to simply fully documenting what (ice-9 rdelim) considers to be a line ending. Perhaps it might turn out that the current behaviour is not always desirable, but the first step is _knowing_ what the current behaviour is (the wording sounds like it is platform-dependent, but it doesn’t inspire confidence that all cases were considered, and it is impossible to determine from the documentation _what_ systems it knows about).

>I don't think we need to handle Windows case, since nowadays there's WSL and people like to run GNU things on WSL.

Untrue, see e.g. Lilypond. While WSL is at times convenient, it is not the same as native Windows support. (For example, the file names probably aren’t like C:\Dir\Subdir\…, which is incongruent with what you would expect to be able to use in a Windows application.)

Also, I was thinking on some old Mac(?) systems, where “\r” instead of “\n” is the line feed (I don’t know whether it recognised “\n”, IIRC it doesn’t).

Regards.
Maxime Devos

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

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

[Nala Ginrut]

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

I have no any interest to persuade you, just show my opinion and
suggestions.

And I also have no interest to argue with you about the design, because the
efforts has made according to you suggestions.

I'm trying to follow the idea to not waste any efforts have been made.

My suggestion is to find something function to test under different
platforms. And if you think (uname) is not a good way, you should give a
better solution.

If any possible, follow the path technically, not waste anyone's time,
include me, to discuss things that outside of the patch itself.
Best regards.

On Fri, Dec 20, 2024, 20:51 Maxime Devos <maximedevos@telenet.be> wrote:

> >>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.
>
> >RnRs defined read-line to handle different newline properly.
>
>
>
> It’s named (ice-9 rdelim) not (rnrs rdelim). Perhaps (ice-9 rdelim) could
> defer to RnRS, but its documentation currently doesn’t. (If it does defer,
> it also needs to document what additional newline separators it recognises.)
>
>
>
> >My original idea is to stick to a pure line string reader iterator helper
> function. So we can just use read-line to make things simpler. The more
> general implementation has to consider this issue out of the standard API.
>
>
>
> What issue? You aren’t mentioning any bug in this paragraph, and the
> feature missing is also covered by the general interface (since it is
> general). If you are referring to the newline thing: naturally, a general
> API _*wouldn’t*_ have to consider what the behaviour of read-line is or
> should be, since it is up to the caller to decide what behaviour (and
> hence, which passed procedure) they want. (Except where used in the test
> cases -- to test the general interface, some specific reader needs to be
> passed.)
>
>
>
> >The proposed generalisation could introduce extra complexity and seems
> like over engineering. But as I said, it's still beautiful way to go and I
> don't against such an effort. Only if we can spend extra effort to make
> it work properly.
>
>
>
> What extra complexity, and what extra effort, and what doesn’t work
> properly about it? The generalisation I proposed:
>
>
>
>    - does not introduces any complexity – in fact, it’s less, since it
>    does not have to have any knowledge about the ‘settings’ of (ice-9 rdelim)
>    - is not any more work than the specific application - in fact, it is
>    slightly less, because of the previous point (or about equal since a single
>    (and only a single) extra argument needs to be passed)
>    - in another sense, there is no extra work, since its implementation
>    is already provided
>    - in another sense, there is _*less*_ work, since generalisations are
>    more broadly usable (instead of having to re-implement the thing for each
>    differerent reader(get-u8,read-json,read-line,etc.), now you could use the
>    generalisation for all of them)
>    - it is a fairly minimal generalisation and this generalisation has
>    various uses, so there is no overengineering.
>
>
>
> I keep hearing claims about complexity, over-engineering, extra work, but
> nobody actually says what the complexity, over-engineering or extra work _
> *is*_.
>
>
>
> As I’ve written the above kind of response (in less detail) multiple
> times, yet I keep hearing “but brr complexity/…, and no I’m not telling you
> what this supposed complexity/… is, and I’m ignoring the evidence(not just
> disagreeing on some particular points, but _*ignoring*_)”, by now I have
> to assume malice  (“proof by assertion” / “… ad nauseam” is a fallacy, and
> not the kind to make by accident).
>
>
>
> Like, in all the time that was spent claiming without evidence that this
> is overengineered, and claiming that it’s too much work/... while ignoring
> evidence to the contrary, the zero-additional-effort
> zero-additional-complexity generalisation could have been integrated in the
> patch and in Guile, and other things in Guile could perhaps have been
> improved as well.
>
>
>
> If you keep doing this I’m going to shorten future responses to things
> like ‘This ignores previous evidence to the contrary, and is simply ad
> nauseum.’, as apparently there is some selective hearing going on so a full
> response is not worth the effort.
>
>
>
> > Alright, I just elaborate my opinion before in case any misunderstanding
> of my previous words. Let's face the problem.
>
>
>
> >I remember there's way to detect the current platform on the fly, so that
> we can test for each supported OS.
>
> >How about Guile wrapped (uname), I used it in GNU Artanis to detect the
> kernel version. But there's also brief OS info.
>
>
>
> Guile already has knows what system it is on, see e.g. %host-type. There
> is no need for an additional syscall at runtime.
>
>
>
> This seems overly complicated, extra work and overengineerd, compared to
> simply fully documenting what (ice-9 rdelim) considers to be a line ending.
> Perhaps it might turn out that the current behaviour is not always
> desirable, but the first step is _*knowing*_ what the current behaviour
> is (the wording sounds like it is platform-dependent, but it doesn’t
> inspire confidence that all cases were considered, and it is impossible to
> determine from the documentation _*what*_ systems it knows about).
>
>
>
> >I don't think we need to handle Windows case, since nowadays there's WSL
> and people like to run GNU things on WSL.
>
>
>
> Untrue, see e.g. Lilypond. While WSL is at times convenient, it is not the
> same as native Windows support. (For example, the file names probably
> aren’t like C:\Dir\Subdir\…, which is incongruent with what you would
> expect to be able to use in a Windows application.)
>
>
>
> Also, I was thinking on some old Mac(?) systems, where “\r” instead of
> “\n” is the line feed (I don’t know whether it recognised “\n”, IIRC it
> doesn’t).
>
>
>
> Regards.
>
> Maxime Devos
>

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

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

[Maxime Devos]

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

>I have no any interest to persuade you, just show my opinion and suggestions. 
>And I also have no interest to argue with you about the design, because the efforts has made according to you suggestions. 
This is a problem. Just making a proposal without following up on discussions of its merits / demerits is ok, as long as you don’t push the proposal afterwards. Likewise, mentioning a (claimed) demerits of a counter-proposal is fine even if you don’t follow-up on counter-arguments.
But you did continue pushing the proposal – and not just by making some parts of it more clear, but in the form “actually I do intend to persuade, but I don’t want to think about actual arguments, so I’ll just repeat my claims without addressing the (counter)arguments”. Tacking on “just my opinion” doesn’t make it so, it just makes it look like an attempt for plausible deniability.
Whether you intended to or not, you did present an ad nauseum (+ implausible deniability) argument, so it is an ad nauseum argument.
>I'm trying to follow the idea to not waste any efforts have been made.
(Here you are making an (implicit) strawman again.) Then you are failing. In my proposal there is nothing about wasting effort, and your nauseum argumentation is quite a waste.
>My suggestion is to find something function to test under different platforms. And if you think (uname) is not a good way, you should give a better solution.
I already did. Also, no. Just because you know something is bad, doesn’t mean you know a better solution, so it doesn’t automatically follow that a better solution should be given.
It’s quite frustrating to be asked “You should tell me how to X” right after I did tell you how to X. It’s as-if you want people to not join the ML or have people leave the ML.
>If any possible, follow the path technically, not waste anyone's time, include me, to discuss things that outside of the patch itself.
Going slightly beyond the scope of a patch is not necessarily a waste of time, and on average can same some time (because less patches would be needed), as I probably mentioned earlier in some other words.
Also, "anyone” includes me. You should stop wasting _my_ time by repeating your ad nauseum messages -- whether it’s for just repeating your opinion, or intended for (fallacious) argumentation or persuasion, it is quite ad nauseum.
Regards,
Maxime Devos

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

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

[Nala Ginrut]

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

>
> I already did. Also, no. Just because you know something is bad, doesn’t
> mean you know a better solution, so it doesn’t automatically follow that a
> better solution should be given.
>


You can just say you've no idea about it, such situation doesn't need to
write so many words to explain it to me. I don't really care about if you
know better than me, I need to know how to solve the problem.

If you can briefly reply just like what I quoted, without writing so many
words that I never take a look as you may realized it already. That is the
meaning of "save my time", and of course saving yours.

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

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

[Maxime Devos]

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

>>I already did. Also, no. Just because you know something is bad, doesn’t mean you know a better solution, so it doesn’t automatically follow that a better solution should be given.

>You can just say you've no idea about it,

That’s true (i.e., I can say I have no idea about it), but I have no reason to lie about it, so I won’t. I did have an idea, and I gave the idea to you, as I mentioned in my two previous replies.

> such situation doesn't need to write so many words to explain it to me.

Paraphrasing you: “I don’t really care about whether you are better at efficient writing than me, I just need to get my message across (without information loss)”.

> I don't really care about if you know better than me, I need to know how to solve the problem. 

And I told you how to do so. Also, well, you are the one that (multiple times, IIRC) brought up “who knows better than who”, not me.

>If you can briefly reply just like what I quoted, without writing so many words that I never take a look as you may realized it already. That is the meaning of "save my time", and of course saving yours.

No. Misreading another persons words is not the meaning of “save my(/your) time”. (_Not_ reading another’s words can have the same kind of effects as misreading, so I’m including it in “misreading” for purposes of the previous sentence.)

Not reading before answering wastes _everyone_ time. Reading is much faster than writing (almost instantaneous compared to the other activities), so in case of a limited audience(*), clarity of writing and speed of writing becomes a bit more important than how fast it is to read. All those words I write, are there for a reason: to answer the questions, to respond to other remark, and to be precise about it. Also, this writing style is natural to me, so doing it different would cost me time. Compactening those words into less words might be possible, but takes a lot of time(**) and can easily lose relevant information, so unless it’s for a wide audience(*), I don’t, which saves time.

(*) various exceptions apply
(**) like, writing this mail took my about 45 minutes, and that’s without any compactening. Yet, it can be fully read in less than a minute. And even if I were to beforehand select parts to only those part, this selection process still needs time, and those other parts would remain unanswered.

Also, when I (of my own volition, and in absence of external obligations competing for time) _choose_ to spend some extra time on writing beyond necessity, then it’s up to myself whether to consider this extra effort ‘waste’ or not, or perhaps even ‘valuable for its own sake’.

Best regards,
Maxime Devos

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

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

[Nala Ginrut]

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

> >You can just say you've no idea about it,
>
> That’s true (i.e., I can say I have no idea about it), but I have no
> reason to lie about it, so I won’t. I did have an idea, and I gave the idea
> to you, as I mentioned in my two previous replies.
>
>
Thanks! This sentence saves a lot of time.

Here are the "back to the track" reply for folks in this thread.

So the situation is more clear now. The newline in various OS need to
respectively tested. And my idea is to check OS via (uname) in test cases.
Now that it's in tests, I think we don't have to talk much about the
efficiency issue for this specific case.

Welcome to comment this proposal.

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

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

[Maxime Devos]

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

>Here are the "back to the track" reply for folks in this thread.
>
>So the situation is more clear now. The newline in various OS need to respectively tested. And my idea is to check OS via (uname) in test cases.
>Now that it's in tests, I think we don't have to talk much about the efficiency issue for this specific case.

No. See what I wrote previously about the subject, and note that most of it is independent of whether it’s for testing or not. As you previously said you intentionally did not read (parts of) the messages, I’m not going to repeat it for you.

In addition: why not simply _read_ the implementation of (ice-9 rdelim) to see what platform-detecting mechanism it uses (if any) and reuse that, instead of reinventing the wheel? Sounds like it would save effort and time, which you seem particularly interested in, and claimed effort/time is one of your own arguments against generalisation.

Also, it doesn’t need to be tested, since read-line is not what’s being added or modified here. (Tests for that may be good, but that’s off-topic, which you are rather against, and is your most coherent argument against generalisation.) Rather, either the used newline in the test needs to be adjusted per-platform, or the documentation of read-line needs to be adjusted to that \n is always a newline.

Also, it’s also not a proper “back to the track” reply, since it ignores the ‘generalisation’ component of the track.

Regards,
Maxime Devos

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

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

[Nala Ginrut]

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

As I said, I didn't against any of your opinions. But I have my freedom to
comment on what I think important.

So I made my proposal accordingly to the specific issue as you pointed out.
This may not be accepted by you, but that's your freedom to share your mind
further. And I unnecessarily need to respond to it unless I think it's
worth. In case you thought people may misunderstand you, I also care if the
image in your mind is not what showed in your mind. I keep my comments
before anyone show the related code as you described.

But let me emphasize it, this doesn't mean anyone is forced to reimplement
the code. At least I accept the current implementation. Don't forget, these
patches included your efforts either, and I respect that part too, in the
name of the code. Personally, I would like to comment on the existing code
rather than mind.

This thread is not only you and me. Many others are reading it. You don't
need to persuade me. You just claim your mind directly, and wait for folks
agree it, or at least part of it.
Best regards.

On Fri, Dec 20, 2024, 23:18 Maxime Devos <maximedevos@telenet.be> wrote:

> >Here are the "back to the track" reply for folks in this thread.
>
> >
>
> >So the situation is more clear now. The newline in various OS need to
> respectively tested. And my idea is to check OS via (uname) in test cases.
>
> >Now that it's in tests, I think we don't have to talk much about the
> efficiency issue for this specific case.
>
>
>
> No. See what I wrote previously about the subject, and note that most of
> it is independent of whether it’s for testing or not. As you previously
> said you intentionally did not read (parts of) the messages, I’m not going
> to repeat it for you.
>
>
>
> In addition: why not simply _*read*_ the implementation of (ice-9 rdelim)
> to see what platform-detecting mechanism it uses (if any) and reuse that,
> instead of reinventing the wheel? Sounds like it would save effort and
> time, which you seem particularly interested in, and claimed effort/time is
> one of your own arguments against generalisation.
>
>
>
> Also, it doesn’t need to be tested, since read-line is not what’s being
> added or modified here. (Tests for that may be good, but that’s off-topic,
> which you are rather against, and is your most coherent argument against
> generalisation.) Rather, either the used newline in the test needs to be
> adjusted per-platform, or the documentation of read-line needs to be
> adjusted to that \n is always a newline.
>
>
>
> Also, it’s also not a proper “back to the track” reply, since it ignores
> the ‘generalisation’ component of the track.
>
>
>
> Regards,
>
> Maxime Devos
>

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

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

[Nala Ginrut]

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

"I also care if the image in your mind is not what showed in your mind"

should be "showed in my mind"
Best regards.

On Fri, Dec 20, 2024, 23:30 Nala Ginrut <nalaginrut@gmail.com> wrote:

> As I said, I didn't against any of your opinions. But I have my freedom to
> comment on what I think important.
>
> So I made my proposal accordingly to the specific issue as you pointed
> out. This may not be accepted by you, but that's your freedom to share your
> mind further. And I unnecessarily need to respond to it unless I think it's
> worth. In case you thought people may misunderstand you, I also care if the
> image in your mind is not what showed in your mind. I keep my comments
> before anyone show the related code as you described.
>
> But let me emphasize it, this doesn't mean anyone is forced to reimplement
> the code. At least I accept the current implementation. Don't forget, these
> patches included your efforts either, and I respect that part too, in the
> name of the code. Personally, I would like to comment on the existing code
> rather than mind.
>
> This thread is not only you and me. Many others are reading it. You don't
> need to persuade me. You just claim your mind directly, and wait for folks
> agree it, or at least part of it.
> Best regards.
>
> On Fri, Dec 20, 2024, 23:18 Maxime Devos <maximedevos@telenet.be> wrote:
>
>> >Here are the "back to the track" reply for folks in this thread.
>>
>> >
>>
>> >So the situation is more clear now. The newline in various OS need to
>> respectively tested. And my idea is to check OS via (uname) in test cases.
>>
>> >Now that it's in tests, I think we don't have to talk much about the
>> efficiency issue for this specific case.
>>
>>
>>
>> No. See what I wrote previously about the subject, and note that most of
>> it is independent of whether it’s for testing or not. As you previously
>> said you intentionally did not read (parts of) the messages, I’m not going
>> to repeat it for you.
>>
>>
>>
>> In addition: why not simply _*read*_ the implementation of (ice-9
>> rdelim) to see what platform-detecting mechanism it uses (if any) and reuse
>> that, instead of reinventing the wheel? Sounds like it would save effort
>> and time, which you seem particularly interested in, and claimed
>> effort/time is one of your own arguments against generalisation.
>>
>>
>>
>> Also, it doesn’t need to be tested, since read-line is not what’s being
>> added or modified here. (Tests for that may be good, but that’s off-topic,
>> which you are rather against, and is your most coherent argument against
>> generalisation.) Rather, either the used newline in the test needs to be
>> adjusted per-platform, or the documentation of read-line needs to be
>> adjusted to that \n is always a newline.
>>
>>
>>
>> Also, it’s also not a proper “back to the track” reply, since it ignores
>> the ‘generalisation’ component of the track.
>>
>>
>>
>> Regards,
>>
>> Maxime Devos
>>
>

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

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

[Maxime Devos]

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

Can you stop it with the repetitive claims of “this is just my proposal, I have freedom to state it, you don’t need to persuade me, etc.”? I’ve heard you the first, dunno, 5 or so times. Except for the “just” qualifier, I did not disagree anywhere. For why you shouldn’t do those repetitive claims: see my previous e-mails which you keep misinterpreting, and see how misleadingly you are framing those repetivive claims.

As I’ve asked similarly previously without any apparent success:
First time you do it again, I add you to my e-mail software’s blocklist (as soon as I figure out how too) (+ a comment to other people that I added you to the blocklist, so they know when it I respond to theirs remarks but not yours, it does not imply anything about yours (neither positive nor negative)).

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

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

[Nala Ginrut]

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

I don't talk nonsense with you, and I didn't against your opinions even for
your nonsense.

The only thing I care is that, are you ready to back to the coding part,
and show your code than cheap talking, now?
Best regards.

On Fri, Dec 20, 2024, 23:47 Maxime Devos <maximedevos@telenet.be> wrote:

> Can you stop it with the repetitive claims of “this is just my proposal, I
> have freedom to state it, you don’t need to persuade me, etc.”? I’ve heard
> you the first, dunno, 5 or so times. Except for the “just” qualifier, I did
> not disagree anywhere. For why you shouldn’t do those repetitive claims:
> see my previous e-mails which you keep misinterpreting, and see how
> misleadingly you are framing those repetivive claims.
>
>
>
> As I’ve asked similarly previously without any apparent success:
>
> First time you do it again, I add you to my e-mail software’s blocklist
> (as soon as I figure out how too) (+ a comment to other people that I added
> you to the blocklist, so they know when it I respond to theirs remarks but
> not yours, it does not imply anything about yours (neither positive nor
> negative)).
>

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

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

[Maxime Devos]

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

>I don't talk nonsense with you, and I didn't against your opinions even for your nonsense.
>The only thing I care is that, are you ready to back to the coding part, and show your code than cheap talking, now?
This isn’t exactly what I wrote about in my last e-mail, but it’s a similar kind of nonsense I don’t want to deal with either (the generalisation Is trivial so nothing needs to be shown, what you are claiming is different from what you are doing, and I did no cheap talking), so consider yourself added to the blocklist.
Bye,
Maxime Devos

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

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

[Nala Ginrut]

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

You typed so many patches unrelated thing that help me thought your time is
cheap. It is cheap talking to me.

Personally I'm so curious why you think blocklist is a weapon to threat
people. But anyway, I don't against your interesting opinions, since you
are always interesting.

Anyway, I would like to back to the topic. You are free to join. I won't
threat you with a blocklist. 😄
Best regards.

On Sat, Dec 21, 2024, 00:07 Maxime Devos <maximedevos@telenet.be> wrote:

> >I don't talk nonsense with you, and I didn't against your opinions even
> for your nonsense.
>
> >The only thing I care is that, are you ready to back to the coding part,
> and show your code than cheap talking, now?
>
> This isn’t exactly what I wrote about in my last e-mail, but it’s a
> similar kind of nonsense I don’t want to deal with either (the
> generalisation Is trivial so nothing needs to be shown, what you are
> claiming is different from what you are doing, and I did no cheap talking),
> so consider yourself added to the blocklist.
>
> Bye,
> Maxime Devos
>

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

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

[Maxime Devos]

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

> Thanks for your patches! Applied now.

Regardless of the question whether to generalise, there was also the thing about the test testing for returning #true even though this behaviour isn’t documented anywhere. Also, there was the thing about needing to verify whether (ice-9 rdelim) always recognises \n or whether that’s Unix-dependent (if the latter, (ice-9 rdelim) or the test needs to be adjusted, and in case of the former the documentation needs to be adjusted).

Best regards,
Mikael


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

Re: [PATCH] test-suite: Add tests for `for-rdelim-in-port`-relatedfunctions.

[Mikael Djurfeldt]

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

Hi Maxime,

On Fri, Dec 20, 2024 at 4:15 PM Maxime Devos <maximedevos@telenet.be> wrote:

> > Thanks for your patches! Applied now.
>
>
>
> Regardless of the question whether to generalise, there was also the thing
> about the test testing for returning #true even though this behaviour isn’t
> documented anywhere.
>

Maybe there's a misunderstanding here: What Adams test does is to compile a
list of results. What he refers to is the #t returned by the test checking
that the compiled results are correct. I changed that wording. Otherwise, I
think the test is fine (on a Unix system).


> Also, there was the thing about needing to verify whether (ice-9 rdelim)
> always recognises \n or whether that’s Unix-dependent (if the latter,
> (ice-9 rdelim) or the test needs to be adjusted, and in case of the former
> the documentation needs to be adjusted).
>

You're right that the behavior is Unix-dependent, as is the behavior of
read-line! in the same file. Perhaps one should do something about that. If
so, the entire (ice-9 rdelim) module needs to be revised as well as
libguile/rdelim.c since the current implementation assumes that the line
delimiter is a single character, which was not true under Windows last time
I checked.

Best regards,
Mikael

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

Re: [PATCH] test-suite: Add tests for `for-rdelim-in-port`-relatedfunctions.

[Nala Ginrut]

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

>
> If so, the entire (ice-9 rdelim) module needs to be revised as well as
> libguile/rdelim.c since the current implementation assumes that the line
> delimiter is a single character, which was not true under Windows last time
> I checked.
>


As I know, Windows seems the only mainstream and living OS which treat
newline with 2 chars. And according to my previous suggestion, people use
WSL for GNU tools on Windows nowadays.
So I wonder if it is still necessary to introduce and maintain such
complexity.
But as I said before, it is not a bad idea to do this, just cost wise.
Again, I don't against such an opinion.

Best regards.

>

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

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

[Maxime Devos]

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

> [...]
> Maybe there's a misunderstanding here: What Adams test does is to compile a list of results. What he refers to is the #t returned by the test checking that the compiled results are correct. I changed that wording. Otherwise, I think the test is fine (on a Unix system).

Sounds reasonable.

>>Also, there was the thing about needing to verify whether (ice-9 rdelim) always recognises \n or whether that’s Unix-dependent (if the latter, (ice-9 rdelim) or the test needs to be adjusted, and in case of the former the documentation needs to be adjusted).

>You're right that the behavior is Unix-dependent, as is the behavior of read-line! in the same file. Perhaps one should do something about that. If so, the entire (ice-9 rdelim) module needs to be revised as well as libguile/rdelim.c since the current implementation assumes that the line delimiter is a single character, which was not true under Windows last time I checked.

(With Unix-dependent I actually meant ‘on Unix(-like) Guile does this, on others Guile does that’.)

Yes, Windows convention is \r\n. I imagine Windows probably recognises \n in many contexts as well though I’m not completely sure about that, but \r\n is its ‘standard’ line ending last time I checked.

That rdelim behaviour looks more problematic than what I expected. Looking at rdelim.scm, it only considers ‘\n’. Also, the interface of read-delimited is intrinsically can’t support multiple-character delimiters (you could replace the string of characters by a list of strings, but ergh). Since other procedures for reading lines exist, I think it’s best to just leave reading lines up to them. Although, likely read-line and read-line! can be fixed.

Proposed documentation modifications, to bring it in line with the implementation, without preventing future fixes (even if a fixed implementation isn’t yet available, it is better to have documentation that acknowledges the faults than having the faults be unknown, and it also provides an opportunity to mention potential incompatible API changes in advance).

> (ice-9 rdelim) documentation:
>(Old) It can be used to read or write lines of text, or read text delimited by a specified set of characters.
>(New)  It can be used to read text delimited by a specified set of characters. You can also use it to read lines of text delimited by a single-character delimiter. However, this will not give appropriate results for text produced on Windows, which delimits lines by a two-character sequence. For general line reading, get-line from (rnrs io ports) is more appropriate.
>(Old) Return a line of text from port if specified, otherwise from the value returned by (current-input-port). Under Unix, a line of text is terminated by the first end-of-line character or by end-of-file.
>(New) Return a newline-terminated line of text from port if specified, otherwise from the value returned by (current-input-port). In future versions of Guile, this may be modified to also recognise other line terminators.
>(Old)Read a line of text into the supplied string buf and return the number of characters added to buf. If buf is filled, then #f is returned. Read from port if specified, otherwise from the value returned by (current-input-port).
>(New)Read a newline-terminated line of text into the supplied string buf and return the number of characters added to buf. If buf is filled, then #f is returned. Read from port if specified, otherwise from the value returned by (current-input-port). In future versions of Guile, this may be modified to also recognise other line terminators.

>(Old)Read a newline-terminated line from port, allocating storage as necessary. The newline terminator (if any) is removed from the string, and a pair consisting of the line and its delimiter is returned. The delimiter may be either a newline or the eof-object; if %read-line is called at the end of file, it returns the pair (#<eof> . #<eof>).
> (New) Read a newline-terminated line from port, allocating storage as necessary. The newline terminator (if any) is removed from the string, and a pair consisting of the line and its delimiter is returned. The delimiter may be either a newline or the eof-object; if %read-line is called at the end of file, it returns the pair (#<eof> . #<eof>). The newline is returned as a character. In future versions of Guile, this may be modified to also recognise other line terminators, and the delimiter might be returned as a string instead.

> (rnrs io ports) documentation:
> Scheme Procedure: get-line input-port ¶
> (New) See Textual I/O. Unlike Textual I/O, eol-style should be taken into account according to R6RS. However, this is not implemented.
>Old: Display obj and a newline character to port. If port is not specified, (current-output-port) is used. This procedure is equivalent to: […]
>New: Display obj and a newline character to port. If port is not specified, (current-output-port) is used. This procedure is equivalent to: […] In future versions of Guile, this may be modified to write other line terminators depending on its end-of-line style.

> Scheme Procedure: write-char char textual-output-port
>old: These procedures are identical to the ones provided by Guile’s core library. See Venerable Port Interfaces, and See Writing Scheme Values, for documentation.
>old: These procedures are identical to the ones provided by Guile’s core library. See Venerable Port Interfaces, and See Writing Scheme Values, for documentation. Contrary to what R6RS prescribes, neither module automatically convers line feed characters to the line terminator of the end-of-line style.
(Please check the last point, seems like something that should be tested experimentally and I don’t have a Guile setup on this computer.)
(Also, docstrings are to be modified accordingly)

Best regards,
Maxime Devos

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