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.
But, I don't feel strongly either way.
On Mon, May 21, 2012 at 1:32 PM, Borkdude <michielbork...@gmail.com> wrote:
> I guess it wouldn't hurt having them available in the else, even if people
> won't use them often.
>
> On Monday, May 21, 2012 7:11:05 PM UTC+2, Aaron Cohen wrote:
>>
>> On Wed, May 16, 2012 at 9:53 AM, Walter Tetzner <
>> robot.ninja.saus...@gmail.com**> wrote:
>>
>>> On Wednesday, May 16, 2012 9:16:29 AM UTC-4, Aaron Cohen wrote:
>>>>
>>>> Saying something is obvious and then using the word monad a paragraph
>>>> later is contradictory. ;)
>>>>
>>>> What should happen on the else branch of the if-let; which bindings are
>>>> in scope and what would be their values?
>>>>
>>>>
>>> None of the bindings should be available in the else branch, since there
>>> would be no way to know which will succeed before run-time.
>>>
>>
>> I actually think that having all the bindings available and just nil for
>> everything past the first failure would be more useful, and also matches
>> the intuition that it expands out to nested if-lets
>>
>> (if-let [a 1 b 2 c nil] [a b c])
>>
>>
>> (if-let [a 1]
>> (if-let [b 2]
>> (if-let [c nil]
>> [a b c]
>> [a b c])
>> [a b c])
>> [a b c])
>>
>> => [1 2 nil]
>>
> --
> 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 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
