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 resource you might find interesting as a starting point: http://www.lispworks.com/documentation/HyperSpec/Body/03_dad.htm
On Thursday, December 11, 2014 11:55:36 PM UTC-5, Michael Blume wrote: > > 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 stuck into the map here > https://github.com/clojure/clojure/blob/clojure-1.6.0/src/clj/clojure/core.clj#L4083 > > and taken out again here > https://github.com/clojure/clojure/blob/clojure-1.6.0/src/clj/clojure/core.clj#L4090 > ) > > The latter makes it pretty clear that this is accidental behavior and, as > you say, shouldn't be relied on -- in particular, if you have more than > about 8 keys, you spill over to a PersistentHashMap and get everything in a > random order and it almost certainly fails. > > The trouble is this behavior is already used by ring-middleware-format, > which then fails to compile if clojure uses a different implementation for > small maps. > > I'm wondering if given the brittleness of this behavior we should make > sure it can't be used in future versions of clojure. > > On Thu Dec 11 2014 at 6:56:22 PM <adrian...@mail.yu.edu <javascript:>> > wrote: > >> 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 11, 2014 6:11:59 PM UTC-5, Michael Blume wrote: >>> >>> 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? Should both be allowed? Should neither? >>> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@googlegroups.com >> <javascript:> >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com <javascript:> >> 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+u...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > -- 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/d/optout.
