[pro] About &aux

[Steve Haflich]

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é" <fahree at gmail.com> wrote:
> On 12 June 2011 10:00, Daniel Weinreb <dlw at 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)))
> , at 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 at common-lisp.net
> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20110612/f53c5aef/attachment.html>