Type System

Every port in the engine has a type, and a port accepts a value if it's exactly that type — or if some path leads from the value's actual type to the port's. That path works one of two ways: most of the time it's a registered conversion, actual logic that runs when the connection is made; a few times it's subtyping instead, where the source type is already, structurally, a value of the target type and nothing needs to run at all. This page lists both together in the same tables — see Converters and subtyping below for how the two are told apart.

Each type here is implemented by a dedicated type class, named after the data it represents with a Type suffix: Region Manager Type is the class backing the region manager data, Table Type the class backing tables, and so on. This page refers to every type by that full class name and links each one to its own page.

See Ports on the EGO Script page for how a port's type governs what it can receive, and Basic Data Flow for the general rule this page's conversions follow.

Automatic type conversion only happens when a value is connected from one port to another — a variable reference, or a functor call inlined directly into an argument. It never applies to a constant written directly into a port; a constant is instead parsed by the receiving port's own type-specific literal syntax, which accepts only that type's own literal form. See Constants for this rule in full.

Conditional conversions. Some conversions can fail outright, for two different reasons. The first is a mismatch between a generic holder's declared type and what it actually contains: converting an already-typed, known value never fails, but converting a generic holder type (such as Table Value Type) does depend on what it actually contains. Table Value Type → String Type and Table Value Type → Real Value Type are the clearest examples: each only succeeds if the Table Value Type value actually holds that type. Wrapping such a conversion in Skip On Error turns the failure into a type test — see Manipulating Tables and Lookup Tables for a full worked example of this pattern. The same conditional logic governs every type that converts to or from Table Type itself — see Table format of table-shaped types below for the exact column layout each one expects.

The second reason is content validation: the source value's type is compatible, but its actual content doesn't satisfy the target type's constraints. String Type → Real Value Type is the clearest example — connecting the string “test” to a Real Value Type port fails outright, since “test” isn't parseable as a number, while “3.14” succeeds. The same content-validation governs every conversion that narrows the numeric chain in Value types below: Integer Value Type → Non Negative Integer Value Type fails for any negative input, for instance, since there's no way to represent it in the narrower type at all. The named filename converters (String Type → Map Filename Type and similar) apply the same extension-checking rule Constants documents for literal filenames — confirmed for Weights Filename Type (.dcf, .txt, .csv), Table Filename Type and Lookup Table Filename Type (.csv for both), and Kmz Filename Type (.kmz). Generic Filename Type is the exception: it accepts any extension, matching its role as a filename with no specific format requirement.

Information loss. Failing outright and losing information are two different things — a conversion that never fails can still be irreversible. Real Value Type → Integer Value Type is the clearest example: it never fails, since every real number truncates to some integer, but the fractional part is simply dropped — 3.9 and 3.1 both become 3, and neither the original value nor the fact that something was lost survives the conversion. The opposite case — guaranteed to succeed *and* fully recoverable — describes the widening direction of that same numeric chain instead; see Value types below for exactly which steps are which. Every table from here on carries a Notes column stating this directly for the specific pair on that row; a plain — means this page has no confirmed failure or loss behavior for that conversion beyond the general rules above, not that the question doesn't apply.

Sequencing. A conversion to None Type is registered for almost every type in the system. This isn't meant to transform data — it's what lets sequence ports accept a connection from any container's output regardless of what that container actually produces: connecting an output to a None Type-typed input creates a dependency edge without needing the value itself, so the engine schedules the connected functor to run after the one that produced it. The types that support this are listed separately in Sequencing below, rather than repeated in every table.

A path from one type to another works one of two ways. Most entries in the tables below are registered converters — real conversion logic that runs when the connection is made, subject to the conditional-failure pattern above. A few are subtyping instead: the source type is already, structurally, a value of the target type, so a port declared for the target accepts it directly, with nothing to register and nothing to run. Both kinds appear together in the same tables from here on; every table has a Notes column stating how each specific entry behaves — subtyping, a possible failure, or information loss — so that looking up one conversion tells the whole story without cross-referencing this section.

