Program

│ Deutsch (de) │ English (en) │ suomi (fi) │ français (fr) │ Bahasa Indonesia (id) │ italiano (it) │ português (pt) │ русский (ru) │

A program is either an executable program, that is, the complete and runnable application, or it is that portion of a Pascal Source code file or files that can be compiled and is not declared to be a unit or library. This is sometimes referred to as the main program.

main program

program is a reserved word that introduces a classical program source code file:

program hiWorld(input, output, stderr);

begin
	writeLn('Hi!');
end.

Meanwhile FPC discards the program header, i.e. the first line. The output file name is determined by the source code file's name. However, the program name does become a reserved identifier. In the example above, e.g. attempting to define a constant named hiWorld would trigger a duplicate identifier compile-time error.

The file descriptor list is completely ignored, but in {$mode ISO}. The text variables input, output and stderr are always opened and their names can not be changed in other modes. (cf.: SysInitStdIO is always called in rtl/linux/system.pp)

Thus with FPC the following complete source code example compiles identically as does the previous example.

begin
	writeLn('Hi!');
end.

program structure

A program file has to follow a certain structure. There can be at most one uses-clause and it has to be at the top of the program right after the (depending on used compiler possibly optional) program header.

program hiWorld(input, output, stderr);

uses
	// sysutils for applicationName
	// gettext for internationalization routines
	sysutils, gettext;

resourcestring
	helloWorld = 'Hi!';

begin
	translateResourcestrings(applicationName() + '.%s.mo');
	writeLn(helloWorld);
end.

What comes thereafter, the exact order and number of various sections after the uses-clause until final the compound statement begin…end. is free of choice. However, there are some plausible considerations.

• A type-section comes prior any section that can use types, e.g. var-sections or routine declarations.
• Since goto is known as the devil's tool, a label-section, if any, is as close as possible to the block it is supposed to declare labels for.
• Generally you go from general into specifics: For example a var-section comes in front of a threadvar-section. A const-section comes before a resourcestring-section.
• resourcestring-sections can be either static or global, that means they should appear relatively soon after the uses-clause.
• Direct usage of global variables in routines (or even the mere possibility) is considered as bad style. Instead, declare/define your routines prior any var-(like)-section. (beware: play it safe and set {$writeableConst off})
• Global compiler directives, especially such that allow or restrict what can be written (e.g. {$goto on} allows the use of goto) or implicitly add unit dependencies like {$mode objfpc} should appear soon after the program header.

Taking all considerations into account the rough program structure should look like this (except for label and {$goto on} which are only mentioned for the sake of completeness):

program sectionDemo(input, output, stderr);

// global compiler directives ----------------------------
{$mode objfpc}
{$goto on}

uses
	sysutils;

const
	answer = 42;

resourcestring
	helloWorld = 'Hello world!';

type
	primaryColor = (red, green, blue);

procedure doSomething(const color: primaryColor);
begin
end;

// M A I N -----------------------------------------------
var
	i: longint;

threadvar
	z: longbool;

label
	42;
begin
end.

[The example consciously ignores the possibility of “typed constants”, sticking rather to traditional concepts than unnecessarily confusing beginners.]

see also

• unit
• library