Re: Problem with SBCL pprint

--===============2691730779670514091==
Content-Type: multipart/alternative; boundary="0000000000001de3fb064e51a48e"

--0000000000001de3fb064e51a48e
Content-Type: text/plain; charset="UTF-8"

I'll agree that the precise language is somewhat elliptical and leaves
things to be inferrred.

https://www.lispworks.com/documentation/HyperSpec/Issues/iss169_w.htm says
that ~A and ~S print as if by PRINC and PRIN1 respectively, and that they
obey *print-pretty*. It further says that ~D,~B,~O,~X,~R (and others)
rebind printer controls.  So unless it meant that ~D,~B,~O,~X,~R are
permitted to *avoid* rebinding and recursively invoking any other builtin
functions, one might assume they operate simply by doing the rebindings as
specified and invoking PRINC.  Indeed that is precisely what these
directives do in at least 4 implementations of FORMAT that I looked at.
However it does in fact preclude NOT doing the rebindings!
    "The FORMAT function by itself  [...]  for each FORMAT directive,
they may neither bind [...] *nor fail to bind* any standard printer control
variables as specified in the description."

But what's the point of specifying mandatory rebindings if not to either
permit or require user-written functions to take over the printing as per
the print-pretty mechanism?
Honestly, I think it's stupid. But it is what it is.

And your possible bug? I don't know and don't care.  People shouldn't write
methods on integers, IMHO

--0000000000001de3fb064e51a48e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I&#39;ll agree that the precise language is somewhat ellip=
tical and leaves things to be inferrred.<div><br><div><a href=3D"https://ww=
w.lispworks.com/documentation/HyperSpec/Issues/iss169_w.htm">https://www.li=
spworks.com/documentation/HyperSpec/Issues/iss169_w.htm</a> says that ~A an=
d ~S print as if by PRINC and PRIN1 respectively, and that they obey *print=
-pretty*. It further says that ~D,~B,~O,~X,~R (and others) rebind printer c=
ontrols.=C2=A0 So unless it meant that ~D,~B,~O,~X,~R are permitted to <i>a=
void</i> rebinding and recursively invoking any other builtin functions, on=
e might assume they operate simply by doing the rebindings as specified and=
 invoking PRINC.=C2=A0 Indeed that is precisely what these directives do in=
 at least 4 implementations of FORMAT that I looked at.=C2=A0</div><div>How=
ever=C2=A0it does in fact preclude NOT doing the rebindings!</div></div><di=
v>=C2=A0 =C2=A0 &quot;The FORMAT function by itself=C2=A0 [...]=C2=A0=C2=A0=
for each FORMAT directive, they=C2=A0may neither bind [...]=C2=A0<b>nor fai=
l to bind</b> any standard printer control variables as specified in the=C2=
=A0description.&quot;</div><div><br></div><div>But what&#39;s the point of =
specifying=C2=A0mandatory rebindings if not to either permit or require use=
r-written functions to take over the printing as per the print-pretty mecha=
nism?</div><div>Honestly, I think it&#39;s stupid. But it is what it is.=C2=
=A0=C2=A0</div><div><br></div><div>And your possible bug? I don&#39;t know =
and don&#39;t care.=C2=A0 People shouldn&#39;t write methods on integers, I=
MHO<br><br></div></div>

--0000000000001de3fb064e51a48e--


--===============2691730779670514091==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============2691730779670514091==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Sbcl-help mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sbcl-help

--===============2691730779670514091==--