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 <[email protected] 
> <javascript:>> 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
>>
>
>

Reply via email to