On Mon, May 21, 2012 at 1:43 PM, Jay Fields <j...@jayfields.com> wrote:
> There's a few issues there, first of which is that the code doesn't > evaluate to what's shown: > REPL started; server listening on localhost port 21867 > user=> > (if-let [a 1] > (if-let [b 2] > (if-let [c nil] > [a b c] > [a b c]) > [a b c]) > [a b c]) > java.lang.Exception: Unable to resolve symbol: c in this context > (NO_SOURCE_FILE:3) > > The c isn't nil in the else form, it's unbound. The same would be true if > it failed at any of the other levels, if the original if fails, a, b, & c > are all unbound. So, setting them to nil isn't consistent. It might be a > good option, but it's not consistent with the code above. I can't imagine > that you'd want the else statement to have a bunch of possibly nil vars for > any reason other than printing - otherwise you'd end up putting a bunch of > conditional logic in the else to know which vars are nil, in which case > you're better off using nested if-lets anyway. But, maybe the printing > (i.e. logging) scenario is reason enough to bind these variables. I'd > probably lean towards keeping them all unbound, as it's clear that each var > would be bound (if form) or unbound (else form), versus each var being > possibly truthy or nil in the else form. > > Yeah, I was typing theory code. However, "none defined in the else" doesn't fully match the "nested if-lets" behavior either. In the second if-let stanza, "a" would be bound in the else case. In any event, this is all just bike-shedding and illustrating that what appears "obvious" isn't necessarily. -- 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
