checking deduced types

[paciorek]

@perrydv and I talked about adding some functionality to allow someone writing nFunctions and nClasses to check the types decided by the compilation process.

This issue is to clarify and track progress on this effort.

@perrydv is your thought that there would be an additional argument to nCompile that triggers this and that somehow we give back to the user the type info for all local variables in an nFunction or in nClass methods? (Or perhaps a user could invoke a function on a compiled nFunction or nClass generator to get the info.)

[paciorek]

E.g., we could have the option to do:

nCompile(foo, control = list(return_symbolTables = TRUE))

and return the various symbolTables.

[perrydv]

@paciorek Yes, something like that, and that seems like one good approach.

I think sometimes what will be confusing about type processing is not just the types of symbols (things with names) but also of intermediate steps. Note that the exprClass_print function, which is called by the exprClass print method, has a showType argument that is supposed to show the type of each intermediate step, arranged vertically with indentation to create a simple syntax tree visualization. I don't think it has test coverage and I haven't used it in a while, so I'm not sure of its status. It could be a lot of output to show all of that for every line of every method, so I wonder if there another layer of organization that could be added, like a list of the exprClass objects associated with each line of input code and an easy way to find things by input line.

Initial implementation notes: There is a control list element for nCompile called return_cppDefs which if TRUE does not complete the compilation process and instead returns the cppDefs, which represent the compilation result right up to the point of outputting C++. However I think we might want the NC_Compiler and NF_Compiler objects instead, which represent the processed code still in a more abstract syntax tree closer to the original code. An example of the distinction is that when the cppDefs are created from N*_Compiler objects, the symbol tables are converted to C++ symbol tables. The N*_Compiler should have more of the processed R content before the C++ representations. There is a way to get those returned from nCompile_nClass and nCompile_nFunction, using the debugging controls over starting and stopping at certain compiler stages, but we could make an easier way if desired for clarity.

[paciorek]

Notes to self: one can see the pieces we might need by browsing into processNFstages and looking at $code and $symbolTable.

{ | 
  <- | D1
    y | D1
    nRep | D1
      x=1 | D0
      times=2 | D0
  return | D1
    + | D1
      x | D0
      y | D1
}

and here are the steps leading to the NF processing stages:

1: nCompile(Cfoo)
2: nCompile_createCppDefsInfo(new_units, new_unitTypes, controlFull, new_compi
3: nCompile_nFunction(units[[i]], stopAfterCppDef = TRUE, env = env, compileIn
4: NF_Compiler$createCpp(control = controlFull)
5: process(control = controlFull, sourceObj = sourceObj)
6: processNFstages(self, controlFull, sourceObj, doKeywords, .nCompilerProject

1: nCompile(nc)
2: nCompile_createCppDefsInfo(new_units, new_unitTypes, controlFull, new_compi
3: nCompile_nClass(units[[i]], stopAfterCppDef = TRUE, env = env, compileInfo 
4: NC_Compiler$createCpp(control = controlFull, sourceObj = NC, interfaceCalls
5: process(control = controlFull, sourceObj)
6: createCppMethods(control = controlFull, sourceObj)
7: NFcompilers[[i]]$createCpp(sourceObj = sourceObj)
8: process(control = controlFull, sourceObj = sourceObj)
9: processNFstages(self, controlFull, sourceObj, doKeywords, .nCompilerProject