I created a ticket and posted a patch:
http://dev.clojure.org/jira/browse/CLJ-1613
On 12 December 2014 at 08:35, Michał Marczyk wrote:
> (let [foo 1
>bar 2
>{:keys [bar foo]
> :or {foo 3 bar (inc foo)}} {}]
> {:foo foo :bar bar})
> ;= {:foo 3, :bar 4}
>
> (let [foo 1
>
Quoting Michael's Gist:
(let [{:keys [bar foo]
:or {foo 1
bar (inc foo)}} {}]
(assert (= foo 1))
(assert (= bar 2)))
The main problem I see with this is that I'd expect the foo in :or to
refer to any foo in the enclosing scope. As things stand, whether it
does or not depend
Common Lisp has a really well thought approach to parameter lambda lists.
If you feel strongly about resolving this ambiguity and enforcing
consistency around sequential binding in the destructuring syntax, perhaps
that would be a good place to root a design you can flesh out in Jira.
Here's a
Yep, I spent some time playing with the macro and the macroexpand. It looks
like
a) it only works if the dependent keys come *before* the keys they depend
on (ie the opposite of how you'd order, say, defs)
b) this ordering arises entirely from the seq ordering of
PersistentArrayMap (keys are stuc
Whenever you want to get insight in how a macro is rewriting your code, try
evaluating your form quoted with macroexpand.
Here's a gist with the macroexpansion each form.
https://gist.github.com/aamedina/542b084d31d4e0c9a7a8
Hopefully the expansion makes things clear!
On Thursday, December
I wouldn't have expected either form to work actually; It's interesting
that the first does. I would love someone else enlighten us on this, but my
guess is that it's something not specified and that you shouldn't rely on.
If you want to have optional argument defaults depend on each other, I
r
If I make my defaults on a :keys :or destructuring depend on the values of
other keys, I *can* get a compile-time error, depending on what order I
give the keys https://gist.github.com/MichaelBlume/4891dafdd31f0dcbc727
Is this on-spec behavior? Should the former be allowed but not the latter?
Shou
