Re: Eastwood lint tools - some Qs
Ah, I see - that makes sense, thanks. On 14 January 2014 19:49, Andy Fingerhut andy.finger...@gmail.com wrote: defn is a macro, and thus macro-expanded during Eastwood analysis, I believe ignoring the :arglists. I think it is really only the :arglists of functions that matter for Eastwood :wrong-arity warnings Andy On Mon, Jan 13, 2014 at 10:22 PM, Colin Fleming colin.mailingl...@gmail.com wrote: Interesting - but there must be some sort of magic there since otherwise every call to defn would be flagged, since its :arglists implies it has 6 arguments. And in fact, there's nothing there indicating that the body is in fact the body. On 14 January 2014 18:56, Andy Fingerhut andy.finger...@gmail.comwrote: 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
Eastwood lint tools - some Qs
Just started using this and I see the argslist caveat that causes Eastwood to misdiagnose :wrong-arity (the readme specifies java.jdbc 0.3.x but it also gets tripped up by congomongo). Can you (Andy or Jonas or any other Eastwood user) clarify how the arglists cause the problem and what, if anything, can be done in the source of java.jdbc and/or congomongo to alleviate the problem? Thanx, Sean -- -- 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.
Re: Eastwood lint tools - some Qs
Sean, it looks like the issue is caused by arglists like this one: https://github.com/clojure/java.jdbc/blob/master/src/main/clojure/clojure/java/jdbc.clj#L782-L783 tools.analyzer.jvm uses :arglists to detect possible invoke calls with a misplaced arity, expecting that to be a valid value, in your case for documentation purposes you are attaching a :arglists that does not match a valid list of args vector, so t.a.j interprets that as a 6-arity arglist. Nicola Sean Corfield (Clojure) writes: Just started using this and I see the argslist caveat that causes Eastwood to misdiagnose :wrong-arity (the readme specifies java.jdbc 0.3.x but it also gets tripped up by congomongo). Can you (Andy or Jonas or any other Eastwood user) clarify how the arglists cause the problem and what, if anything, can be done in the source of java.jdbc and/or congomongo to alleviate the problem? Thanx, Sean -- -- -- 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.
Re: Eastwood lint tools - some Qs
Thanx for the specific example! Yeah, I've used :arglists for examples in a couple of places instead of actual argument lists. I'll fix that in 0.3.3 and may do the same with CongoMongo (although it's a far worse culprit in several areas - and we're in the process of migrating to Monger now anyway). Sean On Jan 13, 2014, at 11:49 AM, Nicola Mometto brobro...@gmail.com wrote: Sean, it looks like the issue is caused by arglists like this one: https://github.com/clojure/java.jdbc/blob/master/src/main/clojure/clojure/java/jdbc.clj#L782-L783 tools.analyzer.jvm uses :arglists to detect possible invoke calls with a misplaced arity, expecting that to be a valid value, in your case for documentation purposes you are attaching a :arglists that does not match a valid list of args vector, so t.a.j interprets that as a 6-arity arglist. Nicola Sean Corfield (Clojure) writes: Just started using this and I see the argslist caveat that causes Eastwood to misdiagnose :wrong-arity (the readme specifies java.jdbc 0.3.x but it also gets tripped up by congomongo). Can you (Andy or Jonas or any other Eastwood user) clarify how the arglists cause the problem and what, if anything, can be done in the source of java.jdbc and/or congomongo to alleviate the problem? Thanx, Sean signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Eastwood lint tools - some Qs
Sean: Eastwood's current use of :arglists for :wrong-arity linter checking is definitely 'at odds' with the way java.jdbc and some other libraries use it for clearer documentation of fn/macro args. I would recommend leaving :arglists as-is for java.jdbc, and wait for the next version of Eastwood to add a capability to have something like an :eastwood-arglists for functions that explicitly replace their :arglists like this. Such a capability might best belong in Eastwood itself, since it is the new tool on the block. As an example, I was considering that if a fn/macro explicitly chose to be Eastwood-friendly in this way, it could have an :arglists and :eastwood-arglists explicitly, for those few vars that replace their :arglists. When one is using Eastwood with a library that they do not want to modify in that way, there could be some extra config file for Eastwood where one could specify these :eastwood-arglists. Thoughts? Andy On Mon, Jan 13, 2014 at 11:56 AM, Sean Corfield s...@corfield.org wrote: Thanx for the specific example! Yeah, I've used :arglists for examples in a couple of places instead of actual argument lists. I'll fix that in 0.3.3 and may do the same with CongoMongo (although it's a far worse culprit in several areas - and we're in the process of migrating to Monger now anyway). Sean On Jan 13, 2014, at 11:49 AM, Nicola Mometto brobro...@gmail.com wrote: Sean, it looks like the issue is caused by arglists like this one: https://github.com/clojure/java.jdbc/blob/master/src/main/clojure/clojure/java/jdbc.clj#L782-L783 tools.analyzer.jvm uses :arglists to detect possible invoke calls with a misplaced arity, expecting that to be a valid value, in your case for documentation purposes you are attaching a :arglists that does not match a valid list of args vector, so t.a.j interprets that as a 6-arity arglist. Nicola Sean Corfield (Clojure) writes: Just started using this and I see the argslist caveat that causes Eastwood to misdiagnose :wrong-arity (the readme specifies java.jdbc 0.3.x but it also gets tripped up by congomongo). Can you (Andy or Jonas or any other Eastwood user) clarify how the arglists cause the problem and what, if anything, can be done in the source of java.jdbc and/or congomongo to alleviate the problem? Thanx, Sean -- -- 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.
Re: Eastwood lint tools - some Qs
On Jan 13, 2014, at 2:05 PM, Andy Fingerhut andy.finger...@gmail.com wrote:
Eastwood's current use of :arglists for :wrong-arity linter checking is
definitely 'at odds' with the way java.jdbc and some other libraries use it
for clearer documentation of fn/macro args.
Google seems to indicate that :arglists is used for all sorts of documentation
clarifications and some libraries have pretty much arbitrary stuff in that
metadata, based on the fact that clojure.repl/doc and autodoc and other tools
don't parse it, they simply display it as-is :(
Sounds like Eastwood should ignore :arglists and just use the actual argument
lists for the arity check, with perhaps an additional lint warning for when
what's in :arglists doesn't match possible real signatures of the function? I
can see the latter being useful on its own sometimes.
As an example, I was considering that if a fn/macro explicitly chose to be
Eastwood-friendly in this way, it could have an :arglists and
:eastwood-arglists explicitly, for those few vars that replace their
:arglists. When one is using Eastwood with a library that they do not want to
modify in that way, there could be some extra config file for Eastwood where
one could specify these :eastwood-arglists.
I'm not sure how I feel about a potential explosion of tool-specific metadata.
Perhaps a single :eastwood map containing whatever flags are relevant for that
tool? So in this case :eastwood {:arglists '(...)} to provide arglists-specific
data to Eastwood which would also be a good place to add a way to exclude
specific linters on a per-fn basis?
It found three bugs in our code on the first run so I'm figuring out a way to
integrate it into our build as an additional QA step now :)
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)
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: Eastwood lint tools - some Qs
Sean Corfield writes: Sounds like Eastwood should ignore :arglists and just use the actual argument lists for the arity check, with perhaps an additional lint warning for when what's in :arglists doesn't match possible real signatures of the function? I can see the latter being useful on its own sometimes. There's no way other than inspecting :arglists to determine the signature of a function. Eastwood *could* add a pass to put the arg vectors of defn forms in an atom and use that to check for wrong arities, but this would work only for functions that get analyzed by tools.analyzer.jvm, this means that it wouldn't report the warning for i.e. calls to a function from a dependency. 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. [1]http://clojure.org/special_forms#Special%20Forms--(def%20symbol%20init?)%20 Nicola -- -- 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.
Re: Eastwood lint tools - some Qs
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) signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Eastwood lint tools - some Qs
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.
Re: Eastwood lint tools - some Qs
Actual arglists have a set structure and can be parsed automatically: https://github.com/bwo/macroparser/blob/master/src/macroparser/bindings.clj It's true that you couldn't reconstruct something as informative as the :arglists metadata on defn from the actual declaration, of course. On Mon, Jan 13, 2014 at 6:57 PM, Colin Fleming colin.mailingl...@gmail.comwrote: 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. -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] -- -- 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.
Re: Eastwood lint tools - some Qs
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.comwrote: 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.
Re: Eastwood lint tools - some Qs
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.comwrote:
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
Re: Eastwood lint tools - some Qs
Interesting - but there must be some sort of magic there since otherwise every call to defn would be flagged, since its :arglists implies it has 6 arguments. And in fact, there's nothing there indicating that the body is in fact the body. On 14 January 2014 18:56, 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
Re: Eastwood lint tools - some Qs
defn is a macro, and thus macro-expanded during Eastwood analysis, I believe ignoring the :arglists. I think it is really only the :arglists of functions that matter for Eastwood :wrong-arity warnings Andy On Mon, Jan 13, 2014 at 10:22 PM, Colin Fleming colin.mailingl...@gmail.com wrote: Interesting - but there must be some sort of magic there since otherwise every call to defn would be flagged, since its :arglists implies it has 6 arguments. And in fact, there's nothing there indicating that the body is in fact the body. On 14 January 2014 18:56, 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. --
