Categories of tags

Tags in ioL all fall into one of 4 main categories.

• Presentation tags
• Presentation container tags
• Persistent logic tags
• Transient logic tags

Transient logic tags

A transient logic tag is one that 'disappears' after it is complete. It may produce a result or carry out some other action, but after that the tag has fulfilled its purpose.

While other tag types create a tag instance that can be manipulated or deleted after the tag has been created, a transient logic tag creates no such tag instance. It simply performs its required action and 'leaves behind' any values that have been produced as a result.

The following are transient logic tags built into ioL:

• abs
• add
• and
• clear
• dialog
• div
• eq
• false
• ge
• gt
• if
• inf
• int
• invalid
• join
• le
• lt
• mod
• mul
• ne
• neg
• not
• null
• num
• openLink
• or
• put
• putError
• putLn
• requestTransfer
• split
• sub
• void
• xor

What happens if if you attach a name to a transient logic tag instance? For example:

<result:add 1,1>

By itself, the add tag would add 1+1 and produce a result of 2. Because we have attached a name to the tag instance, the behaviour is slightly different. It doesn't make sense to refer to an instance of a tag that creates no lasting instance, so in this case, ioL automatically wraps the result produced by the add tag inside another tag that can store it in a persistent way. For this example, ioL will implicitly wrap up the add tag as follows:

<result:vector <add 1,1>>

So instead of producing a result directly, the result is instead stored inside a newly created vector tag named result. In fact, ioL will implicitly wrap the result in either a vector or scalar tag whenever an instance name is attached to a transient logic tag. (This also applies to field expressions like <theTitle:console.title>.)

So how does ioL know whether a vector or scalar is an appropriate choice for a particular tag or field value? The answer is ioL can't know with certainty how you will use the result or whether a vector or scalar will be a better choice, and will implicitly use a scalar for eq, join and ne tags, and a vector for all other tags. (Also, the result of the .@ operator is implicitly wrapped in either a scalar or a vector depending on whether one or multiple elements were requested. Meanwhile, the result of the .& operator is always a scalar.)

As you can see, the rules here are ad-hoc and hard to remember. For most tags a vector is a safe choice. But if you explicitly need one or the other (for example, the .# operator behaves differently for vectors vs scalars), the best way is to just be explicit. If we want the result of an addition operation to be stored in a scalar instead of a vector, we can simply say so:

<result:scalar <add 1,1>>

Or in a more compact form:

<result:scalar|add 1,1>

The following table shows which transient logic tags are implicitly wrapped in scalars vs vectors when a name is attached to them:

Categories of fields

• Presentation container fields
• Scalar fields
• Vector fields
• Repeatable code fields

Vector fields A vector field takes a list of zero or more values. In many cases these values would not be hard-coded as literal numbers inside the list, but would be set in terms of the result(s) produced by one or more other tags.