Oh boy.


(setf prog '((hax my anix) (dich snake) (LAIN)))
(pprint (third prog))

I... what?

>>2
    CL-USER> (pprint 'money)
   
    MONEY
    ; No value
    CL-USER>

>>1
Undefined behaviour detected.

>>4

No way dude

>>5
Yes, that SETF will expand into a SETQ, unless prog is a symbol macro, which it probably isn't. If prog was declaimed to be a special variable, either directly((DECLAIM (SPECIAL PROG))) or indirectly(DEFVAR/DEFPARAMETER), that SETF would not be undefined, it would also not be undefined if that statement was wrapped in a LET that had prog as a lexical variable. I'm not touching the problem of prog not having earmuff's if it is a special variable.

More details at http://www.lispworks.com/documentation/lw51/CLHS/Body/s_setq.htm . ``setq may be used for assignment of both lexical and dynamic variables.f any var refers to a binding made by symbol-macrolet, then that var is treated as if setf (not setq) had been used.'' Since prog has not been declared or defined anywhere as a lexical or special variable, nor as a symbol macro, the behaviour is undefined.

What will an implementation do when it encounters an undefined variable? Common cases are:
1. (setq var ...) gets treated as it would be (setf (symbol-value 'var) ...), which sets the symbol's value slot, without proclaiming/declaiming var as special. However, if you were to locally declare it special, you could access the value, or via (symbol-value 'var). Of course, such implementations may extend this by treating the undefined variable locally special, but not declaiming it globally special everywhere. It's a bit of a tricky issue. The reason for that expansion is that SETQ's name comes from SET QUOTED, which meant that SETQ was supposed to abbreviate the fairly common form(SET 'VAR ...) in old lisps (with only dynamic scope). SET still exists today and it more or less means the same as (setf (symbol-value ...) ...).
2. The other common treatmeant is the same as 1, but with proclaiming the variable globally special (CMUCL does this, I think SBCL removed this behaviour in their fork, but I'm not 100% sure). This is a bit more agressive as the next time someone uses that variable, it would be automatically considered special, thus altering the behaviour unadvertedly.

Another common thing to do is signal a WARNING that the variable is undefined and then proceed with setting the value slot of the global symbol. SBCL does this.

I didn't explain the local vs global declaration issue in the previous post.
The thing is that an implementation like SBCL will treat a variable as locally special only if it's undefined, without globally proclaiming it special. While, if the same variable is used within the lexical scope in another function, nothing would change. CMUCL could declare it globally special, which would affect other functions. SBCL's treatment is likely the most common and sanest (it also issues a warning each time you use an undefined variable), but since the behaviour is undefined, an implementation could just as well signal an error, which is worse, but still correct behaviour.

tl;dr: Don't do this, unless you understand what you're doing, but if you do understand, you'd already just use the proper forms, which specify EXACTLY what you meant, instead of leaving the implementation guessing/defaulting to some implementation-specific behaviour. It might be worth mentioning that one known CL book author (Paul Graham) has the habbit of abusing this behaviour, without chooshing to use well-defined behaviour. He even mentions that some implementations may treat the code wrong, without bothering to fix it...

I'm not touching the problem of prog not having earmuff's if it is a special variable.
Why I don't put asterisks on special variables
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Several people have asked me to clarify why I don't use the
*earmuff* convention for special variables, so here goes.

First of all, I'm not convinced that unexpected collisions
are unconditionally bad. The way I look at it, you always
learn something when you encounter a collision and you
never learn anything when you don't.

My instinct tells me that the earmuff convention is
dangerous, or at least that it isn't nearly as open-shut
an issue as everyone seems to think. For example, what
sort of binding is this?

(let (*hello*)
  ...)

It is a lexical binding because I haven't declared *hello*
to be special yet. But that's not what you thought when
you first looked at it, was it?

Or consider this: If you are dogmatic about the earmuffs,
why stop there? How about a print-name convention for
distinguishing between macros and functions? Instead of
with-open-file, we could call it ^with-open-file^ so that
we wouldn't need to remember that it is a macro instead of
a function. This convention would also reduce collisions
like accidentally trying to funcall a macro.

Would you use this convention? No, of course you wouldn't.
It's stupid. Instead of relying on a semantically meaningless
print-name convention, it is a better idea to just name
your macros and functions appropriately in the first place.

I consider both of these facts features:

* Invoking a function looks the same as invoking a macro.
* Binding a special variable looks the same as binding
  a lexical variable (with or without earmuffs).

Hope this helps clarify my reasoning,

Doug Hoyte
Strategic Lead API Designer, HCSW

PS. Come to think of it, not even the standard is dogmatic
about the earmuffs. There are at least 6 special variables
defined by ANSI that don't begin and end with asterisks.

>>8
Try not to impersonate other anon's. Not that I care much. (You put >>6 in the namefield).

Anyway, Doug Hoyte is fine to keep his own conventions, altough I prefer using the earmuffs as it helps distinguish between lexical and dynamic variables, whose behaviours are quite different. It's also a very widely accepted and respected CL tradition.
BTW, care to list those 6 special variables? I'm only aware of some constants which aren't marked with +...+ or *...*.

Don't change these.

Name:		Email:
Entire Thread Thread List