You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 25, 2022. It is now read-only.
The idea is to use metaocaml to make the configuration engine available at runtime and be able to trigger a re-emission of the initialization code on some event.
There are lots of issues with this:
metaocaml doesn't handle modules at all.
metaocaml doesn't handle toplevel bindings. We use bindings for two things:
main.ml : this could be avoided completely, since it's not actually exported, not a blocker
Keys: In this case, we really want the bindings to be available to the rest of the modules.
A solution, assuming that the first point is solved, would be to use "Keys as a module" instead of the current global Bootvar_gen module.
In metaocaml, the meta level need in theory to be linked with the dependencies of the sublevel. A trick could be to use similar method than module aliases, where the typechecker doesn't look at a module until it's needed for typechecking.
There are lot's of typing issues, in particular related to the connect function. Linked to Connects are error-prone #7
The idea is to use metaocaml to make the configuration engine available at runtime and be able to trigger a re-emission of the initialization code on some event.
There are lots of issues with this:
main.ml
: this could be avoided completely, since it's not actually exported, not a blockerA solution, assuming that the first point is solved, would be to use "Keys as a module" instead of the current global
Bootvar_gen
module.cc @avsm
The text was updated successfully, but these errors were encountered: