Re: Linefeed character in SBCL



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...)
.



Relevant Pages

  • Re: Linefeed character in SBCL
    ... character in SBCL. ... I feel this way because (write-char #\Linefeed ... stream) returns #\Newline. ... How can I access the distinct Linefeed character in SBCL? ...
    (comp.lang.lisp)
  • Re: getting a simple-base-string from read-line
    ... > I've been doing some reading from files in SBCL and I was hoping I could ... > (SIMPLE-ARRAY CHARACTER (3)) CHARACTER ... > lines to be of type simple-base-string in SBCL and SBCL compained loudly ... The reason for this flexibility is to allow implementations to choose ...
    (comp.lang.lisp)
  • Re: Speed: a column of floats from large file
    ... Well, no, because as you said the bottleneck for SBCL is in READ-LINE, ... for external formats on character streams: ... asked for (whether explicitly through an:external-format argument, ... the bottleneck is likely to be in parsing the float. ...
    (comp.lang.lisp)
  • Re: Changing stream :element-type
    ... >> Note that the LANG=C hack to write octets to a character stream appears to ... The POSIX C locale, in character set terms, corresponds pretty closely ... such, using it to encode octets is a pretty poor idea, because, as ... been written by sbcl users and developers of the simple-streams ...
    (comp.lang.lisp)
  • Execution Error in Compiled Stalin Code
    ... When is 'display' the character in question I get .. ... The only write-char is in my ad hoc write-line routine ... I tried various Stalin command line options, ... The compiles generated a plethora of error messages, ...
    (comp.lang.scheme)