Re: Linefeed character in SBCL
- From: Kent M Pitman <pitman@xxxxxxxxxxx>
- Date: 30 Mar 2008 14:50:02 -0400
dstein64 <DStein64@xxxxxxxxx> writes:
On Mar 30, 11:06 am, dstein64 <DStei...@xxxxxxxxx> 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...)
.
- Follow-Ups:
- Re: Linefeed character in SBCL
- From: Rob Warnock
- Re: Linefeed character in SBCL
- References:
- Linefeed character in SBCL
- From: dstein64
- Re: Linefeed character in SBCL
- From: dstein64
- Linefeed character in SBCL
- Prev by Date: Re: tasters wanted
- Next by Date: Listing slots in CLOS
- Previous by thread: Re: Linefeed character in SBCL
- Next by thread: Re: Linefeed character in SBCL
- Index(es):
Relevant Pages
|
|