On Sun, Nov 23, 2014 at 6:02 AM, Christian Peel <[email protected]> wrote:
> Milan, > > Thanks for the comments. I also am confident that info about what line > errors occur on will improve. > For some context, the reason traditional dynamic systems like e.g. Matlab or Python, don't have this issue is that they use interpreters and literally walk through a fairly faithful representation of the code you wrote, including line number annotations. Thus, when an error occurs, it's a trivial matter to report the line number you are currently interpreting – the parsed code representation is the exact thing you're operating on when the error occurs. Moreover, to give a full stack trace, you simply need to walk back through the stack data structure that the interpreter maintains as it executes the program. In a JIT system like Julia, things are quite different. By the time your code is running, it no longer closely resembles the code you wrote and there is no interpreter and the "stack" is the actual stack. All of this is what gives you C-like performance. When an error occurs, the error message and stack trace have to be determined from the machine code that is currently executing and the stack trace is derived from *the* stack, not some data structure. All this is further complicated by the fact that LLVM's JIT does not tend to produce debug data quite as well as the static compilation infrastructure does. People don't seem to use debuggers on JITed code or particularly care about backtraces, so we're pushing the envelope here, but things are getting better quite steadily. > You asked about a specific example of catching errors early. I just meant > that running something like Lint as part of the 'include' command could > help improve the speed of the edit-compile-test cycle. I don't have any > examples, I just wanted to suggest a place (the include function) where > syntax errors could be caught. > There are two relevant packages: - https://github.com/tonyhffong/Lint.jl - https://github.com/astrieanna/TypeCheck.jl These packages provide a lot of the kind of static code analysis that I think you're interested in. In the future, I'd like to integrate these into the standard library so that running checks on your code when you want to is trivial and universally accessible (rather than requiring installing packages).
