Add promoter expression

[SteveBronder]

@WardBrian I got this up to the point that I think I have all the backend setup. What I'm having trouble figuring out is where to place the actual promotions in the MIR lol!

The thing I'm confused by is where to get the udf signature information. tmk I would need a separate pass where I also include the functions block as I go over each of the other blocks. I was at first thinking about doing this in Stan_math_backend/Transform_mir where I'd have some functions like the below that do go over each block/statement/function/expression adding promotions where we need them.

(*Go over each block updating expressions in functions in statements that need promoted *)
let promote_func_args fun_block prog_block = 
  (*make a table for each udf and it's signature*)
  udf_func_signatures = get_udf_signatures fun_block in 
  (*Go over each statement updating it's functions whose args need promoted *)
  List.map ~f:(promote_func_arg_stmts udf_func_signatures) prog_block

(*iterate over each block in the program doing promotion*)
let do_program_promotion prog = 
   let promote_func_args' = promote_func_args p.functions_block
  Program.map_stmts promote_func_args' p

But should this happen somewhere else sooner? Like should we do it right after we call Ast_to_Mir?

Also do we only need to do this promotion for UDFs or should it also happen for stan math functions. UDFs are a little simpler as there is only ever one signature. Stan math will be a little harder as we would need to choose the "most appropriate" signature

Submission Checklist

• Run unit tests
• Documentation
  • If a user-facing facing change was made, the documentation PR is here:
  • OR, no user-facing changes were made

Release notes

Copyright and Licensing

By submitting this pull request, the copyright holder is agreeing to
license the submitted work under the BSD 3-clause license (https://opensource.org/licenses/BSD-3-Clause)

[WardBrian]

I think ideally we would do this during typechecking, if we’re willing to move it into the frontend as well and make it part of the type metadata. Part of #995 is trying to make overloading easier, so we should try to plan ahead if possible

The way I’d do this is change the return types in SignatureMismatch to return something like

type t = Fine | Promotion of int list | SignatureMismatch of error rather than the option type it does now. The int list is just the indecies that need promotions. Note, I’m not staring at the code RN so I have no idea how hard this would be.

does that sound reasonable?

Edit: I realized this is assuming my new typechecker which unifies the use of SignatureMismatch for all function types. I honestly don’t know how to do this in the current typechecker, would need to investigate.

[WardBrian]

@SteveBronder - if you want to revisit this soon I think it is easier to do in the typechecker now per my above comment. Happy to help if needed

[SteveBronder]

Yes! Got lost in pathfinder I'll come back to this in the coming week

[WardBrian]

I've linked #373 to this as this is essentially what it was describing, just now applied to the newer types

[WardBrian]

Looks like I confused Github pretty seriously somehow. I've got this hooked up to the typechecker in an ok-ish way at any rate

[WardBrian]

@SteveBronder this is passing the trivial tests I set up. If you can take another pass at it there's definitely some clean up it could use.

[nhuurre]

Ternary operator x ? y : z and array literals {x, y, z} may also generate stan::math::promote_scalar. Would it be feasible to implement those too as a promotion in the MIR?

[nhuurre]

[optional] this could be a bit smarter, like promoting literals to literals and collapsing promotion of promotion.

[nhuurre]

Looks good to me.

[WardBrian]

Thanks @nhuurre. I’m gonna add some more tests when I fix the merge and update some of the doc. I’ll merge after the tests are done and the doc is approved