Three relationships in this system work through subtyping:

• Categorical Map Type is a subtype of Map Type — see Map and raster types below.
• Table Type and Lookup Table Type are both subtypes of Base Table Type — see Table and Lookup Table types below.
• Non Negative Integer Value Type is a subtype of Integer Value Type, mirroring the actual mathematical relationship between the value sets: non-negative integers are a subset of all integers. Positive Integer Value Type's relationship to Non Negative Integer Value Type, by contrast, runs through an ordinary registered converter rather than subtyping, even though the value sets nest the same way — see Value types below for both, side by side.

The chain running through Positive Integer Value Type, Non Negative Integer Value Type, Integer Value Type, and Real Value Type behaves differently depending on direction, and the Notes column below states each step's behavior directly. Widening — positive to non-negative to integer to real — only relaxes which values are allowed; the number itself never changes, so every registered step is both guaranteed to succeed and fully recoverable. (Non Negative Integer Value Type's own step to Integer Value Type isn't among these registered steps at all — it's the subtyping entry from Converters and subtyping above, so the question of failing or losing information doesn't apply to it; nothing runs.) Narrowing the other way splits into two different behaviors: Integer Value Type → Non Negative Integer Value Type and Non Negative Integer Value Type → Positive Integer Value Type both fail outright if the value falls outside the narrower range — negative, or zero, respectively — since there's no way to represent those values in the target type at all. Real Value Type → Integer Value Type is different again: it never fails, but it's lossy — the fractional part is simply truncated and can't be recovered. See How automatic conversion works above for these two dimensions — failure and information loss — stated generally.

Five of these types also converge on Null Value Type — not to be confused with None Type above. Where None Type is the sequencing mechanism, Null Value Type is an ordinary type in its own right; converting to it always succeeds, and it converts onward only to None Type, nowhere else.

Boolean conversions. Boolean Value Type converts from four of the numeric types below — Integer, Non-Negative Integer, Positive Integer, and Real — using a non-zero-is-true rule, and converts back out to Integer, Non-Negative Integer, Real, Null, and String, using True → 1 / False → 0 (or True → “true” / False → “false” for String). There is deliberately no Boolean Value Type → Positive Integer Value Type entry: False converts to zero, and zero has no valid representation in Positive Integer Value Type, so no converter is registered for that specific pair.

Log Tag conversions. Log Tag Type converts to and from the same four numeric types by the level's position number in Log Tag Type's own table (e.g. Info is level 4, so Info ↔ 4 in either direction), and separately converts to String Type using the level's name rather than its number (Info → “Info”).

Filenames largely behave like String Type with an extra validation step on the way in — see Constants for the extension-checking rules each filename type applies to its text. Every filename type here converts to and from String Type; most of them — Generic, Map, Table, Lookup Table, and Weights Filename Type — also convert to and from a generic Table Value Type holder, the same generic-holder role Table Value Type plays for the table-shaped types further down this page. That direction is lossy in every case: going into Table Value Type discards the parent folder path and keeps only the filename itself, so round-tripping back out through String Type or another filename type does not restore the original folder. Folder Type, Kmz Filename Type, and Projection Type are the exceptions: they connect only to String Type, not to Table Value Type.

Table Type sits at the center of this group. It and Lookup Table Type are both subtypes of Base Table Type — see Converters and subtyping above — so their path back to Base Table Type, marked Subtyping in the Notes column below, needs no conversion at all, while the narrowing direction the other way round is an ordinary registered check against a specific shape. The rest of the table is more ordinary conversion territory: Table Value Type moving to and from the scalar types a table cell can actually hold, and the individual value types converting into Tuple Type and Table Cell Type for use as keys and column declarations.

