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]

Re: port-line bug details & patch question.



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