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
Sometimes it would be useful to associate some metadata to nodes and edges, that is used e.g. for the GUI or documentation purposes, and have it properly handled and propagated to outputs.
A simple example are the positions of nodes. It could be useful for critical pairs to have a (preliminary) node layout that is based on the node layout of the rules. This layout would then be refined by some algorithm in the GUI.
In order to do this, we'd probably need to include this metadata into the payloads of nodes and edges. We'd also need to figure out how to properly handle these payloads in basic categorial operations such as pullbacks, pushouts, overlappings, etc. This would probably involve having a type class with the necessary operations.
Monoidal Metadata
A first suggestion would be to use the Monoid class, which describes types that have an "empty" value and can be arbitrarily combined. Then any elements created from scratch would have the "empty metadata, elements created from a single other element would have the metadata copied and elements created from multiple other elements (e.g. in an overlapping or pushout) would have the metadata combined.
In the example of using positions, the following type could be used as metadata:
typePosition=PositionFloatFloat|NoPositioninstanceMonoidPositionwheremempty=NoPositionmappendNoPosition p = p
mappend p NoPosition= p
mappend (Position x1 y1) (Position x2 y2) =Position ((x1+x2)/2) ((y1+y2)/2)
We still have to check if Monoid is enough, and how exactly the metadata is propagated by the primitive operations.
The text was updated successfully, but these errors were encountered:
Rationale
Sometimes it would be useful to associate some metadata to nodes and edges, that is used e.g. for the GUI or documentation purposes, and have it properly handled and propagated to outputs.
A simple example are the positions of nodes. It could be useful for critical pairs to have a (preliminary) node layout that is based on the node layout of the rules. This layout would then be refined by some algorithm in the GUI.
In order to do this, we'd probably need to include this metadata into the payloads of nodes and edges. We'd also need to figure out how to properly handle these payloads in basic categorial operations such as pullbacks, pushouts, overlappings, etc. This would probably involve having a type class with the necessary operations.
Monoidal Metadata
A first suggestion would be to use the
Monoid
class, which describes types that have an "empty" value and can be arbitrarily combined. Then any elements created from scratch would have the "empty metadata, elements created from a single other element would have the metadata copied and elements created from multiple other elements (e.g. in an overlapping or pushout) would have the metadata combined.In the example of using positions, the following type could be used as metadata:
We still have to check if
Monoid
is enough, and how exactly the metadata is propagated by the primitive operations.The text was updated successfully, but these errors were encountered: