Hi Daniel -- Sorry that your query has languished a bit. I'm not particularly familiar with godoc's static analysis features, and anything that requires me to go read something tends to get bumped down a level on the stack.
Assuming that by 'static' you mean 'compile-time', then I think it is the case that Chapel already has static analysis capabilities since it is a statically-compiled (rather than interpreted or JIT'd) language. So maybe I'm not understanding the question. For example, Chapel does do type analysis and callgraph analysis as part of its compilation process. Perhaps what you're asking is whether we expose such information to the user through a GUI as in the Go examples, in which case we don't (because we don't have a GUI). So, such information is currently reflected only in the form of error messages and compiler-driven optimizations. Let me stop there for now in the interests of getting a response back to you and not presuming too much about the direction that you were asking about. Thanks for your interest in Chapel, -Brad On Tue, 29 Jul 2014, Daniel Moniz wrote: > Hello Chapel developers, > > This is probably a premature question, but has any thought been given > and/or is there any appetite for adding static analysis capabilities > into the stock Chapel toolchain? > > I'm interested in static analysis generally (across a number of > languages, and for a host of reasons), but the main influence that > prompted me to ask the question in regards to Chapel come from the > (currently experimental) static analysis features that were recently > added to the Go language (version 1.3; in the form of additional > features in the "godoc" tool, packaged with the stock Go toolchain > distribution; see [1] for more info.) > > I could see static analysis features being useful for both documentation > and code navigation purposes, as well as more "under the hood" purposes > relating to potential optimizations, spotting performance bottlenecks, > possibly better codegen on heterogenous architectures (I betray one of > my other longer-term goals here, in that I'm interested in seeing if > there's a possible sweet spot with Chapel and workflows where some > computation is pushed off onto FPGAs), etc. However, I confess I don't > know Chapel well-enough to know what's been done on this front so far, > nor what the challenges are or where is the best place in the current > Chapel "stack" to implement any such features. I presume there might be > things that could be borrowed from the tooling built up around LLVM, at > least where Chapel is built with LLVM codegen, but this seems like it > would be down a notch semantically than would be ideal. > > > Footnotes: > > [1] "Static analysis features of godoc" > http://golang.org/lib/godoc/analysis/help.html > > > > > -- > Daniel Moniz <[email protected]> [http://pobox.com/~dnm/] > > > ------------------------------------------------------------------------------ > Infragistics Professional > Build stunning WinForms apps today! > Reboot your WinForms applications with our WinForms controls. > Build a bridge from your legacy apps to the future. > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk > _______________________________________________ > Chapel-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/chapel-developers > ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk _______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
