One thing I just ran into while using this DSL was that I was getting a cryptic error about how the "Jacobian is 0x1 and is not square". I eventually realized this is because I was looking up a continuous return value of a subtrace in my model in the involution I had written. It was something along the lines of:

# `:vals => i` points to a subtrace which samples `:val ~ ...` then returns this value
@read(model_tr[:vals => 1], :cont)

Would it be easy to throw a custom error if a user tries to read a continuous value from a subtrace return like this, so it's clear to the user how to fix this?

One limitation of the Trace Transform DSL though, as compared to the Involution DSL, is it that it seems like TraceTransformDSLPrograms no longer have access to the model and proposal arguments, whereas InvolutionDSLPrograms did? If I'm right about that, then it seems harder to write trace transforms parameterized by various model arguments, which might be useful sometimes (e.g. in the example I gave for the use of ExtendingTraceTranslators in SMC), because the trace address you want to read / write from could depend on model arguments, and not just previously sampled values.

@ztangent That is still supported, but with a different syntax that better matches the idea that model_in and aux_in are traces, e.g. get_args(model_in) and get_args(aux_in).

That is still supported, but with a different syntax that better matches the idea that model_in and aux_in are traces, e.g. get_args(model_in) and get_args(aux_in).

Nice, that's right! Perhaps all that's needed then is an example within the docs / tutorials of that -- or maybe there already is, and I just missed it.

As another suggestion for an improvement, I think the documentation for the @copy and @tcall could both be improved. In particular, for @copy, we should make it clear that

1. It is possible to copy a whole submap of addresses
2. If we copy a whole submap of addresses, it will overwrite any values currently at those addresses

I'm not 100% sure 2 is true--it is true in my fork where I redid the set_submap! function in my choicemap rewrite, but not sure about the main branch. If 2 is true, we could also consider if this is the behavior we want. I suspect it isn't. Eg. It is sometimes nice to have an involution looking like

@transform .....
  @write(new_tr[:top => :value => 1], some_value, :disc)
  # say the proposal proposes some addresses in `:top => :space1` and `:top => :space2`, but not in `:top => :value`
  @copy(proposal_tr[:top], new_tr[:top])
end

Ie. we may want to write to some addresses in namespace :top, then copy in all the proposed addresses in namespaces :top without overwriting the values we wrote explicitly.

To prevent this type of overwriting should be pretty easy, we just need to change a call to set_submap! to merge!.