Skip to content

Use "generic" meta types consistently #87

Open
@brandonwillard

Description

@brandonwillard

In some instances, we automatically create logic variables as stand-ins for unspecified meta object components (e.g. #35, TFlowMetaOp.outputs); following #84, we should always produce properly "typed" generic objects and we should also restrict meta object inputs to the expected "types" (whenever possible).

For example, TFlowMetaOp.outputs would ideally return something strictly unifiable with a tuple of TFlowMetaTensor objects. As well, we shouldn't allow a strictly logic variable argument for TFlowMetaOp.op_def, since it's possible to create a TFlowMetaOpDef object with strictly logic variable arguments—making it just as generic, but properly "typed" (i.e. will only unify with a TFlowMetaOpDef, but will unify with any TFlowMetaOpDef).

This change will probably need to come alongside an easy way to generate these generic meta types (e.g. a "generic" TFlowMetaOp requires a "generic" TFlowMetaOpDef).

Such a consistency would also simplify the code base quite a bit, since there are numerous places where isvar is used to check whether or not a property is available.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingenhancementNew feature or requestimportantFeatures and issues that need to be addressed ASAPmeta graphThis issue involves the meta graph objects

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions