From: Dorai Sitaram
Subject: Can PRINC insert gratuitous newlines?
Date:
Message-ID: <astj1n$3rj$1@news.gte.com>
I expected the program
(progn (princ "abc") (princ "'
def") nil)
to print the same thing as
(progn (princ "abc'") (princ "
def") nil)
In CLISP, the first prints
abc
'
def
and the second prints
abc'
def
In CMUCL and SBCL, both programs print the second
result, which to me is expected behavior. However,
when I filed a bug report (via the clisp sf site), it
was closed because it apparently is not a bug. What
rationale can there be for this to be expected
PRINC behavior?
····@goldshoe.gte.com (Dorai Sitaram) writes:
> I expected the program
>
> (progn (princ "abc") (princ "'
> def") nil)
>
> to print the same thing as
>
> (progn (princ "abc'") (princ "
> def") nil)
>
> In CLISP, the first prints
>
> abc
> '
> def
>
> and the second prints
>
> abc'
> def
>
> In CMUCL and SBCL, both programs print the second result, which
> to me is expected behavior. However, when I filed a bug report
> (via the clisp sf site), it was closed because it apparently is
> not a bug. What rationale can there be for this to be expected
> PRINC behavior?
None whatsoever. It's a bug. What the hell were they thinking?
Regards,
--
Nils G�sche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID #xD26EF2A0
> * In message <············@news.gte.com>
> * On the subject of "Can PRINC insert gratuitous newlines?"
> * Sent on 7 Dec 2002 19:43:51 GMT
> * Honorable ····@goldshoe.gte.com (Dorai Sitaram) writes:
>
> I expected the program
>
> (progn (princ "abc") (princ "'
> def") nil)
>
> to print the same thing as
>
> (progn (princ "abc'") (princ "
> def") nil)
>
> In CLISP, the first prints
>
> abc
> '
> def
>
> and the second prints
>
> abc'
> def
>
> In CMUCL and SBCL, both programs print the second result, which to me
> is expected behavior. However, when I filed a bug report (via the
> clisp sf site), it was closed because it apparently is not a bug.
> What rationale can there be for this to be expected PRINC behavior?
did you actually bother to read my reply to the bug report?!
the standard gives the implementors a lot of freedom in printing when
*PRINT-PRETTY* is T, see "22.1.1.1 Multiple Possible Textual
Representations".
(http://www.lisp.org/HyperSpec/Body/sec_22-1-1-1.html).
In particular, when the current line already has
something on it and the next object does not fit on it (until
*PRINT-RIGHT-MARGIN*), the implementation may print in several
different ways, e.g.:
this is a long list: (1 2 3 4 5
6 7 8 9 10)
or
this is a long list:
(1 2 3 4 5 6 7 8 9 10)
22.1.1.1 says:
"here might also be implementation-defined printer control variables."
in CLISP, this is user-controlled via the variable
CUSTOM:*PPRINT-FIRST-NEWLINE*, which is documented in
<http://clisp.cons.org/impnotes.html#ppr-first-newline> or
<http://clisp.cons.org/impnotes/printer.html#ppr-first-newline>
--
Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
Growing Old is Inevitable; Growing Up is Optional.
Sam Steingold <···@gnu.org> writes:
> the standard gives the implementors a lot of freedom in
> printing when *PRINT-PRETTY* is T, see "22.1.1.1 Multiple
> Possible Textual Representations".
Whoops, and *PRINT-PRETTY* defaults to T in CLISP, apparently.
My apologies.
Regards,
--
Nils G�sche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID #xD26EF2A0