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