Even for those who don't need to be sold on Lisp macros, that was worth reading just for this sentence (in reference to C++ macros):
I forgot what rabid programming language fans are like; they can and will defend any system, no matter how dysfunctional, as long as it's _their_ dysfunctional sytem.
Higher Order Perl is a fantastic book, which makes a lot of functional concepts more immediately usable for non-Lisp dynamic language programmers (the example language is Perl, but there are projects on the web to convert the examples to other languages; the concepts apply across most of the popular dynamic languages).
The comma means to use the value of place there, instead of the literal symbol 'place'.
(Ironically, MJD made one of the same mistakes there he complained about in his C examples -- mentioning 'v' twice, which makes any side effects happen twice. Lisp macros are better than C's, but still require some care.)
defsetf turns that expression into whatever the defsetf expander for f1 returns -- it's up to the code.
> What does the comma right before place in its second usage signify?
It "punches a hole" in the quote: the ` in `(setf ,place (* v v)) says "don't evaluate this, this is a litteral value/list", but then the comma indicates "actually evaluate just this expression right here within the definition context" so ,place will be replaced by the value of the place argument. It's kinda equivalent to #{} in Ruby strings.
As others have pointed out, v should probably be unquoted as well.
The comma 'unquotes' the place variable so it is replaced with the value passed to the first argument on set-sqrt. I'm not in front of a lisp interpreter, but I think both those v's should be unquoted too in order to get the expected behavior ... (plus they are a bit leaky since they are evaluated twice, but that's just being pedantic).
I'm not a CL guy so I don't know how defsetf actually works, but I skipped down in that link to where that Lisp macro is, and if defsetf works like he describes (and I don't know if it does), then
(setf (f1 arg1) arg2)
will cause an error, but
(setf (sqrt arg1) arg2)
will expand into
(setf arg1 (* v v))
which, as you can see, is nonsensical in terms of what it looks like he was trying to do.
Yes, as has been pointed out, he is missing a pair of commas (or more correctly, a patch to ensure that v is evaluated once and only once --- right now it is evaluated 0 times, and adding 2 commas would make it eval twice. Using the definition of (square x) is the cleanest way to fix this).
The way I memorized it was to associate it with #{...} in ruby:
def my_gimme(thing)
gimme "select #{thing} from something"
end
Of course, in lisp, the "interpolation" (and macros in general) is structural: you can't use malformed strings to inject unexpected code like you could in my silly example.
Incidentally, Stuart Halloway uses this same Ruby syntax as pseudo-code when he first introduces macro syntax in his Programming Clojure book.
In short, macros are cool because, instead of hacking the compiler and groveling through its weird data structures to add language features, you can add language features in the language itself, because the language is already traditionally expressed in parse trees. Phrased this way, I don't see why this is a life-changing revelation.
I forgot what rabid programming language fans are like; they can and will defend any system, no matter how dysfunctional, as long as it's _their_ dysfunctional sytem.
:-)