stan-dev / stan-dev/stanc3

Improving external C++ integration

Open
#1,278 4 comments 0 reactions 1 assignee View on GitHub

@WardBrian is already working on this.

Since Jan 12, 2023.

cpp-codegen feature interface
Dominant language
OCaml
Stars
160
Forks
59
Avg merge
21h 45m
Merged PRs (30d)
26

Description

Introduction

After #1277, the only required use for forward declarations of functions is for using external C++ code. This feature as currently implemented is sub-par for a number of reasons:

  1. We need to globally disable the typechecker pass which verifies that forward declarations all eventually have definitions. (--allow-undefined)
  2. We generate a C++ declaration for these functions, which means users must use our complicated templates and backward compatibility breaks any time we change our code generation.
  3. At least in CmdStan, the external C++ is outside the generated model's namespace and so it needs to have knowledge of what the model's namespace is.

Proposed change:

A new syntax, which looks like

extern "myfile.hpp" real foo(real a);

(note, extern is already a reserved word in Stan).

This syntax solves each of the 3 problems above:

  1. The typechecker knows this is for external C++ and not just a normal forward declaration, so it can locally disable that check
  2. Similarly, the backend knows this is for external C++ and can generate no bespoke code of its own. The user can provide any C++ which satisfies the call sites, and this should be much more stable between versions of Stan.
  3. Finally, we can paste the contents of myfile.hpp directly into the generated C++ (more likely we will just do a C++-level #include), so that this code will live inside the namespace.
Considerations
  • If we ever had a non-C++ backend, one could imagine a extern "foo.py" ... style which does the same thing. Using the filename rather than something like extern "C++" is to allow for item 3 above.
  • It might be useful to also allow some code before the model namespace, e.g. if the user's C++ needs its own #includes, we may want those outside the namespace. Something like this seems like it could be handled on the command line, rather than in the language.

Previous discussions:

Soliciting opinions @bob-carpenter @mitzimorris @rok-cesnovar @nhuurre

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.