(defun lname(names)
(setq i 0)
(loop for i below (length names)
do (
(print (read-from-string (aref names i) nil nil :start 0))
)
)
)
names is an array of strings (full names) and I am trying to just print the
first name. Why am I getting a
"*** - SYSTEM::%EXPAND-FORM: (PRINT (READ-FROM-STRING (AREF NAMES I) NIL NIL
:STA
RT 0)) should be a lambda expression" error?
swoop wrote:
> (defun lname(names)
>
> (setq i 0)
>
> (loop for i below (length names)
> do (
> (print (read-from-string (aref names i) nil nil :start 0))
> )
> )
>
> )
>
>
> names is an array of strings (full names) and I am trying to just print the
> first name. Why am I getting a
> "*** - SYSTEM::%EXPAND-FORM: (PRINT (READ-FROM-STRING (AREF NAMES I) NIL NIL
> :STA
> RT 0)) should be a lambda expression" error?
>
>
You are trying to evaluate ((print (read-from-string ...)))
This is not valid syntax -- you have too many enclosing parens.
If the car of a form is itself a list then it must be a lambda expression
(which is why you get that error).
Parens in Lisp are *not* the equivalent of braces in C -- you can't
just slap another pair around a form and have it mean the same thing.
BTW, your paren layout there is really bad, and you've made the mistake of
setting an unbound variable (which will make it a special variable, which
you don't want; it's also redundant). You should write this something like this:
(defun lname (names)
(loop for i below (length names)
do (print (read-from-string (aref names i) nil nil :start 0))))
or, better,
(defun lname (names)
(loop for name across names
do (print (read-from-string name nil nil :start 0))))
Paul
"Paul F. Dietz" <·····@dls.net> writes:
> swoop wrote:
> > (defun lname(names)
> >
> > (setq i 0)
> >
> > (loop for i below (length names)
> > do (
> > (print (read-from-string (aref names i) nil nil :start 0))
> > )
> > )
> >
> > )
>
> ... and you've made the mistake of setting an unbound variable
> (which will make it a special variable, which you don't want; it's
> also redundant).
Actually, only the symbol-value of the symbol i will be set -- it will
not become special.
--
Janis Dzerins
If million people say a stupid thing, it's still a stupid thing.
Janis Dzerins <·····@latnet.lv> wrote in message news:<···············@gulbis.latnet.lv>...
> "Paul F. Dietz" <·····@dls.net> writes:
> > ... and you've made the mistake of setting an unbound variable
> > (which will make it a special variable, which you don't want; it's
> > also redundant).
>
> Actually, only the symbol-value of the symbol i will be set -- it will
> not become special.
My understanding is that it's simply undefined behavior. On some Lisps
the variable will in fact become special. On some others, an error is
signaled.
···@ashi.footprints.net (Kaz Kylheku) writes:
> Janis Dzerins <·····@latnet.lv> wrote in message news:<···············@gulbis.latnet.lv>...
> > "Paul F. Dietz" <·····@dls.net> writes:
> > > ... and you've made the mistake of setting an unbound variable
> > > (which will make it a special variable, which you don't want; it's
> > > also redundant).
> >
> > Actually, only the symbol-value of the symbol i will be set -- it will
> > not become special.
>
> My understanding is that it's simply undefined behavior. On some Lisps
> the variable will in fact become special. On some others, an error is
> signaled.
Somehow I thought that assignment to free variables in top-level is
different from assignment in non-top-level. So now I'll do my
homework and go read the spec.
--
Janis Dzerins
If million people say a stupid thing, it's still a stupid thing.
"Janis Dzerins" <·····@latnet.lv> wrote in message
····················@gulbis.latnet.lv...
> "Paul F. Dietz" <·····@dls.net> writes:
>
> > swoop wrote:
> > > (defun lname(names)
> > >
> > > (setq i 0)
> > >
> > > (loop for i below (length names)
> > > do (
> > > (print (read-from-string (aref names i) nil nil :start
0))
> > > )
> > > )
> > >
> > > )
> >
> > ... and you've made the mistake of setting an unbound variable
> > (which will make it a special variable, which you don't want; it's
> > also redundant).
>
> Actually, only the symbol-value of the symbol i will be set -- it will
> not become special.
Actually, I think that is a depends apon which implementation you are using
and sometimes the current bindings of implementation-specific special
variables. But regardless, it is not a good style, I don't know why the
don't teach LET at the beginning of these courses...and as stated above, the
i from (setq i 0) is never used.
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
"Coby Beck" <·····@mercury.bc.ca> writes:
> "Janis Dzerins" <·····@latnet.lv> wrote in message
> ····················@gulbis.latnet.lv...
> > "Paul F. Dietz" <·····@dls.net> writes:
> > >
> > > ... and you've made the mistake of setting an unbound variable
> > > (which will make it a special variable, which you don't want; it's
> > > also redundant).
> >
> > Actually, only the symbol-value of the symbol i will be set -- it will
> > not become special.
>
> Actually, I think that is a depends apon which implementation you are using
> and sometimes the current bindings of implementation-specific special
> variables. But regardless, it is not a good style, I don't know why the
> don't teach LET at the beginning of these courses...and as stated above, the
> i from (setq i 0) is never used.
Assigning to unbound variables is undefined behavior, cmucl has the
habit of declaring them special. From my .cmucl-init file:
(setf ext:*top-level-auto-declare* nil)
See also the documentation for this variable. I agree with Coby;
seeing top-level setq-forms in tutorials or books always makes me
cringe. See for example p. 24 in Sonya Keene's CLOS book.
Rudi
* Rudi Schlatte wrote:
> See also the documentation for this variable. I agree with Coby;
> seeing top-level setq-forms in tutorials or books always makes me
> cringe. See for example p. 24 in Sonya Keene's CLOS book.
Maybe in books, sometimes, but I think in anything that is showing
user-interactions with a REP loop, it's OK (and implementations ought
to not cause huge global effects by a top-level assignment in a
listener, though I agree completely that this is undefined
behaviour).
The reason I think this is that it's really unreasonable to expect
people to sit there saying `(DEFPARAMETER *MYVAR* ...)' every time
they want to catch some result in a listener. Yes, it's *correct* to
do this (but make sure you say DEFPARAMETER, because DEFVAR won't work
more than once...), but it's very painful, and I bet what people
actually *do* is use SETF. *Especially* since in most implementations
SETF won't cause a global special declaration...
I think there's a difference between the `conversational' style of
interacting with the system via a listener, and the more formal
`written' style of writing a program. Top-level SETFs of undeclared
variables should *definitely* not be encouraged in programs!
--tim
"swoop" <····@anon.edu> writes:
> (defun lname(names)
>
> (setq i 0)
>
> (loop for i below (length names)
> do (
> (print (read-from-string (aref names i) nil nil :start 0))
> )
> )
>
> )
Please learn proper formatting:
(defun lname (names)
(setq i 0)
(loop for i below (length names)
do ((print (read-from-string (aref names i) nil nil :start 0)))))
Hopefully your problem now becomes evident: Parens are not like
curly-braces or parens in C, you can't just add some extra for good
measure. This is at least syntactically correct:
(defun lname (names)
(setq i 0) ; This is a free reference to i, probably bogous.
(loop for i below (length names)
do (print (read-from-string (aref names i) nil nil :start 0))))
While this is probably somewhat closer to what you really mean:
(defun lname (names)
(loop for x across names
do (print (read-from-string x nil nil)))))
Also, "lname" provides no clues as to what the function does.
--
Frode Vatvedt Fjeld