I'm a little confused with the role that whitespace plays in the lisp
world.
(Just to be clear, I'm using clisp.)
To quote the Common Lisp Hyperspec, Section 2.1.4: "Whitespace
characters serve as separators but are otherwise ignored."
To me that means the programs:
'a (blarg blarg)
and
'a
(blarg blarg)
are equivalent.
The first runs fine. I guess (blarg blarg) is completely ignored
(which seems counter-intuative to me). 'a is seen to be a self
evaluating symbol, evaluated and printed.
The second results in an error. blarg is seen by clisp to be undefined
so we know (blarg blarg) is NOT ignored.
Hence the two programs are NOT equivalent.
Is clisp broken on such a fundamental thing? Is it a setting I have to
change? Or am I missing something?
Thanks for any insight.
-Mark
From: Larry Clapp
Subject: Re: syntax question from a newbie
Date:
Message-ID: <0a0nva.srj.ln@127.0.0.1>
In article <····························@posting.google.com>, mark wrote:
> I'm a little confused with the role that whitespace plays in the
> lisp world.
> (Just to be clear, I'm using clisp.)
>
> To quote the Common Lisp Hyperspec, Section 2.1.4: "Whitespace
> characters serve as separators but are otherwise ignored."
>
> To me that means the programs:
>
> 'a (blarg blarg)
>
> and
>
> 'a
> (blarg blarg)
>
> are equivalent.
>
> The first runs fine. I guess (blarg blarg) is completely ignored
> (which seems counter-intuative to me). 'a is seen to be a self
> evaluating symbol, evaluated and printed.
> The second results in an error. blarg is seen by clisp to be
> undefined so we know (blarg blarg) is NOT ignored.
>
> Hence the two programs are NOT equivalent.
>
> Is clisp broken on such a fundamental thing?
Sort of. clisp's reader function certainly doesn't appear to work the
way one would expect (given the CLHS text, especially). By contrast,
in CMUCL, this:
'a (blarg blarg)
prints A, then gives an undefined function error for blarg.
On the other hand, if you say
(progn
'a
(blarg blarg)
)
to clisp, you do in fact get an undefined function error. clisp
appears to read a single form from stdin, and throws the rest away.
E.g:
[14]> 'a 'b 'c 'd #\garbage
A
[15]> '(this is a
test) 'b 'c 'd
(THIS IS A TEST)
I wouldn't worry about it too much, though. As bugs go, this one
doesn't eat much. :)
-- Larry
Larry Clapp <·····@theclapp.org> wrote in message news:<·············@127.0.0.1>...
> ...
> I wouldn't worry about it too much, though. As bugs go, this one
> doesn't eat much. :)
>
> -- Larry
Well, the reason I'm worried is because the way I decided to learn
Lisp is to simultaniously write an interpreter (limited in
functionaly) and learn the language. So I was a little confused at
this point. I wasn't sure if the tokenizer should be throwing (blarg
blarg) away or if the evaluator somehow set a flag that it should
ignore things or what.
Now I undersand that neither is the case. The tokenizer should return
the symbol 'a, it gets evaluated and printed. Then the cons cell
(blarg blarg) gets returned and upon an attemted evaluated an error
occurs.
In addition to everything available on the web, I did manage to order
"Anatomy of Lisp" from a used bookstore on the web and it should be
arriving within the next couple of weeks. So I'm not going into this
endevour completely blind.
Thanks everyone for your help.
-Mark
"mark" <···@hotmail.com> wrote in message ·································@posting.google.com...
> I'm a little confused with the role that whitespace plays in the lisp
> world.
> (Just to be clear, I'm using clisp.)
>
> To quote the Common Lisp Hyperspec, Section 2.1.4: "Whitespace
> characters serve as separators but are otherwise ignored."
>
> To me that means the programs:
>
> 'a (blarg blarg)
>
> and
>
> 'a
> (blarg blarg)
>
> are equivalent.
>
> The first runs fine. I guess (blarg blarg) is completely ignored
> (which seems counter-intuative to me). 'a is seen to be a self
> evaluating symbol, evaluated and printed.
> The second results in an error. blarg is seen by clisp to be undefined
> so we know (blarg blarg) is NOT ignored.
>
> Hence the two programs are NOT equivalent.
>
> Is clisp broken on such a fundamental thing? Is it a setting I have to
> change? Or am I missing something?
>
------test.lisp--------
'a (blarg blarg)
-----------------------
[1]> (load "C:/test.lisp")
;; Loading file C:\test.lisp ...
*** - EVAL: the function BLARG is undefined
------test1.lisp--------
'a
(blarg blarg)
-----------------------
1. Break [2]> (load "C:/test1.lisp")
;; Loading file C:\test1.lisp ...
*** - EVAL: the function BLARG is undefined
2. Break [3]>
C:\>C:\Docume~1\AllUse~1\Desktop\clisp <test.lisp
i i i i i i i ooooo o ooooooo ooooo ooooo
I I I I I I I 8 8 8 8 8 o 8 8
I \ `+' / I 8 8 8 8 8 8
\ `-+-' / 8 8 8 ooooo 8oooo
`-__|__-' 8 8 8 8 8
| 8 o 8 8 o 8 8
------+------ ooooo 8oooooo ooo8ooo ooooo 8
Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2002
A
*** - EVAL: the function BLARG is undefined
Bye.
C:\>C:\Docume~1\AllUse~1\Desktop\clisp <test1.lisp
i i i i i i i ooooo o ooooooo ooooo ooooo
I I I I I I I 8 8 8 8 8 o 8 8
I \ `+' / I 8 8 8 8 8 8
\ `-+-' / 8 8 8 ooooo 8oooo
`-__|__-' 8 8 8 8 8
| 8 o 8 8 o 8 8
------+------ ooooo 8oooooo ooo8ooo ooooo 8
Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2002
A
*** - EVAL: the function BLARG is undefined
Bye.
Using the line interface directly, OTOH, appears to accept the first
complete form it finds and discards the rest. Not a big deal as long
as it handles files correctly.
--
Geoff
Geoffrey Summerhayes <·············@hotmail.com> wrote:
+---------------
| Using the line interface directly, OTOH, appears to accept the first
| complete form it finds and discards the rest.
+---------------
Yes, the problem appears to be in the GNU "readline" editing interface
*not* in CLISP's Lisp reader per se.
+---------------
| Not a big deal as long as it handles files correctly.
+---------------
Well, it often breaks completely when trying to copy & paste multi-form
input from some other source. [As in, "Hmmm... Neat little hack I see
here in this netnews posting. Let me pop up a listener and paste it
in to try... Oh, crap! Burned again! I forgot to copy it one form at
a time!"] I've found it inconvenient enough that I've mostly switched
to CMUCL for that kind of stuff.
On the other hand, the GNU "readline" editing interface can be awfully
convenient when doing "tweak & run" kinds of exploration. You can afford
to hand-type longer expressions directly into the listener, knowing that
if you typo you can <ESC><UP> and fix it.
You takes your pick and gets what you get, I suppose...
-Rob
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
> Geoffrey Summerhayes <·············@hotmail.com> wrote:
> +---------------
> | Using the line interface directly, OTOH, appears to accept the first
> | complete form it finds and discards the rest.
> +---------------
>
> Yes, the problem appears to be in the GNU "readline" editing interface
> *not* in CLISP's Lisp reader per se.
>
> +---------------
> | Not a big deal as long as it handles files correctly.
> +---------------
>
> Well, it often breaks completely when trying to copy & paste multi-form
> input from some other source. [As in, "Hmmm... Neat little hack I see
> here in this netnews posting. Let me pop up a listener and paste it
> in to try... Oh, crap! Burned again! I forgot to copy it one form at
> a time!"] I've found it inconvenient enough that I've mostly switched
> to CMUCL for that kind of stuff.
>
> On the other hand, the GNU "readline" editing interface can be awfully
> convenient when doing "tweak & run" kinds of exploration. You can afford
> to hand-type longer expressions directly into the listener, knowing that
> if you typo you can <ESC><UP> and fix it.
>
> You takes your pick and gets what you get, I suppose...
Actually, it's a feature: it allows you to write:
[51]> (+ 2 3))))))))))))
5
It has nothing to do with readline, only that once you've pasted your
multiple s-exp on a line, you can go back and add (values ... ):
[52]> (+ 1 3) (* 2 4)
4
^P^A(values ^E)RETURN:
[53]> (values (+ 1 3) (* 2 4))
4 ;
8
--
__Pascal_Bourguignon__ http://www.informatimago.com/
----------------------------------------------------------------------
There is a fault in reality. Do not adjust your minds. -- Salman Rushdie
> * In message <······················@giganews.com>
> * On the subject of "Re: syntax question from a newbie"
> * Sent on Sat, 11 Jan 2003 05:04:00 -0600
> * Honorable ····@rpw3.org (Rob Warnock) writes:
>
> +---------------
> | Not a big deal as long as it handles files correctly.
> +---------------
>
> Well, it often breaks completely when trying to copy & paste
> multi-form input from some other source. [As in, "Hmmm... Neat little
> hack I see here in this netnews posting. Let me pop up a listener and
> paste it in to try... Oh, crap! Burned again! I forgot to copy it one
> form at a time!"] I've found it inconvenient enough that I've mostly
> switched to CMUCL for that kind of stuff.
if you want to type several expressions on the same line, like this:
[1]> 2345 356
2345
[2]>
356
[3]>
you can try the appended patch (made against the current CVS head, I am
not sure whether it will apply cleanly against 2.30)
comments?
--
Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
main(a){a="main(a){a=%c%s%c;printf(a,34,a,34);}";printf(a,34,a,34);}
Index: src/reploop.lisp
===================================================================
RCS file: /cvsroot/clisp/clisp/src/reploop.lisp,v
retrieving revision 1.20
diff -u -w -b -r1.20 reploop.lisp
--- src/reploop.lisp 11 Dec 2002 20:09:25 -0000 1.20
+++ src/reploop.lisp 14 Jan 2003 19:32:01 -0000
@@ -472,6 +472,7 @@
(force-output *debug-io*)
(tagbody
+ (makunbound '*terminal-read-stream*)
(clear-input *debug-io*) ; because the user did not expect a break loop
(let* ((*break-count* (1+ *break-count*))
(stream (make-synonym-stream '*debug-io*))
Index: src/debug.d
===================================================================
RCS file: /cvsroot/clisp/clisp/src/debug.d,v
retrieving revision 1.52
diff -u -w -b -r1.52 debug.d
--- src/debug.d 11 Dec 2002 20:04:31 -0000 1.52
+++ src/debug.d 14 Jan 2003 19:32:02 -0000
@@ -48,7 +48,7 @@
pushSTACK(STACK_3); pushSTACK(NIL); funcall(L(terminal_raw),2); pushSTACK(value1);
# Stackaufbau: ostream, istream, prompt, command-list, inputstream, raw.
var signean status = listen_char(STACK_4); # horchen
- if (ls_eof_p(status))
+ if (ls_eof_p(status) && !boundp(Symbol_value(S(terminal_read_stream))))
goto eof;
# bereits Zeichen verf�¼gbar (und nicht im ilisp_mode) -> kein Prompt
if (ilisp_mode || interactive_stream_p(STACK_4)) {
@@ -115,7 +115,9 @@
}
#endif
#if !defined(TERMINAL_USES_KEYBOARD) # auf dem Atari ging's �¼ber Funktionstasten
- if (!ls_avail_p(status)) { # nur bei interaktivem Input-Stream
+ var bool terminal_read_stream_bound = false;
+ if (!ls_avail_p(status) /* only for interactive input streams */
+ && !boundp(Symbol_value(S(terminal_read_stream)))) {
# Erkennung von Kommandos statt Formen:
# (multiple-value-bind (line flag) (read-line istream)
# (let ((h (assoc line *key-bindings* :test #'string-equal)))
@@ -175,6 +177,13 @@
pushSTACK(value1); pushSTACK(*inputstream_);
funcall(L(make_concatenated_stream),2);
dynamic_bind(S(terminal_read_stream),value1);
+ terminal_read_stream_bound = true;
+ *inputstream_ = Symbol_value(S(terminal_read_stream));
+ } else if (streamp(Symbol_value(S(terminal_read_stream)))) {
+ var object stream = Symbol_value(S(terminal_read_stream));
+ Symbol_value(S(terminal_read_stream)) = unbound;
+ dynamic_bind(S(terminal_read_stream),stream);
+ terminal_read_stream_bound = true;
*inputstream_ = Symbol_value(S(terminal_read_stream));
}
#endif
@@ -182,7 +191,19 @@
var object obj = stream_read(inputstream_,NIL,NIL); # read object (recursive-p=NIL, whitespace-p=NIL)
dynamic_unbind(); # S(read_suppress)
#if !defined(TERMINAL_USES_KEYBOARD)
- if (!ls_avail_p(status)) dynamic_unbind(); # S(terminal_read_stream)
+ if (streamp(Symbol_value(S(terminal_read_stream)))) {
+ var object stream = Symbol_value(S(terminal_read_stream));
+ var object strm_l = TheStream(stream)->strm_concat_list;
+ if (terminal_read_stream_bound)
+ dynamic_unbind(); /* S(terminal_read_stream) */
+ Symbol_value(S(terminal_read_stream)) =
+ (consp(strm_l) && !nullp(Cdr(strm_l))
+ /* some input on the first line was not processed ? */
+ && (pushSTACK(T), pushSTACK(Car(strm_l)),
+ pushSTACK(NIL), pushSTACK(eof_value),
+ funcall(L(peek_char),4), !eq(value1,eof_value)))
+ ? stream : unbound;
+ }
#endif
dynamic_unbind(); # S(key_bindings)
if (!eq(obj,eof_value)) { # EOF test (after whitespace)
@@ -378,6 +399,7 @@
back_trace = &bt_here;
/* Default-Driver: (CLEAR-INPUT *DEBUG-IO*), since whatever has been
typed so far, was not typed in anticipation of this error */
+ Symbol_value(S(terminal_read_stream)) = unbound;
clear_input(var_stream(S(debug_io),strmflags_rd_ch_B|strmflags_wr_ch_B));
/* SYS::*BREAK-COUNT* increase: */
dynamic_bind(S(break_count),fixnum_inc(Symbol_value(S(break_count)),1));
Index: src/constsym.d
===================================================================
RCS file: /cvsroot/clisp/clisp/src/constsym.d,v
retrieving revision 1.173
diff -u -w -b -r1.173 constsym.d
--- src/constsym.d 9 Jan 2003 23:05:24 -0000 1.173
+++ src/constsym.d 14 Jan 2003 19:32:03 -0000
@@ -1541,7 +1541,7 @@
LISPSYM(prin_jblpos,"*PRIN-JBLPOS*",system) /* IO variable */
LISPSYM(format_tabulate,"FORMAT-TABULATE",system) /* see io.d and format.lisp */
LISPSYM(terminal_read_open_object,"*TERMINAL-READ-OPEN-OBJECT*",system) /* IO */
-LISPSYM(terminal_read_stream,"*TERMINAL-READ-STERAM*",system) /* IO */
+LISPSYM(terminal_read_stream,"*TERMINAL-READ-STREAM*",system) /* IO */
LISPSYM(backquote,"BACKQUOTE",system) /* marker in IO */
LISPSYM(splice,"SPLICE",system) /* marker in IO */
LISPSYM(nsplice,"NSPLICE",system) /* marker in IO */
Sam Steingold <···@gnu.org> wrote in message news:<··············@loiso.podval.org>...
> [...]
> if you want to type several expressions on the same line [...]
> you can try the appended patch (made against the current CVS head, I am
> not sure whether it will apply cleanly against 2.30)
>
> comments?
Yes. Thank you! I intend to give this a go as soon as I have a bit of
time. This is definitely the sort of behavior I'd prefer.
-Mark
In article <····························@posting.google.com>,
mark <···@hotmail.com> wrote:
>I'm a little confused with the role that whitespace plays in the lisp
>world.
>(Just to be clear, I'm using clisp.)
>
>To quote the Common Lisp Hyperspec, Section 2.1.4: "Whitespace
>characters serve as separators but are otherwise ignored."
>
>To me that means the programs:
>
>'a (blarg blarg)
>
>and
>
>'a
>(blarg blarg)
>
>are equivalent.
>
>The first runs fine. I guess (blarg blarg) is completely ignored
>(which seems counter-intuative to me). 'a is seen to be a self
>evaluating symbol, evaluated and printed.
>The second results in an error. blarg is seen by clisp to be undefined
>so we know (blarg blarg) is NOT ignored.
>
>Hence the two programs are NOT equivalent.
>
>Is clisp broken on such a fundamental thing? Is it a setting I have to
>change? Or am I missing something?
It seems like a bug to me.
On the other hand, I wouldn't be surprised to see a difference between:
(blarg blarg) 'a
and
(blarg blarg)
'a
when running interactively. The debugger that's invoked when the error
occurs might clear out the input buffer (to avoid using it as a response to
the debugger's prompts), so anything later on the same line may get
discarded.
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
···@hotmail.com (mark) wrote in message news:<····························@posting.google.com>...
[snip]
> 'a is seen to be a self evaluating symbol, evaluated and printed.
Is that right?
I thought 'a [== (quote a)] is a form, with QUOTE being a special
operator that returns its argument without evaluating it. Hence 'a =>
A.
Thanks,
Vijay L
······@lycos.com (Vijay L) wrote in message news:<····························@posting.google.com>...
> ···@hotmail.com (mark) wrote in message news:<····························@posting.google.com>...
>
> [snip]
>
> > 'a is seen to be a self evaluating symbol, evaluated and printed.
>
> Is that right?
>
> I thought 'a [== (quote a)] is a form, with QUOTE being a special
> operator that returns its argument without evaluating it. Hence 'a =>
> A.
>
> Thanks,
>
> Vijay L
Sorry. You're right. I wasn't thinking. Things like T and 123 are self-evaluating.
-Mark
···@hotmail.com (mark) wrote in message news:<····························@posting.google.com>...
> I'm a little confused with the role that whitespace plays in the lisp
> world.
> (Just to be clear, I'm using clisp.)
>
> To quote the Common Lisp Hyperspec, Section 2.1.4: "Whitespace
> characters serve as separators but are otherwise ignored."
>
> To me that means the programs:
>
> 'a (blarg blarg)
>
> and
>
> 'a
> (blarg blarg)
>
> are equivalent.
>
> The first runs fine. I guess (blarg blarg) is completely ignored
> (which seems counter-intuative to me). 'a is seen to be a self
> evaluating symbol, evaluated and printed.
> The second results in an error. blarg is seen by clisp to be undefined
> so we know (blarg blarg) is NOT ignored.
Note that you are in an interactive Lisp shell. That shell does a
whole lot of things that are not in the Hyperspec. For example, if you
press up-arrow, you can recall history. Up arrows are not part of the
Lisp syntax and behavior either.
The CLISP interactive read loop expects you to type in a single
expression, which it will evaluate.
The Lisp implementations differ quite a bit in how they implement the
interactive read loops. The HyperSpec doesn't constrain in how this is
done.
In some systems, you have a text-editor-like window in which you
freely type text anywhere you want. In order to cause evaluation, you
may have to do something special, like put a cursor on an expression
anywhere in the buffer, or make a selection, and invoke a command to
evaluate it. Now how does *that* fit into the Hyperspec? The buffer
isn't even processed top to bottom!
Note that if you put your Lisp code into a file and load it, CLISP
handles that just fine; that's the important mechanism that is
governed by the Lisp syntax.
> Hence the two programs are NOT equivalent.
>
> Is clisp broken on such a fundamental thing? Is it a setting I have to
> change? Or am I missing something?
You just have to type the expressions as separate input lines, or else
put them into a PROGN, in which case only the last value will be
printed.