David Widmann

Maybe it would be better to not have a dedicated model but a special log density function type with the desired factorization that can be used in LogDensityModel. Then it...

I'm not particularly happy about enforcing a specific struct, it seems a bit restrictive. Also it seems difficult (impossible?) to evaluate both the prior and likelihood in a single execution...

Just an additional note: of course, this suggestion would still allow you to use a struct for implementing `logprior` or `logprior_loglikelihood` etc. for a specific class of models. But the...

> By this I presume you mean separately evaluating just the prior / likelihood? No, I mean executing e.g. a Turing model and then accumulating log prior and log likelihood...

> It is a tradeoff I suppose as I am stuck in a mindset of trying to make it as simple as possible for someone to support tempering where the...

> Presumably they'd define a logprior, a loglikelihood, but then there would still be a step where in AMH say we would need to define a new model constructor that...

We already have implemented some similar functions for working with transitions in Turing, eg. `metadata`, `getparams`, `getlogp`, `getlogevidence`. I think it could be useful to move some of them upstream.

I am less sure about `get_model` though. It seems orthogonal to the problem with multiple disconnected model types and quite specific for the mixture example? It also doesn't seem very...

IMO AbstractMCMC should not make assumptions on or enforce any specific structure of the outputs. One of the design principles is that the interface and the default implementations should work...

One sample would just correspond to a single row of a table. Of course, one could just rely on `keys` and `values` for a single sample but AFAICT the Tables.jl...