[RFC] Can the model function be made a custom closure type? about dynamicppl.jl HOT 7 CLOSED

To wrap up: unless we do crazy world-age and eval tricks, the answer is likely NO, unless we give up the possibility of defining models other than at toplevel.

from dynamicppl.jl.

Hmm isn't

const inner_function = Mymodel_Function_1()

problematic? But maybe that could be avoided if you define

function model_1(y)
  return Model(Mymodel_Function_1(), (y = y,), ModelGen{(:y,)}(mymodel_1, NamedTuple()))
end

from dynamicppl.jl.

I wrote that because otherwise, a new object every time. There is no closed-over data in this variant, anyway -- it's meant as a singleton type, so what would be problematic?

But another thing I now worry about: I think producing a type makes the macro unable to be used in non-toplevel places. Does putting a model inside e.g. a function work in all cases currently?

from dynamicppl.jl.

I wrote that because otherwise, a new object every time. There is no closed-over data in this variant, anyway -- it's meant as a singleton type, so what would be problematic?

I assumed it would be problematic since it would not be possible to define another model if inner_function is already defined. Additionally, there's no need for inner_function it seems since there is always only one instance of Mymodel_Function_1 as the Julia documentation explains:

Immutable composite types with no fields are singletons; there can be only one instance of such types: [...]
The === function confirms that the "two" constructed instances of NoFields are actually one and the same.

from dynamicppl.jl.

I assumed it would be problematic since it would not be possible to define another model if inner_function is already defined.

Oh, I assumed it to be gensymed as well.

Additionally, there's no need for inner_function it seems since there is always only one instance of Mymodel_Function_1 as the Julia documentation explains:

Right, I forgot about that! And we could even make it simpler, without having to create a separate type each time, by using a kind of "anonymous struct":

function (::ModelFunction{Symbol("##mymodel#474")})(vi, spl, ctx, model)
   local y
   # transformed model code
end

function var"##model#473"(y)
  return Model(ModelFunction{Symbol("##mymodel#474")}(), (y = y,), ModelGen{(:y,)}(var""##model#473", NamedTuple()))
end

mymodel = ModelGen{(:y,)}(var""##model#473", NamedTuple())

from dynamicppl.jl.

Or, more simply

function (model::Model{Symbol("##mymodel#474")})(vi, spl, ctx)
   local y
   # transformed model code
end

function mymodel(y)
  return Model{Symbol("##mymodel#474")}((y = y,), getmissings(y))
end

with

struct Model{name, Targs<:NamedTuple, Tmissings<:Val}
  args::Targs
  missings::Tmissings
end

if that's possible without the ModelGen.

from dynamicppl.jl.

if that's possible without the ModelGen.

I'm not familiar with all details of DynamicPPL but AFAIK the advantage of having (and saving) the ModelGen is to be able to generate a new model with different data (which can even be missing partially). But I guess that could be part of Model as well by saving the default arguments?

At least it seems possible to replace

struct Model{name, Targs <: NamedTuple, Tmodelgen, Tmissings <: Val} <: AbstractModel
    args::Targs
    modelgen::Tmodelgen
    missings::Tmissings
end

function Model{name}(args::NamedTuple, modelgen, missings::Val = getmissing(args))
    return Model{names,typeof(args),typeof(modelgen),typeof(missings)}(args, modelgen, missings)
end

and just implement

function (model::Model{Symbol("##mymodel#474")})(vi, spl, ctx)
   local y
   # transformed model code
end

as you suggested.

Possibly (not sure about this) one could get rid of ModelGen by adding
Targs and defaults from ModelGen to Model and replacing the ModelGen functionality with something like

Base.similar(::Model, args...) = ...

from dynamicppl.jl.