Hi,
I get an error when trying to run the following example code (from the
Paul Graham book):
> (defun our-length (lst)
(let ((len 0))
(dolist (obj lst)
(setf len (+ len 1)))
len))
OUR-LENGTH
> (our-length (list 1 2 3))
*** - EVAL: variable L has no value
backtrace reveals that our-length is being read as:
(BLOCK OUR-LENGTH
(LET ((LEN 0)) (DOLIST (OBJ LST) (SETF LEN (+ LEN 1))) L LEN))
Can someone tell me where that extra 'L' is coming from near the end
of the line, and is this a known problem?
If I remove the leading whitespace in the last line of our-length the
problem disappears. This happens in both CLisp (windows client) and
ECL (on Linux).
Thanks,
Michael
From: Juan Jose Garcia Ripoll
Subject: Re: Newbie question: lisp parsing error?
Date:
Message-ID: <2gbmrtFuog1U1@uni-berlin.de>
Hi Michael
Michael O'Connor wrote:
> I get an error when trying to run the following example code (from the
> Paul Graham book):
>
>>(defun our-length (lst)
>
> (let ((len 0))
> (dolist (obj lst)
> (setf len (+ len 1)))
> len))
> OUR-LENGTH
>
>>(our-length (list 1 2 3))
>
> *** - EVAL: variable L has no value
>
> backtrace reveals that our-length is being read as:
> (BLOCK OUR-LENGTH
> (LET ((LEN 0)) (DOLIST (OBJ LST) (SETF LEN (+ LEN 1))) L LEN))
>
> If I remove the leading whitespace in the last line of our-length the
> problem disappears. This happens in both CLisp (windows client) and
> ECL (on Linux).
I cannot reproduce this with neither of the two :-/ How did you type
this example? From the command line? Did you try saving this in a file
and loading it?
It could happend that, if you cut and pasted from a text file, you are
not pasting just normal characters, but unicode ones, that ECL does not
understand. This happens to me, for instance, when pasting text from
knode into a terminal. Most of the times the spaces are pasted with code
0x80 or something like that, which confuses ECL.
Regards,
Juanjo
Michael O'Connor wrote:
> Hi,
>
> I get an error when trying to run the following example code (from the
> Paul Graham book):
>
>
>>(defun our-length (lst)
>
> (let ((len 0))
> (dolist (obj lst)
> (setf len (+ len 1)))
> len))
> OUR-LENGTH
>
>>(our-length (list 1 2 3))
>
> *** - EVAL: variable L has no value
>
I am a newbie and I get similar errors when I cut and paste from the pdf
for Paul Graham's OnLisp and I think it has to do with characters that
are not visible (control chars or maybe bytes that are not shown in your
charset).
The code above looks to be from the ACL book of PG and not OnLisp. You
might want to indicate that in your future posts and page # and the
source where you are copying from if you want someone to replicate
issues FWIW.
Usually I get these fixed by trial and error to find the problematic
part (in this case the last line as you indicated). The ` and ' always
seem get copied badly from the pdf in my case.
You could try a hex editor to see what you've got in your file if your
are curious.
Let me know if you find a better way to handle this kind of problem.
-Antony
Antony Sequeira <·············@hotmail.com> said:
>I am a newbie and I get similar errors when I cut and paste from the pdf
>for Paul Graham's OnLisp and I think it has to do with characters that
>are not visible (control chars or maybe bytes that are not shown in your
>charset).
I have also gotten them copying and pasting into Clisp, although it
doesn't have to be from a PDF -- I can get these when copying from
another text editor. Slime avoids this, but even when using Clisp
directly retyping the example has always worked (or given me a
different, more sensisble, error.)
adam connor <···················@mail.com> wrote in message news:<··································@4ax.com>...
> Antony Sequeira <·············@hotmail.com> said:
> >I am a newbie and I get similar errors when I cut and paste from the pdf
> >for Paul Graham's OnLisp and I think it has to do with characters that
> >are not visible (control chars or maybe bytes that are not shown in your
> >charset).
>
> I have also gotten them copying and pasting into Clisp, although it
> doesn't have to be from a PDF -- I can get these when copying from
> another text editor. Slime avoids this, but even when using Clisp
> directly retyping the example has always worked (or given me a
> different, more sensisble, error.)
I used to get Python errors when I cut & paste code from a PDF to
Python's builtin editor. Interesting to track that bug down...