I'm not sure I understand this, but it seems to me that special
variables can override parameter values in defun functions. If I set
up this variable and two functions:
(defvar *x* 10)
(defun a (*x*) (b))
(defun b () *x*)
When I enter (a 4) I get:
1. Trace: (A '4)
2. Trace: (B)
2. Trace: B ==> 4
1. Trace: A ==> 4
4
[40]> *x*
10
This seems to imply that the parameter call to a (ie *x*) is
remembered when function b is called, but forgotten about after a
terminates. In other words *x* in b knows about the parameter getting
the value 4, even though it doesn't get it directly.
Is this correct?
If so it seems care needs to be taken when defining parameter values
to make sure their names don't conflict with any special variables
that have been set up.
I hope the above makes sense -- it goes against what I would have
intuitively expected, with function parameters 'protected' by being
local to the function. I would have expected the *x* value in a to be
ignored, and b to print out 10 as if nothing had been passed to a.
On Aug 5, 4:28 pm, "webmasterATflymagnetic.com"
<·········@flymagnetic.com> wrote:
> I'm not sure I understand this, but it seems to me that special
> variables can override parameter values in defun functions.
[snip]
> Is this correct?
Yes.
>
> If so it seems care needs to be taken when defining parameter values
> to make sure their names don't conflict with any special variables
> that have been set up.
Yes.. that's why we name special variables with *earmuffs*, and why
you should never (well, rarely) use *earmuffs* for function
parameters!
>
> I hope the above makes sense -- it goes against what I would have
> intuitively expected, with function parameters 'protected' by being
> local to the function. I would have expected the *x* value in a to be
> ignored, and b to print out 10 as if nothing had been passed to a.
Whatever evaluation model you've built up to expect that, tear it
down. Special variables are globally special. There is nothing special
about defun... it's just LAMBDA, as is LET.
Cheers,
drewc
On 6 Aug, 00:48, Drew Crampsie <·············@gmail.com> wrote:
> On Aug 5, 4:28 pm, "webmasterATflymagnetic.com"
>
> Whatever evaluation model you've built up to expect that, tear it
> down. Special variables are globally special. There is nothing special
> about defun... it's just LAMBDA, as is LET.
Thanks! I thought I was losing it! I know Lisp means you need to turn
your brain inside-out, but then you can write code in 3 lines rather
than 30. (And it's taking a long time to undo all those years of C and
Java.)
But I _am_ beginning to see why Lisp is cool!!
Thanks again,
>
> Cheers,
>
> drewc
Drew Crampsie <·············@gmail.com> wrote:
+---------------
| <·········@flymagnetic.com> wrote:
| > If so it seems care needs to be taken when defining parameter values
| > to make sure their names don't conflict with any special variables
| > that have been set up.
|
| Yes.. that's why we name special variables with *earmuffs*, and why
| you should never (well, rarely) use *earmuffs* for function
| parameters!
+---------------
The one place where I have sometimes found this behavior useful
is for functions with a stream parameter, where the function would
really like for all its default output *and* the output of other
functions it calls to go to the stream parameter. One can trivially
accomplish this by using the symbol *STANDARD-OUTPUT* for the
stream's formal parameter, e.g.:
> (defun bar ()
(format t "Hello, world!~%"))
BAR
> (bar)
Hello, world!
NIL
> (defun foo (*standard-output*)
(format t "Guess where this text goes?~%")
(bar)
(format t "And where did BAR's text go?~%"))
FOO
> (with-output-to-string (s)
(foo s))
"Guess where this text goes?
Hello, world!
And where did BAR's text go?
"
>
Or an even simpler approach:
> (with-output-to-string (*standard-output*)
(bar))
"Hello, world!
"
>
In practice, a somewhat safer style might be to use a keyword
parameter with the defaults set up so that *STANDARD-OUTPUT* is
not disturbed if the stream parameter is not provided, e.g.:
> (defun foo (&key ((:stream *standard-output*) *standard-output*))
(format t "Guess where this text goes?~%")
(bar)
(format t "And where did BAR's text go?~%"))
FOO
> (foo)
Guess where this text goes?
Hello, world!
And where did BAR's text go?
NIL
> (with-output-to-string (s)
(foo :stream s))
"Guess where this text goes?
Hello, world!
And where did BAR's text go?
"
>
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
In article
<····································@z6g2000pre.googlegroups.com>,
Drew Crampsie <·············@gmail.com> wrote:
> On Aug 5, 4:28 pm, "webmasterATflymagnetic.com"
> <·········@flymagnetic.com> wrote:
> > I'm not sure I understand this, but it seems to me that special
> > variables can override parameter values in defun functions.
> [snip]
> > Is this correct?
>
> Yes.
>
> >
> > If so it seems care needs to be taken when defining parameter values
> > to make sure their names don't conflict with any special variables
> > that have been set up.
>
> Yes.. that's why we name special variables with *earmuffs*, and why
> you should never (well, rarely) use *earmuffs* for function
> parameters!
>
> >
> > I hope the above makes sense -- it goes against what I would have
> > intuitively expected, with function parameters 'protected' by being
> > local to the function. I would have expected the *x* value in a to be
> > ignored, and b to print out 10 as if nothing had been passed to a.
>
> Whatever evaluation model you've built up to expect that, tear it
> down. Special variables are globally special.
Unless you declare local variables to be special or declare
variables to be locally special.
CL-USER 34 > (defun foo (vs1) (declare (special vs1)) (bar vs1))
FOO
CL-USER 35 > (defun bar (vs2) (let ((vs1 41)) (baz (+ vs1 vs2))))
BAR
CL-USER 36 > (defun baz (vs3) (values (locally (declare (special vs1)) vs1) vs3))
BAZ
CL-USER 37 > (foo 1)
1
42
In FOO vs1 is a special local variable.
In BAR within the LET, vs1 is a lexical variable. Not special,
since VS1 not globally declared to be special.
In BAZ within locally VS1 is a special variable.
If one calls FOO, the value of VS1 in BAZ is the value of
VS1 in FOO. Since the LET VS1 in BAR is lexical, its value
is not not used when the value for vs1 is determined within
BAZ.
> There is nothing special
> about defun... it's just LAMBDA, as is LET.
>
> Cheers,
>
> drewc
--
http://lispm.dyndns.org/
Thanks all for your replies.
I asked the question after puzzling over the GPS code in Novig's
Paradigms of Artificial Intelligence Programming, where he uses it but
doesn't describe why the parameter is not called in the function.
I now know how it works.
And reading on I've also found out he tells you 15 pages on! Oh
well...
Thanks again for your time.