I think what you need is something like code checker. You can check the package Lint.jl. This is an on-going work, so is not perfect yet.
On Wednesday, September 16, 2015 at 7:33:52 AM UTC+2, ivo welch wrote: > > > Julia is only at version 0.4 (well, soon). It's too soon to expect > miracles. :-). however, I want to restate an old suggestion. a language > should have as few surprises as possible. this applies not only to > features, but also to performance. > > http://julia.readthedocs.org/en/latest/manual/performance-tips/ contains > many gotchas. > > the language interpreter should eventually help non-julian experts with > the gotchas. that is, the knowledge in the page on julia performance > optimization should be in the compiler---even if just as a jit warning. > for example, global variables: julia could give a warning when it guesses > that the global variable could be rolled into a local function or that the > global variable looks like it may be constant. from what I see, similar > arguments can be made for abstract containers and others. (maybe a > language pragma would be helpful---unless turned off, help the novice!) > > common gotcha's come up again and again for a reason. this is why they > are on this julia page to begin with. my guess is that checking for > gotchas will probably mess up beautiful internal julia compiler-language > code (in tryomg to determine whether the julia user code likely has > gotchas), but we all hope that julia user code will be a lot more common > than julia compiler-language code. > > suggestion for julia version 1.4, perhaps. > > regards, /iaw > > PS: (R drove me nuts [=cost me days and days] to understand gotchas. for > example, I learned the hard way that changing one element in a data frame > creates complete copies, and thus slowed down my program by a factor of 100 > when large data frame were involved? I wasted the time of a lot of good > people on the R mailing lists. how should I have suspected this? even if > I had read the docs end to end, I would not have remembered them a few > weeks later. or, why is read.csv() in R not.data.frame(data.table:fread) ? > do I really want my users to have to learn this the hard way, given how > common it is?) > >
