Subject: [clisp-list] Re: *print-pretty*, read-char

From: "Hoehle, Joerg-Cyril" <[email-masked]>
Date: Fri Mar 19 09:49:04 2004

warning: Off-topic (OT), no reference to Lisp below.

Bruno Haible wrote:
>some innocent looking code that is broken by such a change:
>(let ((s (make-string-input-stream "xy
>z"))) (progn (read s) (read-char s)))
>would return #\z on Unix and #\LF in Don Cohen's "Windows 
>faithful" mode.
>There are lots of examples like this.

This reminds me how for over 10 years, gcc's cpp was unable on UNIX to handle continuation lines (backslash at end of line) emanating from MS-DOS systems.

I.e. on UNIX, you had *often* no problems compiling a file using DOS CRLF.

But when the source code contained
#define frob(x) /* now it's getting long */ 1+ \
 (3 * (x) + FRODO)
cpp would halt with an error. You had to modify the source code to remove the CR after the backslash \ (or just convert the whole file to UNIX conventions).

I *really* think that it's great when CR/LF both disappear from my eyes and I can concentrate on the line's actual content. perl and php get this just plain wrong. CL's read-line gets it right.

I can cite abundant examples where varying CR/LF caused software to fail or behave strangely.

The most recent experience (just today), about having or not having CR/LF at the end of the last line of a file (so it's actually a different topic), was using sed on Solaris, which caused the last line to be completely dropped. :-(

Regards,
	Jörg Höhle.