Add Support for Common Chapel Idioms

[LouisJenkinsCS]

Currently only a limited number of statements/expressions are shown in auto-completion, but I see this as a massive opportunity to support more common Chapel idioms.

Common Idioms

Spawn on task per locale

coforall loc in Locales do on loc {

} 

SPMD: one task per core per locale

coforall loc in Locales do on loc {
   coforall tid in 1..here.maxTaskPar {

   }
}

Data-Parallelism

forall a in A {

}

The iterable used can be based on what is in scope.

@bradcray

Any suggested idioms? I think this is a rather exciting start. @bradcray What do you think are the most useful Chapel idioms?

[AnubhavUjjawal]

@bradcray @LouisJenkinsCS There is only one snippet listed here https://github.com/chapel-lang/chapel-tmbundle/tree/master/Snippets . VSCode directly supports integration with textmate snippets https://code.visualstudio.com/api/language-extensions/snippet-guide#using-textmate-snippets . Should I create .tmSnippet files for this ? The snippets I would create could be added to both https://github.com/chapel-lang/chapel-tmbundle and the VSCode extension I would work on. Could we handle files duplication here ?

[AnubhavUjjawal]

[LouisJenkinsCS]

Nice job!

[bradcray]

This is cool! I find it hard to come up with "standard idioms" that people use and think it would be more helpful to help with syntactic patterns that might be unfamiliar. For example, if I were to type fora<TAB> I'd be less interested in the tool trying to guess which forall loop form I was about to type and more focused on reminding me that the main forms of forall loops are forall <idx> in <expr> do ..., forall <idx> in <expr> { ... }, forall <tupleIdx> in zip(<expr1>, <expr2>, ...) do ..., etc. Does that make sense?

Perhaps even more useful than syntactic patterns, though: I'm curious what it would take to have this autocompletion be cognizant of standard modules to help complete library function names, help remember the argument names and orders, etc.

[LouisJenkinsCS]

Yeah, also pulling stuff from documentation. This would be very nice in the long run

[bradcray]

There's also a chpltags script in $CHPL_HOME/util/ that may be useful for scraping code to determine these things? (rather than scraping documentation). I'm not sure which approach would be more tractable and useful.

[AnubhavUjjawal]

Perhaps even more useful than syntactic patterns, though: I'm curious what it would take to have this autocompletion be cognizant of standard modules to help complete library function names, help remember the argument names and orders, etc.

@bradcray Maybe we could provide autocompletion on proc too as well ? One brute way is, we could scan through the packages in the library on the start of the extension for procs, and provide autocompletion when needed. The chpltags script could be run on start as well ?

[bradcray]

I think we're saying similar things (or else I'm not understanding). That's what I was thinking about when I said "have this autocompletion be cognizant of standard modules to help complete library function names." If we could scan the modules, or their docs, or the rst sources for the docs, pick out all the (public) procedure declarations and help users by autocompleting them or popping up some documentation about the arguments or something like that, I think it'd be really helpful. I'm obviously not a good stand-in for the typical Chapel programmer, but I have a much harder time remembering things about the library than about the language.