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
Roughly, this means combining two Hugrs into a single Hugr, and in the process replacing static edges from FuncDecls in each with edges from corresponding FuncDefns in the other Hugr. Note this may be done via hugr-model (@zrho link?). There are a number of questions still to be resolved....
Do both input Hugrs have to have a module root? or can one be a non-module (the children of the module can be transferred into any non-module, but potentially "one way" i.e. the Module cannot refer to FuncDefns in the non-module). I don't see how both can be non-module...
(How does the linker identify) which FuncDecls correspond to which FuncDefns?
We may wish to consider the ability to pass extra command-line flags to the linker to change this behaviour e.g. aliasing, extra directives, ....
The ability to rename functions could be useful to avoid conflicts, too
which FuncDefns/FuncDecls does it consider - all? or only children of the (Module?) root(s)?
One answer to both of the "which" questions might be metadata. Or, function name - if we consider only FuncDefns that are immediate children of the (Module) root, we can require these to be unique.
Does it make sense to link a Hugr against itself? There are some interpretations where this makes no sense (e.g. if we only consider FuncDecls+Defns that are immediate children of the root, and require them all to have different names), but others where it might (e.g. if we consider FuncDecls further down the tree, we might link these with FuncDefns just beneath the root)
The text was updated successfully, but these errors were encountered:
Roughly, this means combining two Hugrs into a single Hugr, and in the process replacing static edges from FuncDecls in each with edges from corresponding FuncDefns in the other Hugr. Note this may be done via
hugr-model
(@zrho link?). There are a number of questions still to be resolved....One answer to both of the "which" questions might be metadata. Or, function name - if we consider only FuncDefns that are immediate children of the (Module) root, we can require these to be unique.
The text was updated successfully, but these errors were encountered: