Further refinement to listing for action code operators. Where an action code operator returns a (only) a known Tinderbox data type, there is a cross-link to an aTbref article in that data type. For instance, distance() returns Number-type data so the aTbref article on it now adds this:
For operators that do not return a single know data type or have other purposes, only the $OpReturnType value is shown:
So, why do this? I think—I hope—it will aid those beginning to learn about use of action code. Knowing what Tinderbox would expect—in terms of data type—also helps when considering auto-coercion of data types. For instance, passing a List into a Set automatically de-dupes and sorts it. Or, consider max() , that returns a Number-type:
$MyList = [2;5;1;4;6;3];
// from the above list max() returns the biggest number (6) as a Number-type
$MyNumber = max($MyList); // => Number 6
$MyString= max($MyList); // => String "6", as Number coerced to String
Once you know these wrinkles, it is a bit easier, but understanding what data types are and how they differ should speed learning up a bit.
Tip: the format() and .format() operators always return a String-type, regardless of the source data type they are passed
Wondering how this conditional export works? See the “5-basic_item_operator” template in the aTbRef TBX file, which is an include form making the data table at the start of articles describing action code operators. A conditional at the head of the template checks for notes where the $OpReturnType user attribute value is of a known Tinderbox data type:
^action(
var:set vTypes = [Date;Dictionary;Integer;List;Number;Set;String];
var:boolean vAddSlug = false;
if(vTypes.contains($OpReturnType)){
vAddSlug = true;
};
)^
At the appropriate place in the template’s code, the code for the right-hand cell of that table row† is this:
<p class="attributetabletext"> ^value($OpReturnType)^^if(vAddSlug)^ [about ^linkTo(^value($OpReturnType+"-Type Attributes")^,^value($OpReturnType)^)^ data type]^endIf^</p>
Thus the article about an operator that returns Date-type data will now auto-link to the Date-Type Attributes‡ article, and so on for other Tinderbox defined data types.
Essentially, I’m gently increasing the hypertextual cross-connections in the aTbRef corpus, with the aim of offering the (initially) confused extra ways to look up things they don’t yet know. Just as a computer generated book index is sub-par compared to a human-made index (the former can’t understand context/nuance/inferred ideas)§, I’d be interested to see how well today’s ‘AI’ would do at the above task. It’s also a reminder that intentional hypertext is a world removed from auto-generated graphs/DAGs.
Apart from the refreshed action code pages (c.320) the TBX zip and the JSON index are also refreshed on the live site.
†. Sharp-eyed readers will spot there is no table-related HTML. This is correct, as the template uses two <div>s and CSS to make the ‘table’. It’s easier, once you know the HTML.
‡. The fact the listing is for ‘Date-Type Attributes’ is historical. These articles originated before var and function extended action code beyond passing data between attributes. Plus the articles (still) list the system attributes of that data type.
§. Duncan’s Index, A History of the (2021, Allen Lane/Penguin) features two indexes. It illustrates the difficulty of automating the task of meaningful indexing. It has a 31-page human-curated index and also part of a computer-generated index (the opening part, from ‘AA’ to ‘amusement’). comparing the two suggests the machine version would run to over twice the length length of normal index. As pertinently, it has fewer sub-heads and entries are literal string matches (no understanding of implied/inferred meaning). Using the machine-version shows many of the entities are essentially mis-detections, q.v. the entry for ‘AA’.
), he generously contributes freely to all. Give Mark a handshake in return, if you can.
