IMO, :eastwood-arglist (and a proliferation of other tool-specific metadata) would be exactly the wrong approach; :arglists should be the real defn-form arglists. Instead there should be an optional :pretty-arglists for documentation generators to use in lieu of :arglists if it is present. That would address the documentation need while being tool-agnostic and not prone to grow like kudzu until sometime before 2020 we wind up usually writing defn forms like
(defn ^{:foo-arglists [a b & xyz] :special-tooly-stuff-count 42 :another-thingy-base /etc/data :another-thingy-defs /etc/data/.defs-file :miscellaneous-stuff-v1.1 :pure-function :miscellaneous-stuff-v2.0 #{:pure-function :noprims} :superduperoptionizer4 #{[a? b] [a? b jump? speed] [a? b jump? speed direction]} bar "docstring" ([&thingys] ...)) On Tue, Jan 14, 2014 at 12:56 AM, Andy Fingerhut <andy.finger...@gmail.com>wrote: > Nicola can answer more authoritatively, as I haven't checked that part of > tools.analyzer recently, but I am pretty sure that the :arglists with > things like doc-string? attr-map? are simply treated as if they were normal > positional arguments, with no 'guessing' that they are optional due their > symbols ending with a question mark. > > A function with :arglists ([x & xs]) is checked that it takes 1 or more > args, so only warning if a call is made with 0 args. That is why the > current release of Eastwood will give incorrect :wrong-arity warning > messages if one manually sets :arglists for a function to something other > than what defn would make it. > > For macros, they are all expanded during Eastwood analysis, so any > incorrect number of arguments should cause an exception to be thrown during > analysis, much like it would if you attempted to compile such code. > > Andy > > > On Mon, Jan 13, 2014 at 6:57 PM, Colin Fleming < > colin.mailingl...@gmail.com> wrote: > >> This is an interesting discussion, I've been thinking about some of these >> problems as I move towards adding inspections in Cursive. arglist parsing >> is a real problem in Clojure. I'd like to be able to flag invocations of >> functions with bad arities in the editor, but it's very difficult. Even >> defn is complicated, given that its :arglists is: >> >> :arglists '([name doc-string? attr-map? [params*] prepost-map? body] >> [name doc-string? attr-map? ([params*] prepost-map? body)+ >> attr-map?]) >> >> and its actual args declaration is: >> >> [&form &env name & fdecl] >> >> There's really no way to parse either of them automatically well. Does >> Eastwood use the actual fn declaration or :arglists for linting? What would >> it do in the case above? It's impossible to tell if doc-string? is a >> boolean or if it's an optional arg. >> >> Oh, and I agree that invalid :arglists as documentation is probably a bad >> idea, since it'll inevitably make this sort of tooling more difficult than >> it already is. >> >> >> On 14 January 2014 14:03, Sean Corfield <s...@corfield.org> wrote: >> >>> On Jan 13, 2014, at 3:09 PM, Nicola Mometto <brobro...@gmail.com> wrote: >>> > To be honest I don't like the idea of libraries attaching not-valid >>> > :arglists meta to Vars at all since the doc[1] for `def` says that >>> :arglists >>> > will be "a list of vector(s) of argument forms, as were supplied to >>> > defn" and the clojure Compiler uses :arglists for type-hints handling. >>> >>> I agree with you in principle - and I'm happy to change java.jdbc to >>> avoid the issue. >>> >>> Could Eastwood (or j.t.a) flag invalid :arglists? The "example" ones in >>> both java.jdbc and congomongo are clearly "invalid" according the special >>> forms page (but they silently "work"). Perhaps if Eastwood finds invalid / >>> suspicious metadata in :arglists, it could use a different linter warning? >>> >>> Sean Corfield -- (904) 302-SEAN >>> An Architect's View -- http://corfield.org/ >>> >>> "Perfection is the enemy of the good." >>> -- Gustave Flaubert, French realist novelist (1821-1880) >>> >>> >>> >>> >> -- >> -- >> 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/groups/opt_out. >> > > -- > -- > 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/groups/opt_out. > -- -- 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/groups/opt_out.