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
