Chalk it up to my ignorance, but really that should be a bug in symbol-macrolet. I intended it to be like CL. However, I do agree with you that the current semantics seem to be better in that they are more consistent with how other types of macros work (at least it seems that way to me, which is why I implemented it this way). I say let's leave it until we start getting complaints.
Vladimir
On 7/28/07, Red Daly reddaly@stanford.edu wrote:
Thanks for the bug report. A fix is in the darcs repository.
I also created a and also added a define-script-symbol-macro macro for top-level symbol macros.
However, upon some inspection it appears that Parenscript symbol macros work differently from Lisp symbol macros.
Consider the form (SYMBOL-MACROLET ({name macro-body}*) body). Lisp symbol macros expand not to the result of evaluating MACRO-BODY, but to MACRO-BODY itself:
(symbol-macrolet ((lisp-sym `(print "hello"))) lisp-sym) => (PRINT "hello")
Parenscript macros expand to the the evaluation of MACRO-BODY:
(script
(symbol-macrolet ((paren-sym `(print "hello"))) paren-sym))=> "javascript_print('hello');"
I prefer the Parenscript semantics, so we probably do not need to change anything. If anyone has other thoughts, let me know.
Red
Daniel Gackle wrote:
A js macro that evaluates to a string literal can't be used:
(defjsmacro blah () "abc") (js (blah)) => "null;"
This seems wrong. For one thing, other literals work fine:
(defjsmacro blah () 123) (js (blah)) => "123"
For another, Lisp behaves differently:
(defmacro blah () "abc") (blah) => "abc"
Dan
p.s. Actually, I'd rather use a symbol macro but it appears there is no define-symbol-macro in Parenscript and in this case symbol-macrolet is not convenient. _______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel