aTbRef: updated article re user functions with no arguments

Tutorials and Examples
1

Note: For those for whom action code syntax variations like those described below are confusing, a simple consistent rule of thumb is to always use trailing parentheses on operators and function. The only known exceptions are the action commands function, return and var. The most recent (v9.5.0) aTbRef baseline uses the latter (i.e. with parentheses) notation for the listing of built-in action codes for exactly reason. Being a general suggestion for those less versed in action code, it doesn’t stop others more expert in action code from omitting empty parentheses where they know they aren’t required.

Some test work showed up an undocumented facet of user functions. Unlike built-in operators, the trailing parentheses may not[typo!] be omitted if no arguments are being passed (or expected). So, in general use both these are fine:

$MyList = $MyList.isort;
$MyList = $MyList.isort();

Both forms are valid and give the correct result. Indeed, the former is probably the more common usage.

So, you might assume the same holds for user-defined functions. First consider the simplest of user functions, and one that takes no arguments:

function fTestMessage(){return "Hello world."}

We know this definition syntax is wrong (parentheses omitted):

function fTestMessage{return "Hello world."} WRONG SYNTAX

But, given the opening example— i.e. the isort scenario above, does the same optional use of parentheses hold for invoKing no-argument user functions in action code? No. User functions like this must be called with empty trailing parentheses:

$Text = fTestMessage();
$Text = fTestMessage; WRONG

Side note. Testing the latter above returns a string value of “fTestMessage”, i.e. the action code parser is not detecting the reference to a function called ‘fTestMessage’. This is unsurprising given the impressive long-time support for early Tinderbox action syntax where the quoting of literal strings was not needed. But, action code was significantly less capable then and chances of mis-detection were significantly less. However, legacy support means we need to use always trailing parentheses for user functions to explicitly indicate our intent and not confuse the (legacy) parsing of our code.

The article on Function arguments is now updated. See the new section Functions with no input arguments must have parentheses.

Edit: I moved the current opening paragraph up from the end of the post as @PaulWalters kindly pointed out it is the part of the post of most use to those most in need of guidance. Thus the edit.

2 Likes