INPUT /  OUTPUT /  LANGUAGE

Categories of tags

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

• Presentation tags
• Presentation container tags
• Persistent logic tags
• Ephemeral logic tags

Ephemeral logic tags

An ephemeral 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, an ephemeral logic tag creates no such tag instance. It simply performs its required action and 'leaves behind' any values that have been produces as a result.

The following are ephemeral 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 an ephemeral 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 an ephemeral 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 ephemeral 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.