Comps

Overview

The sys.comp lib provides a standard ontology for modeling heterogeneous component oriented applications. It does not define any implementation behavior, rather it only provides a light weight set of standardized types for modeling common concepts found in control-flow or workflow frameworks.

• Comp: base type for components or function blocks
• CompLayout: standardized layout on 2D wiresheet
• CompFunc: component object-oriented methods
• Links: standardized model for wiring data flow between components

This core sys.comp library defines nothing related to implementation. It is purely for modeling component definitions and a graph of instances.

Comp

The Comp type provides a basic interface for all components that wish to use the standard Xeto model.

• if your model organizes components into a tree then use compName and parentRef to define the tree structure
• if your model provides 2D layout, then use compLayout using a logical coordinate system
• if your model supports data flow links, then use links to model them via a standardized graph design

Comps are defined in Xeto as normal types and their slots specify the fields and methods:

MyAddBlock : Comp {
  in1: Number <transient>
  in2: Number <transient>
  out: Number <transient>
  execute: Func
}

CompLayout

The CompLayout scalar type encodes the coordinates and width of component/block into a logical 2D coordinate system. The height is assumed to be defined by the component's slots.

// this specifies that top, left corner of component is at x=5, y=10
// and width is 4
compLayout: "5, 10, 4"

CompFunc

If your component model has the concept of object oriented methods, then define a Func slot on your component type. Component functions should define exactly one parameter, this makes them suitable for wiring sensibly into data flow applications via links:

// component with func slot
MyFuncBlock: {
  doIt: Func { arg: Str, returns: Str }
}

Links

The Link type defines a standardize model for data flow links between two component slots. A link requires four identifiers to fully identify the relationship:

fromComp.fromSlot => toComp.toSlot

The way the model captures these four identifiers is as follows:

• We store a Links dict on the toComp in the slot named links
• We store a Link dict inside Links dict using the toSlot name
• The Link dict stores the fromComp's id using fromRef
• The Link dict stores the fromSlot name using fromName

Here is example:

// fromComp that outputs data in slot named "out"
@a: DataProducer {
}

// toComp that links out to its own input slot named "in"
@b: DataConsumer {
  links: {
    in: Link { fromRef:@a, fromSlot:"out" }
  }
}

If links are predefined in a spec tree, then use the link meta tag. This tag is placed on the to/input slot and specifies the output/from slot using using a dotted slot path. The dotted slot path is always relative to the root spec:

CompositeComp: Comp {
  topIn: Number
  topOut: Number <link:"sub.innerOut">
  sub: SubComp {
    innerIn: Number <link:"topIn">
    innerOut: Number
  }
}