Chad Scherrer

I see, it's the middle line here: ```julia q = quote KeywordCalls._call_in_default_order(::typeof($f), nt::NamedTuple{($(sorted_args...),)}) = $f(NamedTuple{($(args...),)}(nt)) $f(nt::NamedTuple) = KeywordCalls._call_in_default_order($f, _sort(merge($defaults, $alias($f, nt)))) $f(; kw...) = $f(merge($defaults, $alias($f, NamedTuple(kw)))) end ``` There...

That would be great! I guess this involves changing how the type is displayed, right? Any suggestions on a clean representation?

How about context dependence, like the way `Vector{Bool}`s are displayed? ```julia julia> true true julia> [true, false, false] 3-element Array{Bool,1}: 1 0 0 julia> [true, false, false][1] true ```

Thanks @theogf . The issue isn't exactly here, but in the call passed to each marginal. In `master` this is ```julia function Base.rand(rng::AbstractRNG, ::Type{T}, d::ProductMeasure) where {T} _rand(rng, T, d,...

> The thing is, transport needs both `transport_def` and `transport_origin`, it's not quite the same as basemeasure. `transport_def` is like the 3-arg `logdensity_def`, and `transport_origin` is like `basemeasure`. I think...

I made a little proof of concept here: https://github.com/cscherrer/MeasureBase.jl/pull/94 The advantage is that the approach is very similar to what we do with `basemeasure`. There might be good reasons to...

Why is that?

Hmm, yeah we do need to get to that mass interface.

Either of those would be good, or an asymmetric loss could be interesting. I'd think this must come up a lot in medical applications, right?

Sounds good