Really, an ERROR? Could you show the actual message that was printed? You can't, because you did not even bother to try.
Here is an actual test:
(defun square (x)
(* x x))
(defmacro hypotenuse (x y)
`(sqrt (+ (square ,x) (square ,y))))
;; whatever
(defun make-square (s) (list :square s))
(defun foo (s)
(let* ((square (make-square s))
(diagonal (hypotenuse s s)))
diagonal))
Now, let's compile (SBCL):
; caught STYLE-WARNING:
; The variable SQUARE is defined but never used.
Not really what you expected, right?
(foo 10)
=> 14.142136
It looks like it works.
You are trying to apply Scheme's semantics to CL. You forgot to take into account CL namespaces, which consist of (1) function/classes/type/variable namespaces and (2) namespaces defined by packages (or custom mappings).
> namespace n. 1. bindings whose denotations are restricted to a particular kind. ``The bindings of names to tags is the tag namespace.'' 2. any mapping whose domain is a set of names. ``A package defines a namespace.''
If you defined a local function named square, that could have been the beginning of a point. However, I don't buy the idea that inside a single package, someone is going to shadow a function that belongs to the same package, in a macro (if this happens, it is more likely to be done on purpose).
As for shadowing function bindings from other packages, this is even more improbable.
Please check your facts and avoid posting made-up error messages that can easily be mistaken for actual ones.
I'm not trying to be critical of CL. I thoroughly enjoy working in CL. I'm just trying to clear up some confusion about what it means for a macro to be hygienic, that's all.
> And how can I believe you? this is just too late.
Huh?
> You were spreading confusion by using a dialect of Lisp known only by you, that looked exactly like CL, without giving proper warnings.
It's a hypothetical example meant to illustrate an aspect of macro hygiene. Again, it's not a criticism of CL. Also, it's not "a dialect of Lisp known only by me". It happens to be EuLisp, which is what I've been working with lately, and I chose it because it was designed as a mix between CL and Scheme (and Le-Lisp, RIP) and I figured that, as such, it would be accessible to both Lispers and Schemers. Apparently, I was wrong.
> Fine, but this would have been the same if you used a nebulous "Scheme" without saying it so.
The specific language was irrelevant to my point. Only the semantics of defmacro and gensym were relevant.
> > And how can I believe you? this is just too late.
> Huh?
See it from my point of view: for all I know, you could as well have made an error, then pretended you were not really writing in CL but a nebulous Lisp; hours laters, after having looked around in the archives, you come back and say "It was actually EuLisp". I am not really saying you actually did this, but I am not ready to believe all you say blindly either. Clarifying things up front would have been way more credible.
> Also, it's not "a dialect of Lisp known only by me". It happens to be EuLisp [...]. I figured that, as such, it would be accessible to both Lispers and Schemers. Apparently, I was wrong.
EuLisp is accessible to both Lispers and Schemers, but you can't blame readers for not guessing what you have in mind when you aren't precise enough in your writings.
> The specific language was irrelevant to my point. Only the semantics of defmacro and gensym were relevant.
Except your example depends on other things than defmacro and gensym, and those things depend on the actual language you use, which makes the language not irrelevant. Simply saying "Take this EuLisp code...", or "assuming a Lisp-1 dialect..." would have prevented the confusion that would necessarily arise. I wonder why you did not just say that.
I apologize for causing so much confusion. My comment wasn't clear at all and I failed to communicate precisely what I intended. Thank you for your critique. I will take it to heart and try to improve my written communication in the future.
On that last point, you give the semantics of defmacro as defining "a function that receives an s-expression, manually deconstructs and transforms the s-expression".
You then exemplify that with (defmacro hypotenuse (x y) ...) which features automatic destructuring that pulls out x and y. The macro needs to do no further manual destructuring on these arguments.
You're right. I was thinking about Scheme when I wrote part of that comment, EuLisp in another part, Common Lisp in another, Le-Lisp in yet another, and my writing wound up being pretty muddled. I apologize for the confusion. I need to work on improving the clarity of my communication. Part of the problem is that I view comments on the Web very casually, a conversation, but that's not really the right way to approach it due to the differences in format. Anyway, thanks.
P.S., I was playing with TXR a bit last week after you mentioned it in another thread on here somewhere. After I got to the web site, I recognized it and recalled playing with it a tiny bit quite some time ago (at least a year ago, possibly much longer). Anyway, it's really neat. If I get some spare time sometime soon, I'm going to try and pick it up a bit more because it seems like the kind of thing that will come in very handy at the command line.
The ideas in TXR seem really novel to me. Did you come up with that form of pattern language, or did you nab it from somewhere else? The closest thing I can think of is SNOBOL, but TXR is much nicer to use than SNOBOL.
The idea for the TXR extraction language came from simply wanting to do the inverse of what "here document" interpolation does: have some text with variables, and have that match a similar text, binding pieces to the variables. I had a passing familiarity with pattern matching (as in logic programming) without much actual experience using or coding that sort of thing. I wasn't aware of how SNOBOL works, and also wasn't aware of PEGs. I just started implmenting and adding ideas as they occurred to me.
The pattern language is basically equivalent to PEGs, which can be seen from the examples of arithmetic expression and JSON parsing.
When I added functions, and hence recursion, I knew that the matching would increase in theoretical power from just regular languages to context-free. But only when I used it to implement some parsing it hit me that the code is basically just grammar rules that execute. After that when I encountered PEGs in some paper, the material was obvious.
Someone told me some years ago that it reminded them of SNOBOL in some ways. That made me curious, so that I researched SNOBOL a bit.
The directives which capture or assert a chracter or line position might have been influenced by SNOBOL. :)
You are trying to apply Scheme's semantics to CL. You forgot to take into account CL namespaces, which consist of (1) function/classes/type/variable namespaces and (2) namespaces defined by packages (or custom mappings).
> namespace n. 1. bindings whose denotations are restricted to a particular kind. ``The bindings of names to tags is the tag namespace.'' 2. any mapping whose domain is a set of names. ``A package defines a namespace.''
(http://clhs.lisp.se/Body/26_glo_n.htm)
If you defined a local function named square, that could have been the beginning of a point. However, I don't buy the idea that inside a single package, someone is going to shadow a function that belongs to the same package, in a macro (if this happens, it is more likely to be done on purpose). As for shadowing function bindings from other packages, this is even more improbable.
Please check your facts and avoid posting made-up error messages that can easily be mistaken for actual ones.