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