> * In message <4nem4fmem3.fsf@...>
> * On the subject of "Clisp and REAL"
> * Sent on 27 Jul 2000 17:45:40 -0400
> * Honorable Raymond Toy <toy@...> writes:
>
> 1. Clisp complains about redefining the macro //.
> 2. Clisp complains about redefining the function REAL.
These symbols, '//' and 'real', are exported from the package LISP.
You should not change any slots of a symbol in a locked package.
You will have the same problem with Allegro.
You will be much better off if you do not redefine symbols that you do
not own.
--
Sam Steingold (http://www.podval.org/~sds)
Micros**t is not the answer. Micros**t is a question, and the answer is Linux,
(http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation.
I'd give my right arm to be ambidextrous.

>>>>> "Bruno" == Bruno Haible <haible@...> writes:
Bruno> It's a portability problem with your code. If you define a
Bruno> function or macro on a symbol that's not in a package of
Bruno> yours, it can collide if other people do the same thing.
Ok.
I note that f2cl apparently used to be in its own package, but the
original authors changed that so that it was in USER.
I guess it should probably be changed back.
Thanks,
Ray

Raymond Toy writes:
>
> I'm trying to test f2cl with Clisp. Everything basically works, but I
> get the following problems.
>
> 1. Clisp complains about redefining the macro //. However, I can't
> find any such macro in Clisp. I see the special variable, but
> that's it.
>
> 2. Clisp complains about redefining the function REAL. However, I
> can't find any such function in Clisp. I see that it names a type
> and a class, but that's it.
>
> I could change f2cl to use something besides // and REAL, but I'd like
> to know if this is a problem with f2cl or Clisp.
It's a portability problem with your code. If you define a function or
macro on a symbol that's not in a package of yours, it can collide if
other people do the same thing.
Bruno

I'm trying to test f2cl with Clisp. Everything basically works, but I
get the following problems.
1. Clisp complains about redefining the macro //. However, I can't
find any such macro in Clisp. I see the special variable, but
that's it.
2. Clisp complains about redefining the function REAL. However, I
can't find any such function in Clisp. I see that it names a type
and a class, but that's it.
I could change f2cl to use something besides // and REAL, but I'd like
to know if this is a problem with f2cl or Clisp. I don't have any
such problems with CMUCL.
Ray

Raymond Toy writes:
> But on Unix (char-code #\Newline) is 10
In text files, most often, yes. But in network protocols, no. Look up
the RFCs for SMTP and be surprised that Unix machines sending mail to
Unix machines use CR-LF line terminators.
> it says read-line stops at #\Newline. If Clisp maps CR, LF, CRLF, and
> NEL all into #\Newline, then that's ok. But it doesn't.
CLISP maps CR, LF, CRLF all into #\Newline. (Not NEL, that's not
really used by anyone.) read-line stops when read-char returns
#\Newline.
Bruno

>>>>> "Bruno" == Bruno Haible <haible@...> writes:
Bruno> Raymond Toy writes:
>> Doesn't this cause all kinds of portability problems with Clisp and
>> read-line?
Bruno> On the contrary, it solves portability problems when dealing with
Bruno> files coming from other systems, or with data coming down a
Bruno> socket. With the traditional approach, sometimes it works by luck
Bruno> (when the program doesn't notice that the last character in a line is
Bruno> a control-M), but sometimes it causes problems.
But it causes problems when read-line breaks lines in different places
depending on whether you're using clisp or not.
>> The behavior would be different from what the CLHS says
Bruno> CLHS makes no claims about what #\Newline represents in the outside
Bruno> world.
No, it doesn't. But on Unix (char-code #\Newline) is 10, and
Control-M has a different code, so, to me, read-line shouldn't stop on
Control-M.
>> and probably different from all other lisps (on Unix).
Bruno> It's nice to be avantgarde! :-)
:-) !
Bruno> CLISP is only following the Unicode TR#13 recommendation:
Bruno> Note: Even if you know which characters represents Newline on your
Bruno> particular platform, on input and in interpretation, treat CR, LF,
Bruno> CRLF, and NEL the same. Only on output do you need to distinguish
Bruno> between them.
Ok, if you say so, but that appears to be in conflict with CLHS where
it says read-line stops at #\Newline. If Clisp maps CR, LF, CRLF, and
NEL all into #\Newline, then that's ok. But it doesn't.
I was just surprised, and it somewhat annoys me, but my immediate
problem has been solved by removing the extraneous control-M
character.
Ray

Raymond Toy writes:
> Doesn't this cause all kinds of portability problems with Clisp and
> read-line?
On the contrary, it solves portability problems when dealing with
files coming from other systems, or with data coming down a
socket. With the traditional approach, sometimes it works by luck
(when the program doesn't notice that the last character in a line is
a control-M), but sometimes it causes problems.
> The behavior would be different from what the CLHS says
CLHS makes no claims about what #\Newline represents in the outside
world.
> and probably different from all other lisps (on Unix).
It's nice to be avantgarde! :-)
CLISP is only following the Unicode TR#13 recommendation:
Note: Even if you know which characters represents Newline on your
particular platform, on input and in interpretation, treat CR, LF,
CRLF, and NEL the same. Only on output do you need to distinguish
between them.
Bruno

>>>>> "Bruno" == Bruno Haible <haible@...> writes:
Bruno> Raymond Toy writes:
>> However, read-line is supposed to stop on a #\Newline character, not a
>> control-M.
Bruno> Control-M is the newline character used by Apple's operating systems
Bruno> and by at least one Microsoft application on Win32.
Bruno> So the answer is: It's a feature, not a bug.
For an Apple, #\Newline should be Control-M. But #\Newline on Unix
should be Control-J, not Control-M. Win32 is weird.
Doesn't this cause all kinds of portability problems with Clisp and
read-line? The behavior would be different from what the CLHS says
and probably different from all other lisps (on Unix).
Ray

Raymond Toy writes:
> However, read-line is supposed to stop on a #\Newline character, not a
> control-M.
Control-M is the newline character used by Apple's operating systems
and by at least one Microsoft application on Win32.
So the answer is: It's a feature, not a bug.
Bruno

Let the file test contain the following:
abcd^Mefgh
where ^M is a real control-M character, and the line above is
terminated with a newline. (This is on Unix.)
Then this bit of code
(with-open-file (s "test" :direction :input)
(do ((line (read-line s nil 'eof) (read-line s nil 'eof)))
((eq line 'eof))
(print line)))
prints:
"abcd"
"efgh"
However, read-line is supposed to stop on a #\Newline character, not a
control-M.
Is this right?
In my particular case, the ^M character is a mistake, but does cause
some unexpected results.
Ray
P.S. Clisp version is "2000-03-06 (March 2000)" on Solaris 2.7.