This looks awesome. Regarding the Array parameter issue (which I'm really glad to see in the linter; this issue really tripped me up when learning Julia), if https://github.com/JuliaLang/julia/issues/6984 ever finds a resolution, it would be great to suggest that new syntax in the lint message. Then if the linter becomes common-place, beginners that have never heard of type variance will have a path to understanding.
On Sunday, September 14, 2014 1:38:50 AM UTC-4, Tony Fong wrote: > > That's a good question. They can be used together, obviously. I can easily > speak for Lint. The key trade-off made in Lint is that it does not strive > for very in-depth type analysis. The focus is finding dodgy AST, where it > is located in the source file, and with a bit of explanation around issues. > The analyses are done recursively in a very small neighborhood around each > node in the AST, although the locality issue has improved somewhat with the > new type-tracking ability. The "type guessing and tracking" could leverage > Typecheck.jl, only possible since about last week (with the new features), > and it's a very exciting prospect. > > Lint already provides functionality to return an array of lint messages > (from a file, a code snippet, or a module), so it could be used in IDE > integration I suppose. > > Tony > > On Sunday, September 14, 2014 10:08:09 AM UTC+7, Spencer Russell wrote: >> >> Any comments on how Lint.jl and @astrieanna's also-awesome TypeCheck.jl >> relate? Are you two working together, or are there different use cases for >> the two libraries? >> >> >> peace, >> s >> >> On Sat, Sep 13, 2014 at 3:34 PM, Tony Fong <tony.h...@gmail.com> wrote: >> >>> Fellow Julians, >>> >>> I think it is time to post an update on Lint.jl >>> <https://github.com/tonyhffong/Lint.jl>, as it has improved quite a bit >>> from the initial version I started about 3 months ago. >>> >>> Notable new features >>> >>> - Local variable type tracking, which enables a range of features, >>> such as >>> - Variable type stability warning within a function scope. >>> - Incompatibility between type assertion and assignment >>> - Omission of returning the constructed object in a type >>> constructor >>> - Check the call signature of a selected set of methods with >>> collection (push!, append!, etc.) >>> - More function checks, such as >>> - repeated arguments >>> - wrong signatures, e.g. f( x::Array{Number,1} ) >>> - Mispelled constructor (calls new but the function name doesn't >>> match the enclosing type) >>> - Ability to silence lint warning via lintpragma() function, e.g. >>> - lintpragma( "Ignore unstable type variable [variable name]" ) >>> - lintpragma( "Ignore Unused [variable name]" ) >>> >>> Also, there is now quite a range of test scripts showing sample codes >>> with lint problems, so it's easy to grep your own lint warnings in that >>> folder and see a distilled version of the issue. >>> >>> Again, please let me know about gaps and false positives. >>> >>> Tony >>> >> >>
