mk_function: more than 1 dispatch?

[ChrisRackauckas]

Is there a way to have this make more than 1 dispatch for a function?

[ChrisRackauckas]

Oh, realized I can just make the dispatches in a function over the returned made functions.

[thautwarm]

Oh, you've said a ptoblem.
In fact the most obvious restriction of GG is, it doesn't allow multiple dispatch within the return of a generated function, and it just treat those definitions of multiple methods as multiple assignments.
It's possible to support multiple dispatch. Calling RuntimeFn calling a generated function, and we can change the implementation of calling RuntimeFn, and make some interfaces to select which method to invoke.

In fact, theoretically we can re-implement the multiple dispatch in the GG's system:

struct RuntimeMethod{TypeVars, Args, Kwargs, Body} end

struct RuntimeFunction{Methods} end

We can hold a list of methods in RuntimeFunction's type parameter via type level encoding: https://github.com/thautwarm/GG.jl/blob/variable-analysis/src/typeable.jl#L31

And when we call a RuntimeFunction:

@generated function (::RuntimeFunction{Merhods})(args...; kwargs...) where Methods # Methods is the type level encoding of a list of methods
      methods :: Vector{<:RumtimeMethod} = interpret(Methods) # type level representation to original object
      for method in methods
         check_if_satisfied(method, args, kwargs) && return :($method(args...; kwargs...))
      end
      error("...")
end

It must be correct! However too complex...

[ChrisRackauckas]

https://github.com/JuliaDiffEq/ModelingToolkit.jl/pull/173/files#diff-7849540f758d65e684b2dcd2d863bbfcR223-R226 this shows the workaround, where the two returned functions are the mk_function returns. It's not that bad of a workaround, but yes a real solution would be better!

[thautwarm]

@ChrisRackauckas

Oh, realized I can just make the dispatches in a function over the returned made functions.

When you're making functions you can decide how to make them based on your environment(arguments, local variables, global state, etc.), but multiple dispatch is not allowed on an (already) made function :-)

[thautwarm]

Oh, please DO NOT use GG in the development!

It's still WIP. It needs several days to wait for the registrations of its dependencies and register itself!

[ChrisRackauckas]

It's just a PR. There's no intent to merge until GG registers (#7)

[thautwarm]

Okay.
In case there're some context you don't know, FYI, the master branch of GG doesn't support mutable free variables and automatical recognising of free variables. It's done in the branch variable-analysis and is essential for supporting nested closures.

I've checked your PR and found you didn't make nested closures in the function to make, that's great because it's an already solved case in GG.

But I still wonder if it's possible for ModelingToolkit to generate functions with nested closures?

[ChrisRackauckas]

The functions that it's building are quite simple, so that shouldn't be an issue.

[thautwarm]

Nice, good to know this.