Library functions: introduction |
Proteus stands out from other text processing languages in that it includes many more predefined functions for data treatment; this design, even though requires slightly more memory for running programs, allows the user to create shorter and faster scripts, because many functionalities are developed at low level. The user can concentrate on the algorithms, becoming more productive.
Library functions are divided in the following categories:
There are a few functions which do not belong to the previous categories:
EVAL(exp1[, exp2..])
evaluates all the expressions passed and returns the value of the last one; e.g.:
EVAL("HI", ADD(3, 5), MUL(6, 18), "HELLO, " "WORLD")returns: HELLO, WORLD
FUNC(fstr[, par1[, par2..]])
calls the function corresponding to fstr with the specified parameters; fstr can be an UDF or another library function, except PUB, AVLTRAVERSE, DICTRAVERSE, STRTRAVERSE, REXFSTRTRAN, REXIFSTRTRAN and all the functions that require passing an UDF; if the number of parameters specified does not match the number of required parameters, a run time error appears; the same thing happens if the function is undefined.
IIF(nTest, exp1, exp2)
returns exp1 if nTest != 0, exp2 otherwise; the value returned has the type of exp1 (or exp2, even if they are different); this function is called inline conditional expression
ISET(id1[,id2..],exp)
sets the value of id1, id2.. to exp; all parameters (except the last one) must be variable names or calls to function PUB on a variable name; returns the value of exp
PUB(id)
this function can only appear inside an UDF; it is the same as using id outside of the function; its only parameter must be a variable name (expressed literally, not enclosed between double quotes); it is the only function that can be prefixed by the character '@', indicating passing by reference, because it represents a variable; as such, it can be used in any circumstance where a variable is expected (e.g. ISET, counter in FOR, etc.). It can be replaced by prefixing the character '_' to the variable name; _id is the same as PUB(id).
Many functions (especially in the data structure chapter) are called 'with handles'; these functions create or use data structures that during execution are permanently created into memory; this implies the need to free memory when they are no longer needed - if the user fails to do so, system resources will decrease until there is no more free memory.
A handle is an integer number, that can be stored, passed to functions or returned by an UDF just like every other variable. Handle functions are logically grouped so that they have a constructor (creates the structure into memory and returns its handle) and a destructor (frees memory and invalidates the handle), together with other functions used to manipulate data as long as they are available in memory.
Another important point involves parameters in the function calls.
As previously said, Proteus is a fully functional language: there are no operators. Parenthesis are no longer needed to establish the order of evaluation for expressions; if the user specifies them where they are not needed (that is everywhere, except in function calls), Proteus prints out a syntax error.
There is an exception, anyway; Proteus has an implicit operator, called the join operator. From a logical and semantical point of view, this poses no threat to language definition, in that joining strings is a completely associative operation and, being the only one performed by an "operator", the order of evaluation is always pre-determined. The choice of adding this feature was originated by the will to shorten expression lengths, thus limiting the number of variables that the user needs to reference. The join operator is invisible; it appears any time two expressions are put side by side on a line, as in this example:
SET FH = FOPEN(BaseDir DIRLAST(H, 1), 1)
The line above is semantically the same as the following:
SET FH = FOPEN(STRCAT(BaseDir, DIRLAST(H, 1)), 1)
Implicit join can appear in any function or UDF parameter, and in a few methods. As appears from the previous examples, using the implicit join simplifies the task of writing the code; programs are also shorter and easier to read and understand.
Start of page | Next topic | Previous topic | Contents | Index |