I just install SLIME 2.0 (it's about time, as I was still runing the
alpha version).
I have this bit of code that is causing a warning; however the program
runs correctly, I just want to know why the warning is thrown, and what
I can do to stop it from happening. Here is the code:
(setf path (make-pathname :name "random2"))
(with-open-file (stream path :direction :output
:if-exists :supersede))
The warning is that variable "path" is undefined. As I mentioned the
program works correctly (ie, the random2 file is generated, and the
program's output goes there as expected). It is just annoying trying to
debug a problem that isn't there.
Philip Haddad
Philip Haddad wrote:
> I just install SLIME 2.0 (it's about time, as I was still runing the
> alpha version).
> I have this bit of code that is causing a warning; however the program
> runs correctly, I just want to know why the warning is thrown, and what
> I can do to stop it from happening. Here is the code:
>
> (setf path (make-pathname :name "random2"))
> (with-open-file (stream path :direction :output
> :if-exists :supersede))
>
> The warning is that variable "path" is undefined. As I mentioned the
> program works correctly (ie, the random2 file is generated, and the
> program's output goes there as expected). It is just annoying trying to
> debug a problem that isn't there.
>
> Philip Haddad
Yeah, because you've setf path outside the scope of with-open-file (but
I'm a n00b, so there's probably a more clear explanation). Do it in a
let and you won't get the warnings about it being unbound:
(let ((path (make-pathname :name "random2")))
(with-open-file (stream path :direction :output :if-exists
:supersede)))
··············@gmail.com wrote:
> Philip Haddad wrote:
> > I just install SLIME 2.0 (it's about time, as I was still runing the
> > alpha version).
> > I have this bit of code that is causing a warning; however the program
> > runs correctly, I just want to know why the warning is thrown, and what
> > I can do to stop it from happening. Here is the code:
> >
> > (setf path (make-pathname :name "random2"))
> > (with-open-file (stream path :direction :output
> > :if-exists :supersede))
> >
> > The warning is that variable "path" is undefined. As I mentioned the
> > program works correctly (ie, the random2 file is generated, and the
> > program's output goes there as expected). It is just annoying trying to
> > debug a problem that isn't there.
> >
> > Philip Haddad
>
> Yeah, because you've setf path outside the scope of with-open-file (but
> I'm a n00b, so there's probably a more clear explanation). Do it in a
> let and you won't get the warnings about it being unbound:
>
> (let ((path (make-pathname :name "random2")))
> (with-open-file (stream path :direction :output :if-exists
> :supersede)))
let doesn't work, I thought about that as well. make-pathname needs
setf, I believe.
Philip Haddad wrote:
> let doesn't work, I thought about that as well. make-pathname needs
> setf, I believe.
Sure it works. I think you may be using C-c C-c to compile? That
doesn't compile the whole file, just the top-level form at point. If
you use C-c C-k, it will compile and load the file and you won't get
any warnings using the let code in the above post. I just tried it and
got no warnings with the latest clisp.
··············@gmail.com wrote:
> Philip Haddad wrote:
> > let doesn't work, I thought about that as well. make-pathname needs
> > setf, I believe.
>
> Sure it works. I think you may be using C-c C-c to compile? That
> doesn't compile the whole file, just the top-level form at point. If
> you use C-c C-k, it will compile and load the file and you won't get
> any warnings using the let code in the above post. I just tried it and
> got no warnings with the latest clisp.
Yeah I noticed that if I load the x86f file there is no warning....
interesting....
"Philip Haddad" <·············@gmail.com> writes:
> I just install SLIME 2.0 (it's about time, as I was still runing the
> alpha version).
> I have this bit of code that is causing a warning; however the program
> runs correctly, I just want to know why the warning is thrown, and what
> I can do to stop it from happening. Here is the code:
>
> (setf path (make-pathname :name "random2"))
> (with-open-file (stream path :direction :output
> :if-exists :supersede))
>
> The warning is that variable "path" is undefined. As I mentioned the
> program works correctly (ie, the random2 file is generated, and the
> program's output goes there as expected). It is just annoying trying to
> debug a problem that isn't there.
As someone else pointed out, this is a perfectly legitimate warning
for the compiler to issue. You are indeed setting the value of an
undeclared variable. The fact that it works is beside the point -
that's why it's a warning and not an error.
I am writing separately to point out that this is not a warning thrown
from Slime. You can prove this to yourself by trying the same code
directly in whatever Lisp you are using without Slime in the way - the
same warning will result.
Use DEFVAR or DEFPARAMETER to declare the variable before you use SETF
on it. Which of those you use depends on your needs.
Ari Johnson wrote:
> "Philip Haddad" <·············@gmail.com> writes:
>
> > I just install SLIME 2.0 (it's about time, as I was still runing the
> > alpha version).
> > I have this bit of code that is causing a warning; however the program
> > runs correctly, I just want to know why the warning is thrown, and what
> > I can do to stop it from happening. Here is the code:
> >
> > (setf path (make-pathname :name "random2"))
> > (with-open-file (stream path :direction :output
> > :if-exists :supersede))
> >
> > The warning is that variable "path" is undefined. As I mentioned the
> > program works correctly (ie, the random2 file is generated, and the
> > program's output goes there as expected). It is just annoying trying to
> > debug a problem that isn't there.
>
> As someone else pointed out, this is a perfectly legitimate warning
> for the compiler to issue. You are indeed setting the value of an
> undeclared variable. The fact that it works is beside the point -
> that's why it's a warning and not an error.
>
> I am writing separately to point out that this is not a warning thrown
> from Slime. You can prove this to yourself by trying the same code
> directly in whatever Lisp you are using without Slime in the way - the
> same warning will result.
>
> Use DEFVAR or DEFPARAMETER to declare the variable before you use SETF
> on it. Which of those you use depends on your needs.
hm, you're right, but I always thought that it was bad practice to use
defvar or defparameter if you just need a variable for lexical scope (I
mean path is going to die after the function execution anyways right?)
"Philip Haddad" <·············@gmail.com> writes:
> Ari Johnson wrote:
> > "Philip Haddad" <·············@gmail.com> writes:
> >
> > > I just install SLIME 2.0 (it's about time, as I was still runing the
> > > alpha version).
> > > I have this bit of code that is causing a warning; however the program
> > > runs correctly, I just want to know why the warning is thrown, and what
> > > I can do to stop it from happening. Here is the code:
> > >
> > > (setf path (make-pathname :name "random2"))
> > > (with-open-file (stream path :direction :output
> > > :if-exists :supersede))
> > >
> > > The warning is that variable "path" is undefined. As I mentioned the
> > > program works correctly (ie, the random2 file is generated, and the
> > > program's output goes there as expected). It is just annoying trying to
> > > debug a problem that isn't there.
> >
> > As someone else pointed out, this is a perfectly legitimate warning
> > for the compiler to issue. You are indeed setting the value of an
> > undeclared variable. The fact that it works is beside the point -
> > that's why it's a warning and not an error.
> >
> > I am writing separately to point out that this is not a warning thrown
> > from Slime. You can prove this to yourself by trying the same code
> > directly in whatever Lisp you are using without Slime in the way - the
> > same warning will result.
> >
> > Use DEFVAR or DEFPARAMETER to declare the variable before you use SETF
> > on it. Which of those you use depends on your needs.
>
> hm, you're right, but I always thought that it was bad practice to use
> defvar or defparameter if you just need a variable for lexical scope (I
> mean path is going to die after the function execution anyways right?)
Pascal explains that you should use 'let', but I think his wording may
have been a tad ambiguous, and I wouldn't want you to walk away
without complete clarity on the situation...
If you do (setf path ...) and the symbol PATH does not name an
existing lexical or dynamic variable, a new dynamic variable will be
created with that name, and it will not die until you force it to.
This is, incidentally, precisely why the warning you are getting is
useful (and also why you should give your dynamic variables names
*like-this* with asterisks). Imagine you had the following:
(let ((path nil))
...
(setf path #p"random2")
...)
You won't get any warnings and the setf will operate on the lexical
variable. But imagine if you had a typo or if you changed the name of
the variable for some other reason...
(let ((pth nil))
...
(setf path #p"random2")
...)
Now you get a warning, which is what you want because you did not
intend to create a dynamic variable.
Pascal also correctly points out that doing a setf of an undefined
variable will do a defvar for you and spit out a warning in *most*
implementations, but that the standard does not require that behavior
and that launching an ICBM at your house is a standards-compliant
alternative behavior in this situation.
"Philip Haddad" <·············@gmail.com> writes:
> Ari Johnson wrote:
>> "Philip Haddad" <·············@gmail.com> writes:
>> > (setf path (make-pathname :name "random2"))
>> > (with-open-file (stream path :direction :output
>> > :if-exists :supersede))
> hm, you're right, but I always thought that it was bad practice to use
> defvar or defparameter if you just need a variable for lexical scope (I
> mean path is going to die after the function execution anyways right?)
Of course. While the above is not specified, most implementations
will do DEFVAR for you when you SETF an undefined variable (it's that,
or launching an ICBM on your house).
So the consequence will be to get a dynamic variable named PATH, which
can lead to "strange" bugs when you later try to use it lexically.
We've told you already how to write a lexical variable: use LET!
(let ((path (make-pathname :name "random2")))
(with-open-file (stream path :direction :output :if-exists :supersede)
(write 'stuff stream)))
--
__Pascal Bourguignon__ http://www.informatimago.com/
Kitty like plastic.
Confuses for litter box.
Don't leave tarp around.
Pascal Bourguignon <···@informatimago.com> wrote:
> Of course. While the above is not specified, most implementations
> will do DEFVAR for you when you SETF an undefined variable (it's that,
> or launching an ICBM on your house).
CMUCL is "most implementations"? AFAIK no other implementations will
proclaim the variable as special. They'll generally just set the
symbol-value.
--
Juho Snellman
Philip Haddad wrote, On 10/8/06 4:44 AM:
> (setf path (make-pathname :name "random2"))
> (with-open-file (stream path :direction :output
> :if-exists :supersede))
>
> The warning is that variable "path" is undefined
It is a warning because path is neither declared special or locally bound. The
warning catches typos such as
(defvar pathh) ;; <- this is a typo
(setf path (make-pathname :name "random2")
That's why it is a good idea to declare all variables that you use. Another
reason is so that you are not at the mercy of whatever happens to be in your
environment when you load and run your program -- You can see where and how
everything you use is initialized.
--
Sidney Markowitz
http://www.sidney.com