<div>A few months ago, Vladimir posted an email along with a rather dramatic new feature in Parenscript: the ability to dynamically rebind vars within a scope and have their original value restored on leaving the scope; in other words, Lisp-style special variables. As part of this change, "defvar" was redefined to declare this new kind of variable (invoking quite different behavior by the PS compiler under the hood). If you want old-fashioned JS variables you now need to say "var" instead. I both like and dislike this.</div>
<div> </div>
<div>What I like: the feature itself. One of the best things about Common Lisp is that we get the advantages of global variables without the pain. I had even written a ps macro to do something similar in a few cases. But those cases are rare. The vast majority of the time I <em>don't </em>want this behavior; I want plain JS variables. This is because I need runtime performance, ease of debugging, and and so on. </div>
<div> </div>
<div>I also like the idea of ordinary JS variables being declared using "var", not "defvar". That's because "var" reminds me that I'm dealing with JS scoping rules which are so different from Lisp's. It's also shorter.</div>
<div> </div>
<div>What I dislike: the use of the term "defvar" to declare the new type of variable. I'm skeptical for three reasons:</div>
<div> </div>
<div>1. The word "defvar" is very similar to "var", whereas the behavior of the two is very different;</div>
<div>2. "defvar" has a specific meaning in the Lisp world and it's not what PS is doing here. This is misleading. PS is not Lisp, and we shouldn't establish nominal equivalences where there isn't a semantic equivalence (or at least a close correspondence).</div>
<div>3. Lots of existing PS code says "defvar" to mean "var", all of which will now break. Actually, it's worse. It breaks in a few strange places, while silently compiling (but generating considerably more complex JS) most of the time.</div>
<div> </div>
<div>For these reasons I'm thinking we should keep the feature, but not use "defvar" for it. I'd suggest either "define-special-variable" or "defparameter". The former is verbose but explicit. The latter is more Lispy, addresses #1 and #3 completely and does a better job on #2. I guess I have a slight preference for "defparameter" for the somewhat embarrassing reason that it will be syntax highlighted in Emacs.</div>
<div> </div>
<div>This would then free up the term "defvar", allowing PS to apply the same policy here that was used in previous cases of name changes: keep the behavior the same as it was, but issue a "deprecated" warning specifying what the new term should be.</div>
<div> </div>
<div>Opinions?</div>
<div> </div>
<div>Daniel</div>
<div> </div>
<div><br> </div>
<div class="gmail_quote">On Mon, Dec 24, 2007 at 7:25 PM, Vladimir Sedach <<a href="mailto:vsedach@gmail.com">vsedach@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Instead of introducing a new special form or macro, I decided to<br>follow Common Lisp and make defvar define top-level special forms,<br>
which are automatically dynamically bound by let. Now you need to use<br>the special form 'var' if you just want to define regular globals.<br>This, and a few other minor things are now in the darcs repository<br>
(which should have sent a message to this group after my push, but I<br>guess I didn't configure it right, yet).<br><br>Merry X-mas,<br>Vladimir<br>
<div>
<div></div>
<div class="Wj3C7c"><br>On 11/6/07, Daniel Gackle <<a href="mailto:danielgackle@gmail.com">danielgackle@gmail.com</a>> wrote:<br>> Below is a ps macro that simulates the shadowing of special variables in<br>> Lisp. I'm wondering if anyone thinks this would be useful to add to<br>
> Parenscript.<br>><br>> I wrote it because I have some Javascript functions that reference global<br>> variables, and wanted to write some test functions for those without<br>> modifying global state. One option of course would be to simply write the<br>
> original functions to take parameters instead of the global variables. But<br>> that complicates their signatures and I'm loath to modify production code to<br>> suit tests. With this macro, my test can do this:<br>
><br>> (ps (shadow-let ((*global-var* "test value"))<br>> (function-that-uses-global-var)))<br>><br>> and the original value of *global-var* will be restored:<br>><br>> var _js3778 = null;<br>
> try {<br>> _js3778 = GLOBALVAR;<br>> GLOBALVAR = 'test value';<br>> functionThatUsesGlobalVar();<br>> } finally {<br>> GLOBALVAR = _js3778;<br>> };<br>><br>> Daniel<br>
><br>> ------------------------------------------------------------------------<br>><br>> (defpsmacro shadow-let (bindings &body body)<br>> (labels ((wrap-expr (bindings body)<br>> (if (null bindings)<br>
> body<br>> (list (list 'temporarily-bind (car bindings) (wrap-expr (cdr bindings)<br>> body))))))<br>> `(macrolet ((temporarily-bind ((var expr) body)<br>> (with-ps-gensyms (temp)<br>> `(progn (defvar ,temp nil)<br>
> (try (progn (setf ,temp ,var)<br>> (setf ,var ,expr)<br>> ,@body)<br>> (:finally (setf ,var ,temp)))))))<br>> ,(cons 'progn (wrap-expr bindings body)))))<br></div></div>> _______________________________________________<br>
> parenscript-devel mailing list<br>> <a href="mailto:parenscript-devel@common-lisp.net">parenscript-devel@common-lisp.net</a><br>> <a href="http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel" target="_blank">http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel</a><br>
><br>><br>_______________________________________________<br>parenscript-devel mailing list<br><a href="mailto:parenscript-devel@common-lisp.net">parenscript-devel@common-lisp.net</a><br><a href="http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel" target="_blank">http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel</a><br>
</blockquote></div><br>