It'd be easier with ragged arrays, so yes, it's working around language features.
The other problem as you note is that we need to distinguish data from parameters in the ODE system because we need sensitivities (derivatives of output w.r.t. parameters).
And it's not just pure ragged array problems---it's that the arguments are really heterogeneous---they might be sizes, arrays, matrices, etc. And we're forcing them all to be packed into a ragged array.
Yous ee this pattern elsewhere, not just in Stan, when you have to call these higher-level functions. It's what CVODES and Boost force us to do for the ODE solvers.
Yes, we want to distinguish data from other variables. That's tied up with MPI and shipping data off.
It took me a while to see what you're doing, but I take it you're defining the body of
f to be the mapped function; if we wanted to solve an ODE, we'd do that raher than sum. In general, we want to map functions that apply to multiple arguments and return multiple results.
I think we could probably handle the lambda abstraction with closures, but adding the auto stuff to Stan would be much more challenging. As to the map itself, we could take just
N as the argument and leave the iteration implicit, or we could take an array of arguments.
A further problem is that within the ODE solvers, we again have to make the data/paramters distinction because some arguments can be only data.