Categorical Map Type's path to Map Type, marked Subtyping in the Notes column below, is the clearest example of subtyping on this page — see Converters and subtyping above. A Categorical Map Type value converts automatically wherever a Map Type is expected, keeping its cells and null value intact and dropping only the guarantee that a categorization is attached; the reverse never happens automatically, since an arbitrary Map Type value isn't guaranteed to carry one — which is why there's no corresponding Map Type → Categorical Map Type entry at all. The rest of the table below is Cell Type's round trip with the numeric value types, and the two paths a categorical map takes toward its supporting data: its legend, as a Categorization Type, and its spatial reference, as a Projection Type.

Every matrix-shaped type here — Change Matrix Type, Percent Matrix Type, Transition Matrix Type, and the rest — follows the same pattern: each one converts to and from a Table Type (or Lookup Table Type) with one particular expected column layout, and converting between them is mostly a matter of adding or checking for that layout. This is a conversion relationship, not structural identity — Neighborhood Table Type and Weights Type, for instance, have no editable constant of their own despite converting to and from Table Type; a value is obtained only from a producing functor or from this conversion. See Table format of table-shaped types below for the exact columns each one expects.

The one conversion pair here follows the same table-shaped logic as the simulation types above, though its exact column layout isn't confirmed — see the note in Table format of table-shaped types below.

Several of the types above convert to and from Table Type (or Lookup Table Type) under one particular, expected column layout: converting to Table Type keeps the same rows but drops the type's special meaning, and converting from Table Type checks that the table actually has this shape — the same conditional-conversion pattern described above. As noted in Simulation types, this is strictly a conversion relationship: it doesn't imply the type has an editor or constant syntax matching Table Type's own. In fact, Transition Matrix Type, Change Matrix Type, Percent Matrix Type, Transition Function Parameter Matrix Type, and Weights Of Evidence Skeleton Type each have their own dedicated EGO Script literal syntax, keyed on From→To pairs rather than named columns — see each type's own page for its exact grammar. The engine registers an exact default format for most of these; key columns are marked * the way Table Type itself marks them. Table Type's own Automatic Conversions section and Manipulating Tables and Lookup Tables both describe the Lookup Table Type row below in those same terms — its *#real, #real shape already matching what a single-value table needs.

Note: Transition Set Type is left out of this table on purpose — it converts one-way from Lookup Table Type but never to or from Table Type directly, so it has no registered table format either. Base Table Type and Lookup Table Group Type are left out for a different reason: neither has a fixed column layout to state — see Table and Lookup Table types above for how each of them converts.

Region Manager Type stands apart from every other type on this page: it has no automatic conversions to or from anything else. The only conversion registered for it at all is the sequencing conversion to None Type described below.

A conversion to None Type — used to force an execution order between two functors rather than to transform a value, most visibly through the sequenceInput/sequenceOutput ports EGO Script exposes on most containers — is registered for the following types:

Connection Info Type, Boolean Value Type, Code Type, Date Type, Enum Type, Folder Type, Generic Filename Type, Image Expression Type, Index Or Name Type, Int Set Type, Integer Value Type, Log Tag Type, Name Type, Non Negative Integer Value Type, Null Value Type, Percent Type, Positive Integer Value Type, Real Value Type, String Type, Struct Type, Workdir Type, Categorical Map Type, Categorization Type, Cell Type, Kml Type, Kml Timeline Type, Kmz Filename Type, Map Type, Map Filename Type, Projection Type, Weights Of Evidence Skeleton Type, Change Matrix Type, Neighborhood Table Type, Percent Matrix Type, Transition Function Parameter Matrix Type, Transition Matrix Type, Transition Set Type, Weights Type, Weights Filename Type, Elevation Graph Type, Region Manager Type, Base Table Type, Lookup Table Type, Lookup Table Filename Type, Lookup Table Group Type, Table Filename Type, Table Type, Table Manager Type, Table Value Type, Tuple Type