Most symbols denote *functions* or *operators*. A *monadic* function takes as its argument the result of evaluating everything to its right. (Moderated in the usual way by parentheses.) A *dyadic* function has another argument, the first item of data on its left. Many symbols denote both monadic and dyadic functions, interpreted according to use. For example, ⌊3.2 gives 3, the largest integer not above the argument, and 3⌊2 gives 2, the lower of the two arguments.

APL uses the term *operator* in Heaviside’s sense as a moderator of a function as opposed to some other programming language's use of the same term as something that operates on data, ref. relational operator and operators generally. Other programming languages also sometimes use this term interchangeably with *function*, however both terms are used in APL more precisely. Early definitions of APL symbols were very specific about how symbols were categorized, ref. IBM's 5100 APL Reference Manual, first edition, circa 1975. For example, the operator *reduce* is denoted by a forward slash and reduces an array along one axis by interposing its function *operand*. An example of reduce:

In the above case, the **reduce** or **slash** operator *moderates* the *multiply* function. The expression **×/2 3 4** evaluates to a scalar (1 element only) result through **reducing** an array by multiplication. The above case is simplified, imagine multiplying (adding, subtracting or dividing) more than just a few numbers together. (From a vector, **×/** returns the product of all its elements.)

The above *dyadic functions* examples [left and right examples] (using the same **/** symbol, right example) demonstrate how boolean values (0s and 1s) can be used as left arguments for the ** expand** and **/ replicate** *functions* to produce exactly opposite results. On the left side, the **2-element** vector {45 67} is **expanded** where boolean 0s occur to result in a **3-element** vector {45 0 67} - note how APL inserted a 0 into the vector. Conversely, the exact opposite occurs on the right side - where a 3-element vector becomes just 2-elements; boolean 0s *delete* items using the dyadic **/ slash** function. APL symbols also operate on lists (vector) of items using data types other than just numeric, for example a 2-element vector of character strings {"Apples" "Oranges"} could be substituted for numeric vector {45 67} above.

In APL there is *no precedence hierarchy* for functions or operators. APL's *syntax rule* is therefore *different* from what is taught in mathematics where, for example multiplication is performed *before* addition, under order of operations.

The *scope* of a function determines its arguments. Functions have *long right scope*: that is, they take as right arguments everything to their right. A dyadic function has *short left scope*: it takes as its left arguments the first piece of data to its left. For example(leftmost column below is actual program code from an APL user session, indented = actual user input, not-indented = result returned by APL interpreter):

An operator may have function or data *operands* and evaluate to a dyadic or monadic function. Operators have long left scope. An operator takes as its left operand the longest function to its left. For example:

**The left operand** for the **diaeresis each ¨** operator is the **index ⍳** function. The *derived function* ⍳¨ ("iota") is used monadically and takes as its right the vector 3 3. The left scope of **each** is terminated by the **reduce** operator, denoted by the forward **slash**. Its left operand is the function expression to its left: the **outer product** of the **equals** function. (The syntax and 2-glyph symbol of the outer-product operator are both unhappily anomalous.) The result of ∘.=/ is a monadic function. With a function’s usual long right scope, it takes as its right argument the result of ⍳¨3 3. Thus

**Notes:** The reduce and scan operators expect a dyadic function on their left, forming a monadic composite function applied to the vector on its right.

The product operator "." expects a dyadic function on both its left and right, forming a dyadic composite function applied to the vectors on its left and right. If the function to the left of the dot is "∘" (signifying null) then the composite function is an outer product, otherwise it is an inner product. An inner product intended for conventional matrix multiplication uses the + and × functions, replacing these with other dyadic functions can result in useful alternative operations.

Some functions can be followed by an axis indicator in (square) brackets, i.e. this appears between a function and an array and should not be confused with array subscripts written after an array. For example, given the ⌽ (reversal) function and a two-dimensional array, the function by default operates along the last axis but this can be changed using an axis indicator:

As a particular case, if the dyadic **catenate** **","** function is followed by an *axis indicator* (or *axis modifier* to a symbol/function), it can be used to laminate (interpose) two arrays depending on whether the axis indicator is less than or greater than the index origin (index origin = 1 in illustration below):

**Arrays** are structures which have elements grouped linearly as vectors or in table form as matrices - and higher dimensions (3D or cubed, 4D or cubed over time, etc.). Arrays containing both characters and numbers are termed *mixed arrays*. Array structures containing elements which are themselves arrays are called *nested arrays*.

The **user** may define custom **functions** which, like variables, are identified by *name* rather than by a non-textual symbol. The **function header** defines whether a custom function is niladic (no arguments), monadic (one right argument) or dyadic (left and right arguments), the local name of the **result** (to the left of the **← assign** arrow), and whether it has any local variables (each separated by semicolon ';').

Whether functions with the same identifier but different adicity are distinct is implementation-defined. If allowed, then a function CURVEAREA could be defined twice to replace both monadic CIRCLEAREA and dyadic SEGMENTAREA above, with the monadic or dyadic function being selected by the context in which it was referenced.

Custom dyadic functions may usually be applied to parameters with the same conventions as built-in functions, i.e. arrays should either have the same number of elements or one of them should have a single element which is extended. There are exceptions to this, for example a function to convert pre-decimal UK currency to dollars would expect to take a parameter with precisely three elements representing pounds, shillings and pence.

Inside a program or a custom function, control may be conditionally transferred to a statement identified by a line number or explicit label; if the target is 0 (zero) this terminates the program or returns to a function's caller. The most common form uses the APL compression function, as in the template (condition)/target which has the effect of evaluating the condition to 0 (false) or 1 (true) and then using that to mask the target (if the condition is false it is ignored, if true it is left alone so control is transferred).

Hence function SEGMENTAREA may be modified to abort (just below), returning zero if the parameters (DEGREES and RADIUS below) are of *different* sign:

The above function SEGMENTAREA *works as expected if* the parameters are *scalars or single-element arrays*, but **not** if they are multiple-element **arrays** since the condition ends up being based on a single element of the SIGN array - on the other hand, the user function could be modified to correctly handle vectorized arguments. Operation can sometimes be unpredictable since APL defines that computers with vector-processing capabilities *should* parallelise and *may* reorder array operations as far as possible - therefore, **test and debug** *user functions* particularly if they will be used with vector or even matrix arguments. This affects not only explicit application of a custom function to arrays, but also its use anywhere that a dyadic function may reasonably be used such as in generation of a table of results:

A more concise way and sometimes better way - to formulate a function is to avoid explicit transfers of control, instead using expressions which evaluate correctly in all or the expected conditions. Sometimes it is correct to let a function fail when one or both **input** arguments are **incorrect** - precisely to let user know that one or both arguments used were incorrect. The following is more concise than the above SEGMENTAREA function. The below importantly **correctly** handles vectorized arguments:

Avoiding explicit transfers of control also called branching, if not reviewed or carefully controlled - can promote use of excessively complex "one liners," veritably "misunderstood and complex idioms" and a "write-only" style, which has done little to endear APL to influential commentators such as Edsger Dijkstra. *Conversely however* APL idioms can be fun, educational and useful - if used with helpful **comments ⍝**, for example including source and intended meaning/functionality of the idiom(s). Here is an APL idioms list, an IBM APL2 idioms list here and Finnish APL idiom library here.

Most APL implementations support a number of system variables and functions, usually preceded by the **⎕ (quad)** and or **")"** (**hook**=close parenthesis) character. Particularly important and widely implemented is the ⎕IO (Index Origin) variable, since while the original IBM APL based its arrays on 1 some newer variants base them on zero:

There are also system functions available to users for saving the current workspace e.g. **)SAVE** and terminating the APL environment, e.g. **)OFF** - sometimes called *hook* commands or functions due to the use of a leading right parenthesis or hook. There is some standardization of these quad and hook functions.

The Unicode Basic Multilingual Plane includes the APL symbols in the Miscellaneous Technical block, which are therefore usually rendered accurately from the larger Unicode fonts installed with most modern operating systems. These fonts are rarely designed by typographers familiar with APL glyphs. So, while accurate, the glyphs may look unfamiliar to APL programmers or be difficult to distinguish from one another.

Some Unicode fonts have been designed to display APL well: APLX Upright, APL385 Unicode, and SimPL.

Before Unicode, APL interpreters were supplied with fonts in which APL characters were mapped to less commonly used positions in the ASCII character sets, usually in the upper 128 codepoints. These mappings (and their national variations) were sometimes unique to each APL vendor's interpreter, which made the display of APL programs on the Web, in text files and manuals - frequently problematic.

Note the APL On/Off Key - topmost-rightmost key, just below. Also note the keyboard had some 55 unique(68 listed per tables above, including comparative symbols but several symbols appear in *both* monadic and dyadic tables) APL symbol keys(55 APL functions/operators are listed in IBM's 5110 APL Reference Manual), thus with the use of alt, shift and ctrl keys - it would theoretically have allowed a maximum of some **59**(keys) ***4**(with 2-key pressing) ***3**(with tri-key pressing, e.g. ctrl-alt-del) or some 472 different maximum key combinations, approaching the 512 EBCDIC character max(256 chars times 2 codes for each keys-combination). Again, in theory the keyboard pictured below would have allowed for about 472 different APL symbols/functions to be keyboard-input, actively used. In practice early versions were only using something *roughly* equivalent to 55 APL special symbols(excluding letters, numbers, punctuation, etc. keys). Thus early APL was then only using about 11%(55/472) of a symbolic language's at-that-time utilization potential, based on keyboard # keys limits, again excluding numbers, letters, punctuation, etc. In another sense keyboard symbols utilization was closer to 100%, highly efficient, since EBCDIC only allowed 256 distinct chars, and ASCII only 128.

APL has proved to be extremely useful in solving mathematical puzzles, several of which are described below.

Take Pascal's Triangle, which is a triangular array of numbers in which those at the ends of the rows are 1 and each of the other numbers is the sum of the nearest two numbers in the row just above it (the apex, 1, being at the top). The following is an APL one-liner function to visually depict Pascal's Triangle:

Determine the number of **prime numbers** (prime # is a natural number __greater than 1__ that has no positive divisors other than 1 and itself) up to some number N. Ken Iverson is credited with the following one-liner APL solution to the problem:

Examining the converse or opposite of a mathematical solution is frequently needed (**integer factors of a number**): Prove for the subset of integers from 1 through 15 that they are **non-prime** by listing their *decomposition factors*. What are their non-one factors (#'s divisible by, except 1)?

Generate a Fibonacci Sequence of numbers where each subsequent number in the sequence is the sum of the previous two:

A Practical Introduction to APL 1 & APL 2 by Graeme Donald Robertson
APL for PCs, Servers and Tablets - NARS full-featured, no restrictions, free downloadable APL/2 with Nested Arrays by Sudley Place Software
GNU APL free downloadable interpreter for APL by Jürgen Sauermann
YouTube APL Tutorials uploaded by Jimin Park, 8 intro/beginner instructional videos.
SIGAPL Compiled Tutorials List
Learn APL: An APL Tutorial by MicroAPL