This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
> > Of course, this is assuming that anyone is ever going to use a port, > > with scm_do_read_line, that doesn't use a newline as a line > > incrementor, but wants to take the port-line of that port. I'd think > > that probability aproaches 0, since 'lines' probably won't make much > > sense there, anyway. > > I'd expect periodic bug reports from people wondering why port-line is > different after reading a file by read-char vs by read-line, but this > is when checking the line number after getting eof-object, so maybe > it's sufficient to say in the documentation that port-line is > undefined after end of file, and this is why. I think that ports with different newline characters don't matter at this level, because read-line and read-char must behave consistently with each other; (read-line port) is, by definition, equivalent to (let loop ((chars '())) (let ((char (read-char port))) (cond ((eof-object? char) (list->string (reverse chars))) ((char=? char #\newline) (list->string (reverse (cons char chars)))) (else (loop (cons char chars)))))) I can imagine parsing complicated stuff which has all kinds of wild definitions for line boundaries. Unicode might be such a case (my copy of the standard is still packed, rats). I'm not sure that the I/O ports are the right place to handle that; I think you want to have a different set of routines, built on normal ports, that match the actual semantics of the file format better than read-char and read-line. In other words, that's not a problem we want to solve here. :) I think I've got changes in there now that make this all work right, including missing newlines at EOF.