In CL, `let*` works like Clojure's `let`, in that both allow you to bind
later variables to valued calculated from earlier ones. (CL's `let` only
allows references to things defined before entering the `let`.) A couple
of years ago I was hacking on some CL code originally written by someone
else, with a lot of `let*`s in it. I started adding bindings, and them
more, and after a while I just could not make it work. The order of
bindings was crucial, and the right hand sides were referring to multiple
variables bound elsewhere in the `let*`. It was driving me crazy. I
realized that the whole thing I'd created was an instance of bad coding
style. I just pulled things apart and put the code into separate
functions that called each other. And I replaced all of my `do*`s (loops
with bindings that can refer to each other) with `mapcar` or `mapc` (like
Clojure's `map`). Much clearer.
I now try to avoid `let*` as much as possible in CL, and when I use it, I
make sure that I keep things simple. I'm just learning Clojure. I'm not
going to avoid `let`, but I will try to make sure that I use it carefully.
I agree with other posters here that sometimes code is clearer and easier
to understand if it's broken into sequential bindings, but it depends. I
think that often it's better to use a series of separate function calls
instead of a big `let`. I would say that for me, a good rule of thumb is
that a `let` should bind no more than four or five variables, maximum, and
that if there are more variables, their rhs's should usually refer only to
the variable defined on the previous line. Otherwise it's too hard to keep
track of the dependencies.
Maybe the right thing to say is: Follow PG's rule, except when it's better
to break it. And then keep it simple.
Those aren't rules that anyone else has to follow, of course. Do what
works for you. This is how I think about it.
On Tuesday, October 15, 2013 7:29:29 AM UTC-5, Daniel Higginbotham wrote:
>
> I've been going through On Lisp by Paul Graham and on page 33 he
> recommends against performing "intermediate" bindings. Does this advice
> hold for Clojure? Here are a couple examples:
>
> ;; Common Lisp (from the book)
> (defun bad (x)
> (let (y sqr)
> (setq y (car x))
> (setq sqr (expt y 2))
> (list 'a sqr)))
>
> (defun good (x)
> (list 'a (expt (car x) 2)))
>
> ;; Clojure
> (defn bad [x]
> (let [y (first x)
> sqr (expt y 2)]
> (list 'a sqr)))
>
> (defn good [x]
> (list 'a (expt (first x) 2)))
>
> Paul Graham explains:
>
> "The final result is shorter than what we began with, and easier to
> understand. In the original code, we’re faced with the final expression
> (list 'a sqr), and it’s not immediately clear where the value of sqr comes
> from. Now the source of the return value is laid out for us like a road
> map.
>
> The example in this section was a short one, but the technique scales up.
> Indeed, it becomes more valuable as it is applied to larger functions."
>
> In clojure you can't do setq of course but I find myself going against
> this advice all the time, and I find that it's more important to do so when
> working with larger functions. I think introducing names makes code
> clearer. Here's an example from my own code:
>
> (defn create-topic
> [params]
> (let [params (merge params (db/tempids :topic-id :post-id :watch-id))
> topic (remove-nils-from-map (c/mapify params mr/topic->txdata))
> watch (c/mapify params mr/watch->txdata)
> post (c/mapify params mr/post->txdata)]
> {:result (db/t [topic post watch])
> :tempid (:topic-id params)}))
>
> To my mind, creating bindings for "topic", "watch", and "post" makes the
> code easier to understand. When you get to "(db/t [topic post watch])" you
> don't have to deal with as much visual noise to understand exactly what's
> going into the transaction.
>
> So, is PG's advice any good?
>
> Thanks!
> Daniel
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
