Re: (warn) isn't doing what I expect it to

Pascal Bourguignon <spam@xxxxxxxxxxxxxxxx> writes:

> Nathan Baum <nathan_baum@xxxxxxxxxxxxxx> writes:
> > In the real code, the newline is provided elsewhere. It turned out
> > that way because CLISP doesn't put a newline after a warning:
> >
> > (progn (warn "foo")
> > (princ "bar"))
> >
> > I don't feel the need to change things, since putting a newline in
> > there messes up the display, and removing it from where it is
> > displayed at the moment means that normal Lisp warnings (which I'm not
> > yet redirecting to a log) will be messed up when using CLISP.
>
> The point is that lisp is old enough to be born at a time when
> newlines were inserted _before_ the lines. You needed to move to a
> new-line to be able to print the current line or punch the current
> card.

Actually, the effect is not just that. There's actually something that was
a hugely more modern effect that has been left by the wayside as something
I personally consider a dinosaurlike convention won out over what I think
of as more progressive years ago... that is,

On the Lisp Machine, the parser was engaged with the rubout handler such
that you didn't have to press RETURN at the end of a line. When you typed
the last paren, it knew you were done and it activated immediately. As a
consequence, you were not on a new line.

Many people like me who come from LispM days always protect our
output by doing
(format t "~&...~%")
to say "make sure the previous I/O cleaned up, and make sure we don't
leave ourselves mid-line either." This is not a throwback to when cards
or line printers hadn't advanced, this is an accomodation to "dumb"
command processors that can't tell when you're done typing your command
except by you pressing an additional character not related to the command. :)

So it's just a point-of-view thing, I guess. Certainly there are more people
in the world who don't think like I do on this point than people who do,
so I won't argue my position is a majority opinion. But hearing it compared
to punched cards was a bit much...

The Lisp Machine managed rubout handling without having to know what parser
was active, and still managed to win, using an algorithm described in my
Lisp Pointer paper "Ambitious Evaluation" at
http://www.nhplace.com/kent/PS/Ambitious.html

> Note that even on a video terminal, it might be useful to use the
> newline before convention, since it gives you one more line on the
> screen. With the newline after, you always get the last like blank
> (not that matter much in a 80x60 emacs window ;-).

There's that as well, but the issue isn't just display, it's activation.

Additionally, there were some systems where you pressed Enter (a key
distinct from Return or Linefeed) and this meant not to add a newline
character but to activate immediately, submitting what had been typed
but not any termination key. This again had the issue that it left the
output in an undefined state.

So, for portability, since some command processors took
<prompt> <command>[output starts here]
and some took
<prompt> <command><return>
[output starts here]
the use of ~& was essential to getting portable behavior. I still
use it for this reason, always wishing in vain that the world would
catch back up to the cool style of the Lisp Machine rubout handling.

> If you want to follow unix convention, you need to make intensive use
> of ~&: (format t "~&bar~%") instead of (princ "bar") to interact
> nicely with "older" lisp code.

I agree. Except I'd use the word "newer". :)

Ain't point of view grand?
.

Relevant Pages

  • Re: How do I create a string with #Newline in it?
    ... > The OP was probably thinking of systems where newline is represented ... > wanted to translate to Lisp does. ... I thought that was (again - on unix systems) the ... Great forum. ...
    (comp.lang.lisp)
  • Re: (warn) isnt doing what I expect it to
    ... > that way because CLISP doesn't put a newline after a warning: ... > displayed at the moment means that normal Lisp warnings (which I'm not ... > yet redirecting to a log) will be messed up when using CLISP. ...
    (comp.lang.lisp)
  • Re: printing
    ... Jim Newton writes: ... > prints a carriage return. ... the notion of Newline in Lisp. ... No, it performs a Newline. ...
    (comp.lang.lisp)
  • Re: CLISP always outputs a newline when it exits
    ... You said CLISP only called fresh-line on text streams. ... (And always did expect a newline on all lines, ... If you write on these text streams, as the POSIX standard mandates, ...
    (comp.lang.lisp)
  • Re: CLISP always outputs a newline when it exits
    ... if I'm using it in a pipeline and need precise control over what gets ... you've affirmed about clisp things that are false. ... I can see where the newline is appended in the source ... lisp streams when you want to process unix flows, ...
    (comp.lang.lisp)