Timothy, I think maps vs keywords is a matter of preference. Certainly there are cases where I use maps of options instead of keywords, but it depends on what I'm doing. Lisp and keywords go way back, and I like keywords when I'm using lisp packages/namespaces as the equivalent of an interactive query language.
Even for the case of pure options passed as a map, you'll still potentially have cases where you might like to validate that only *expected* keywords were used. Whether a map as argument or a :as option to destructuring. And it's all well and good to let the user of those maps write code to enforce that. However in the traditional use of keywords naming formal parameters there's a long Common Lisp (at least) history of validating these bindings, and there's also compile time capabilities too, though perhaps less effectively in Clojure than CL. Clojure has provided these keyword capabilities, I just object to this one hole because it has zero up side that I can see, and substantial downside to writing correct programs. On Sun, Aug 23, 2015 at 10:12 AM, Timothy Baldridge <tbaldri...@gmail.com> wrote: > It's generally considered better practice to pass maps to a function > instead of keyword arguments. This also has the nice side-effect of making > it easier to call programmatically from other functions. For example: > > (my-func 1 2 (assoc default-opts :c 42)) is way cleaner than > > (apply my-func 1 2 (mapcat identity (assoc default-opts :c 42))) > > So don't do keyword argument, it rarely works out well. Instead accept a > map of options and validate it with asserts, ignoring "extra" data. A map > is a map, it shouldn't matter if it contains extra data. > > Timothy > > On Sat, Aug 22, 2015 at 7:21 PM, James Reeves <ja...@booleanknot.com> > wrote: > >> https://github.com/roomkey/annotate is another possibility >> >> - James >> >> On 23 August 2015 at 02:06, Colin Yates <colin.ya...@gmail.com> wrote: >> >>> Hi Dave, it _isn't_ an Illegal argument though :-), your destructuring >>> is simply ignoring that parameter. >>> >>> However, I get the pain and solutions might be (in order of 'heavyness'): >>> - http://blog.fogus.me/2009/12/21/clojures-pre-and-post/ >>> - https://github.com/Prismatic/schema >>> - http://typedclojure.org/ >>> >>> HTH >>> >>> Dave Tenny writes: >>> >>> > I sure wish Clojure would generate "IllegalArgumentException" in the >>> > following sample case: >>> > >>> > (defn foo [a b & {:keys [c d]}] 1) >>> > (foo 1 2 :e 5) ; blithely ignores :e 5 >>> > >>> > I understand that Clojure's destructuring things are very nice, and >>> more >>> > powerful than Common Lisp's, and I like >>> > that when I need it. >>> > >>> > However I can't tell you how many times I've been bitten by this. Some >>> > simple typo or other other parameter name error on keyword arguments >>> > with untended and way-too-long-to-debug consequences. >>> > >>> > In my mind, on this subject, Common Lisp lambda lists got this right >>> and >>> > Clojure gets a poor grade. >>> > Something about being doomed to repeat history. In Common Lisp, if you >>> > really wanted to allow other (arbitrary) keywords you'd >>> > just use &allow-other-keys. >>> > >>> > Maybe clojure should only allow the above case to go >>> un-complained-about if >>> > :as was specified for the map. >>> > >>> > If there's some automatic enforcement I'm missing that comes with >>> 'defn' >>> > please let me know, I'm still learning the language. >>> > >>> > I've thought more that once about making a common lisp DEFUN statement >>> that >>> > maps to DEFN but implements >>> > lambda list semantics (including 'supplied-p' parameters). I've just >>> been >>> > too lazy to do it. >>> > >>> > It would also likely perform poorly after injecting the additional >>> > checks/rearrangements into the function on top of what Clojure has >>> already >>> > done, >>> > so I suppose it would have to be taken a step further so that it didn't >>> > generate DEFN expressions at all but was implemented at DEFN's level as >>> > a seperately named form. >>> > >>> > Tips welcome. Just thinking aloud. >>> > >>> > - Dave >>> >>> -- >>> Sent with my mu4e >>> >>> -- >>> 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. >>> >> >> -- >> 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. >> > > > > -- > “One of the main causes of the fall of the Roman Empire was that–lacking > zero–they had no way to indicate successful termination of their C > programs.” > (Robert Firth) > > -- > 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 a topic in the > Google Groups "Clojure" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojure/3-CevvzQg1s/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > clojure+unsubscr...@googlegroups.com. > 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.
