Right now, a Hydra module comes with a list of dependencies -- other modules which the term or type expressions of the module depend upon. Hydra uses these dependencies to build an appropriate graph -- not too big and not too small -- when performing inference or transforming source code.
However, modules currently do not distinguish between term-level and type-level dependencies, and it is increasingly clear that they need to, as domain models like the TinkerPop models may need to first define their own type systems, then use them in program code. Going forward, a module should have two lists of dependencies: one for terms, and one for types. Hydra will use these to build the data graph and the schema graph respectively.
joshsh
commented
11 months ago
Right now, a Hydra module comes with a list of dependencies -- other modules which the term or type expressions of the module depend upon. Hydra uses these dependencies to build an appropriate graph -- not too big and not too small -- when performing inference or transforming source code.
However, modules currently do not distinguish between term-level and type-level dependencies, and it is increasingly clear that they need to, as domain models like the TinkerPop models may need to first define their own type systems, then use them in program code. Going forward, a module should have two lists of dependencies: one for terms, and one for types. Hydra will use these to build the data graph and the schema graph respectively.