On Jun 12, 2011 8:10 AM, "Faré" <fahree@gmail.com> wrote:
> On 12 June 2011 10:00, Daniel Weinreb <dlw@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