Term

A block is the combination of optional declarations plus a possibly empty sequence of statements. For instance

var
	x: integer;
begin
	x := 42;
end

is one block. The begin and end is mandatory, whereas everything else is optional.

Note the absence of a program or routine header. When a block follows such a header, it defines the program or routine in question. For instance, the line

procedure foo;

merely declares “there is a procedure going by the name foo”. This declaration needs to be followed by a block^{[fn 1]} to define foo. To separate the definition of a routine from the following code, a block must be concluded with a semicolon (;); a program on the other hand concludes with a dot (.). In Pascal this last character is indeed not part of a block.

Scope

See also the chapter Scope in Programming Fundamentals.

Wikipedia has related information at Scope (computer science)

This should not be news to you, but there has not been a technical explanation. All declarations made within a block are only valid until the respective end. This principle is known as block scope. It becomes particularly apparent with routines:

program scopeDemo(output);
	const
		answer = 42;
	
	procedure foo;
		const
			answer = 1337;
		begin
			{ Here, `answer` refers to `1337`. }
			writeLn(answer);
		end;
	
	begin
		{ Here, however, `answer` refers to `42`. }
		writeLn(answer);
		foo;
	end.

Without defining another value for answer inside the defining block of foo, the value of answer would be 42. However, the redefinition “shadows” the outside constant. Concededly, re‑using the identifier answer is a poor choice and therefore usually avoided, yet sometimes this is desired and used deliberately.

The term scope was first mentioned when you were introduced to the with‐clause. Note, unlike a record you cannot “select” a particular scope. It is not possible to write scopeDemo.answer to refer to the “outside” constant.^{[fn 2]}

Step

A routine invoking itself is called recursion.^{[fn 9]} Each time a routine calls itself we take a recursion step. How does this look like? Well, it is as simple as that:

program recursionDemo(output);
	procedure writeNaturalNumbers(n: integer);
		begin
			if n > 0 then
			begin
				writeNaturalNumbers(n - 1);
				writeLn(n);
			end
		end;
	begin
		writeNaturalNumbers(3)
	end.

Notice that the writeNaturalNumbers(n - 1) appears within the block defining the writeNaturalNumbers procedure. The definition, the block, has not concluded yet (we have not reached the end;) thus the definition of writeNaturalNumbers is incomplete. Nevertheless we can call the routine we are currently defining.

This works because routine activations (calling/invoking routines) do not require knowledge of the implementation, the definition (the associated block). All you need to know to successfully activate (call) a routine is its name, the total number of parameters and their data types. All of that information is given in routine declaration (the procedure or function line immediately preceding a block). This is can be compared to pointer data types not requiring any knowledge of the referenced data type.

Base case

When you take a recursion step, something should and in fact must change. The decision whether to take another recursion step must depend on “something.” If nothing changed the recursion would (in theory) go on forever.^{[fn 10]}

The most frequent method is to use different actual parameter values: the recursion step involves calling the same routine with a different value than it itself (in this recursion step) was called. However, the routine’s definition prevents taking another recursion step depending on an expression that involves the actual parameter’s value.

You can, if you like, in your mind copy the routine definition of a recursive routine that does not employ additional declarations (i. e. no extra variables), to the call site, but need to replace all occurences of the actual parameter reference with the altered expression. What does that mean? Consider the following recursive procedure.

	procedure writeUnaryNumber(n: integer);
		begin
			if n > 0 then
			begin
				write('I');
				writeUnaryNumber(n - 1);
			end;
		end;

Now, everywhere writeUnaryNumber is called you replace it by what is between (the routine definition’s) begin and end.

	procedure writeUnaryNumber(n: integer);
		begin
			if n > 0 then
			begin
				write('I');
				begin
					if n > 0 then
					begin
						write('I');
						writeUnaryNumber(n - 1);
					end;
				end;
			end;
		end;

However, you need to replace n with n−1, that is the expression writeUnaryNumber in the recursive case gets called with. Parentheses are necessary so it is guaranteed this does not alter the meaning (e. g. unintended consequences because of operator precedence).

				begin
					if (n - 1) > 0 then
					begin
						write('I');
						writeUnaryNumber((n - 1) - 1);
					end;
				end;

You can do the entire process as many times as you want.

	procedure writeUnaryNumber(n: integer);
		begin
			if n > 0 then
			begin
				write('I');
				begin
					if (n - 1) > 0 then
					begin
						write('I');
						begin
							if ((n - 1) - 1) > 0 then
							begin
								write('I');
								writeUnaryNumber(((n - 1) - 1) - 1);
							end;
						end;
					end;
				end;
			end;
		end;

This method may be useful in an exam: the examiner asks what a recursive algorithm does but there are no meaningful identifiers. But, again, it works only if there are no additional variables. Obviously, here writeUnaryNumber prints as many I’s as n if it is non‐negative; the procedure name already says that.

Performance

Mathematicians find recursive definitions particularly elegant. For example, most students are first acquainted with the factorial function (indicated by appending a ${\displaystyle$ !} ) by its recursive definition:

${\displaystyle n!={\begin{cases}1,&{\text{ if }}n=0,\\n\times \left(n-1\right)!,&{\text{ if }}n>0.\end{cases}}}$

As programmers we are less concerned about esthetics than we are about performance. In particular, recursive routines are in general quite inefficient since they introduce a certain computing overhead. This circumstance of performance is not rooted in programming language Pascal but due to the way recursive routines are implemented. Therefore, programmers use the iterative definition of the factorial function

${\displaystyle n!=\prod _{i=1}^{n}i}$

which is a concise way of writing

function factorial(n: integer): integer;
	var
		i, result: integer;
	begin
		result := 1;
		
		for i := 1 to n do
		begin
			result := i * result
		end;
		
		factorial := result
	end;

It is, however, wrong to avoid recursive routines at all costs. For example, exponentiation of a real number ${\displaystyle x}$ to a non‐negative integer exponent ${\displaystyle n}$ has a straightforward iterative definition and implementation:

${\displaystyle x^{n}=\prod _{i=1}^{n}x}$

Yet repetitive multiplication requires ${\displaystyle n-1}$ multiplication operations in total, which is terribly slow for any large ${\displaystyle n}$. In fact we can significantly speed up calculations by employing a recursive definition

${\displaystyle x^{n}={\begin{cases}1,&{\text{ if }}n=0,\\\left(x^{\frac {n}{2}}\right)^{2},&{\text{ if }}n>0{\text{ and }}n{\text{ is even}},\\x\times \left(x^{\frac {n-1}{2}}\right)^{2},&{\text{ if }}n>0{\text{ and }}n{\text{ is odd}}.\end{cases}}}$

because this requires only ${\displaystyle \log _{2}n}$ multiplications, i. e. fewer than ${\displaystyle n-1}$ multiplications if ${\displaystyle n>4}$.^{[fn 11]} This is not a math textbook, so do not worry if the reasoning is not apparent.