Gen.jl icon indicating copy to clipboard operation
Gen.jl copied to clipboard

Non-splatting constructor for `ChoiceMap`

Open bzinberg opened this issue 4 years ago • 0 comments

AFAIK, the only "direct" way to convert a Dict or Vector{<:Pair} to a choicemap is to splat it into the varargs constructor Gen.choicemap:

kvs = [(:a => 1), (:b => 2), #= whatever other stuff; or more to the point,
                                this is often programmatically constructed =#]
c = Gen.choicemap(kvs...)

In Base, this was a performance issue (https://github.com/JuliaLang/julia/issues/21672). In Gen I'm guessing we currently are not hitting that edge, but AFAIK there is no obstacle to also providing a more efficient non-varargs choicemap constructor:

c = Gen.choicemap(kvs)

(although this does potentially cause ambiguity with the varargs version, so we might need to give this version a new name). Personally I think it also is nice from a user perspective to have the ability to "directly convert" a choicemap-like object to a choicemap.

One design question to think through for this constructor is: should it recursively convert a dict-of-dicts to a choicemap with submaps, i.e. should it be an inverse of Gen.nested_view? I'd say no, that gives too much opportunity to silently produce incorrect behavior in cases where the user wants to hold a dict-like thing as an actual value in the choicemap. But I do think it could be reasonable to have the constructor understand keypaths a => b => c as indications of submaps, i.e. to have the constructor be an inverse of iter_deep in https://github.com/probcomp/Gen.jl/issues/123.

bzinberg avatar Apr 02 '21 17:04 bzinberg