when should args to DSL functions be named?

[paciorek]

If we don't name the args for nMatrix it doesn't behave as expected. So I think I am generally confused about how args by name vs. position work in the DSL.

No urgency, just flagging it.

go = nFunction(
        fun = function() {
            y <- nMatrix(7,3,5)
          return(y)
        },
        returnType = 'numericMatrix'
  )
cgo=nCompile(go)
cgo()

     [,1]
[1,]    0

[paciorek]

@perrydv Actually I think I do need some guidance here, as I work through shared/nonshared vars for parallel_for.

From brief perusal, it looks like nMatrix works with args by name, while parallel_for does so by position.

What's supposed to happen generally? I would have thought we would do some general handling early on in the processing to be able to handle either by name or position for all DSL functions.

[paciorek]

By email, Perry noted "If you go into the compile_aaa_operatorLists.R, you'll see there are two relevant fields in an opDef. The first is matchDef, which gives a function prototype used for early aligning of arguments by name and position similar to R. This was likely added to the system after the first skeleton draft of the parallel_for and reduce methods. The second is compileArgs, which indicates which arguments are compile-time. These get pulled into part of the auxEnv field (I think) -- you can look for examples and then in labelAbstractTypes or other places to see how they are accessed later."

[paciorek]

So there is no matchDef for nMatrix, which seems to explain the problem I noted in this issue. If I add it, then passing args to nMatrix either by position or value works in the way expected for R functions.

I note that there are other operators that don't have matchDefs, and I am thinking they should all have them.