I like this. At a bare minimum, just packages/namespaces/tests for functions. I like an extra-mile solution here – if we’re trying to make a way for people to share code, that’s a pretty big deal, so we should go all out.
Bob mentioned that there’s an outstanding debate on whether functions in such packages would be allowed to do things like define parameters. But this I’d like to step around by just doing packages of functions that behave like our UDFs now (but maybe with overloading and namespaces).
The simplest thing I know are Python packages. Like, you make a folder and put __init__.py in it and you have a package.
I think a package system would make Stan code easier to read, but it’d also be an opportunity to add tests for Stan code. I guess that would involve having compile-able Stan files that are not models.
It would be cool to make it easy to write and test Stan packages. Like bin/test mypackage and it runs all the tests in the package. Or bin/test mypackage/tests/test1.stan mypackage/tests/test1.stan and it runs the tests in those files.
Packages installing themselves with the interfaces would be cool too – like not having to put package folders in the right place manually or anything, or being able to install from interpreter of choice.
I really like how devtools makes it easy to install packages from Github.
I’m down to spend some time discussing this. It’s too big an issue to really hammer out quickly. There are a ton of practical critiques of this too (namely, it would be a huge effort), but I don’t know how to make progress on this one unless we start iterating.
Something I don’t like is C++. That stuff is just rough all around. A formal foreign function interface is a different kind of beast, I think.