I tried searching the SBCL manual but couldn't find anything. It seems
that the #\Linefeed character is synonymous with the #\Newline
character in SBCL. I feel this way because (write-char #\Linefeed
stream) returns #\Newline.
How can I access the distinct Linefeed character in SBCL? Thanks.
On Mar 30, 11:06 am, dstein64 <········@gmail.com> wrote:
> I tried searching the SBCL manual but couldn't find anything. It seems
> that the #\Linefeed character is synonymous with the #\Newline
> character in SBCL. I feel this way because (write-char #\Linefeed
> stream) returns #\Newline.
>
> How can I access the distinct Linefeed character in SBCL? Thanks.
Actually, I believe it makes no difference for what I'm doing. This
post can be ignored.
dstein64 <········@gmail.com> writes:
> On Mar 30, 11:06 am, dstein64 <········@gmail.com> wrote:
> > I tried searching the SBCL manual but couldn't find anything. It seems
> > that the #\Linefeed character is synonymous with the #\Newline
> > character in SBCL. I feel this way because (write-char #\Linefeed
> > stream) returns #\Newline.
> >
> > How can I access the distinct Linefeed character in SBCL? Thanks.
>
> Actually, I believe it makes no difference for what I'm doing. This
> post can be ignored.
I'm glad it's not an immediate problem, although this does come up.
Reacting not to your problem, but to your remark about why you feel
what you did:
WRITE-CHAR returns that because that's what it was given, not because
it changes one to the other. That is, #\Newline is returned because,
in that implementation,
(eql #\Newline #\Linefeed) => T
or to put it another way,
#\Linefeed => #\Newline
Although the major operating systems seem to vary as to what they
think the right EOL character sequence is, it's common in CL
implementations for #\Newline to be the same character as one of
#\Return or #\Linefeed, since it was not intended that the standard
require the creation of a new character (not part of any popular
character coding system) for Newline independent of existing
characters.
I usually refer to the characters as #\Return and #\Linefeed when
thinking in ASCII and simply as #\Newline when trying to rise above
it.
It's perhaps unfortunate that we didn't just call them #\CR and #\LF
but that actually would have opened a different can of worms because
the LispM _did_ have a separate Newline character from either #\CR or
#\LF, since it literally had no ASCII coding. It used the SAIL
character set, which assigned code 0 to center-dot, code 1 to
downarrow, code 2 to [lowercase] beta, ..., code 10 to [lowercase]
delta, code 15 to circle-plus [a plus-sign with a circle around it].
See the full character set at
http://common-lisp.net/project/bknr/static/lmman/fd-str.xml
Note that the codes there are shown in octal, not decimal, which was
for a very long time the default ibase/base for Zetalisp, and that in
octal LF is 12 and CR is 15. Note also that Return is 215 OCTAL, that
is, an ASCII CR with the 200 octal bit (010 000 000 binary) set. (The
number of codes that had the 200 bit set on top of what would have
been the ASCII coding is something I never really noticed until just
this minute looking at that table, but I'm quite sure it was not
accidental. I had used ASCII for a couple of years before I noticed
the relation between lowercase A, uppercase A, and control A, and I
know those were not accidental...)
Kent M Pitman <······@nhplace.com> wrote:
+---------------
| http://common-lisp.net/project/bknr/static/lmman/fd-str.xml
| Note that the codes there are shown in octal, not decimal, which was
| for a very long time the default ibase/base for Zetalisp, and that in
| octal LF is 12 and CR is 15. Note also that Return is 215 OCTAL, that
| is, an ASCII CR with the 200 octal bit (010 000 000 binary) set. (The
| number of codes that had the 200 bit set on top of what would have
| been the ASCII coding is something I never really noticed until just
| this minute looking at that table, but I'm quite sure it was not
| accidental.
+---------------
Heh! For a second I thought it was just "7+1" even parity,
which was once upon a time the most common flavor of ASCII
used for Teletypes:
> (defun even-parity/7+1 (x)
(let ((x7 (logand x #o177)))
(+ x7 (if (oddp (logcount x7)) #o200 0))))
EVEN-PARITY/7+1
> (write (mapcar 'even-parity/7+1 (iota 16 8)) :base 8)
(210 11 12 213 14 215 216 17 220 21 22 223 24 225 226 27)
(136 9 10 139 12 141 142 15 144 17 18 147 20 149 150 23)
>
But looking at the URL you reference shows that that's incorrect.
Zetalisp just stuck all the "control" codes up at #o200+x for its
own weird reasons, and the fact that "x" happens to match the
corresponding ASCII control code for just a few of them was just a
convenience for the designers (and confusion for everyone else!).
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607