What I dislike about &aux is that it encourages scoping a lexical variable around the entire lambda body. I prefer whenever possible to scope a local variable over the smallest region in which it is referenced. While this adds more let forms to the code, it makes the code easier to read. One knows the scope over which a variable may be used and need not eyeball the entirerty of a long function body ro be sure the variable isn't referenced somewhere distant.
&aux always reminds me of 40-year-old FORTRAN code where all variables were declared at the head of a function body, and were scoped over the entire body. A lot of more-recent C code is still like this, although modern interactive highlighting editors mitigate the unreadability somewhat. On Jun 12, 2011 8:10 AM, "Faré" <fah...@gmail.com> wrote: > On 12 June 2011 10:00, Daniel Weinreb <d...@alum.mit.edu> wrote: >> I, myself, really dislike &aux. It has been so long >> since I have seen it that I have forgotten that >> it even exists. We never use it; and I should >> add that to our style guide. >> > &aux has its uses. Sometimes it can be clearer than adding a let. > >> I don't even like >> >> (let (a b c) ...) >> > Same thing. If you're going to do side effects (sometimes you have to) > in particular when you need the binding to be visible in a scope > that starts before you have a useful value to initialize it with, > then it's clearer to say let (a) and make it clear > it's conceptually uninitialized than say let ((a nil)) > where nil is bogus and not even an admissible value for the > variable's intended type. See especially unwind-protect forms. > >> since I prefer to think of "let" in the Scheme sense >> of "I am naming the result of a computation." > Call that something else than let if you want, it's a useful idiom. > > Also, binding forms are annoying in that they are verbose > and move the body to the right as you nest them. > Instead of any ad-hoc do-it-all binding macro, > I like this macro from Marco Baringer that does nesting for you: > > (defmacro with-nesting ((&key) &rest things) > (reduce #'(lambda (outer inner) (append outer (list inner))) > things :from-end t)) > >> In >> fact, I added a macro to our library that is like >> "let" but does not allow the variable to be modified. >> (It's not portable; it uses a CCL-specific feature.) >> > Yet Pascal just offered a portable implementation! > > Here's mine. > > (defmacro read-only (value name) > (declare (ignore name)) > value) > (define-setf-expander read-only (value name &environment env) > (declare (ignore value env)) > (error "Thou shall not attempt to modify read-only variable ~S" name)) > > (defmacro let-1-constant ((var val) &body body) > (let ((s (gensym))) > `(let ((,s ,val)) > (symbol-macrolet ((,var (read-only ,s ,var))) > ,@body)))) > >> Unfortunately, we do not use it in practice, since >> it's so important for code style to be consistent >> and it would be very hard to change all our >> sources to do this, since it's hard to know from >> looking at code whether the "let" variable >> ever changes, and we have like 700MLOC >> of code in QRes. I wish Common Lisp had >> always had such a feature. >> > That's a bogus reason not to enact a style guide for *future* code. > You've even done it before. > >> Also, putting things in the parameter list that aren't >> parameters just feels weird. >> > See Hofstadter's "Le ton beau de Marot" about warts. > >> I do not think my own opinions are by any >> means "right". These are just my biases >> and preferences. >> > If you were sincere in this statement, then why share them? > > —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org > Multiple instances of a same hacker with different context in his mental > cache count as multiple hackers wrt documentation and testing needs. > > _______________________________________________ > pro mailing list > pro@common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro
_______________________________________________ pro mailing list pro@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro
