The main design goals of the Perfect language are as follows:
- Provability. It should be possible to construct proofs of program
correctness.
- Expressibility. The language should be sufficiently expressive for a
very wide range of problems.
- Safety. The language must be safe to use for the development of critical
systems.
- Object-oriented support. The language should support object-oriented
development without forcing object-oriented methods on the user where they convey no
benefit.
- Portability. There should be no implementation-dependent language
features. Any implementation-dependent limits (other than run-time memory and
other resource limitations) should be such that the compiler can report if
they are exceeded. If a program which does not refer to features of the
environment compiles successfully under two implementations, and its
specification is deterministic, it should produce identical results in both
cases (except for execution time differences). [Note: this requirement may be
relaxed in the case of floating-point types, as a concession to execution efficiency, and
in recognition that hardware conformance to the IEEE standard is of variable quality.]
- Clarity. The language must be strongly typed and make it clear when the
value of a variable or parameter is changed.
- Productivity. An experienced user should be able to construct correct
programs rapidly, and to read programs written by others.
- Ease of learning. The language should not be difficult for a typical
analyst/programmer to learn. Mastery of Perfect should be easier to achieve than
mastery of C++.
- Implementability. It must be possible to translate Perfect programs to
run efficiently in a wide range of computer environments.
Major principles of Perfect include the following:
- Specification of entities is done separately from describing their
implementations. Descriptions of implementations are optional in those cases where the
translator is capable of generating an implementation.
- Minimisation of side-effects (to promote provability). The evaluation
of an expression is not permitted to have side-effects apart from the creation of new
objects. All changes to variables must be explicit (i.e. the variable must be identified
and the context must clearly indicate that its value is changed).
- Reduced need for explicit pointers in comparison to traditional
programming languages. This is because the use of pointers makes programs very
hard to reason about (due to the pervasive nature of aliasing and side-effects
which abound).
- Economy of concepts (to promote ease of learning).
- Orthogonality. Language constructs may be used in combination and
their semantics are combined naturally.
- Automatic storage management (to promote productivity and
correctness).
- Minimal implicit type conversions (to promote correctness,
clarity and safety).
- Conciseness of frequently-used constructs and symbols (to promote
productivity). Most keywords are abbreviated (usually to a single syllable).
Infrequently-used keywords are written in full (or at least have longer abbreviations) for
clarity.
- The meaning of the program does not depend in any way on characters
that are typically invisible when the source is printed out or viewed using an editor. For
example, non-displayable control characters are illegal; blanks and tabs at the end of a
line have no significance. This promotes clarity and safety.
It is assumed that in the future, Perfect developers will work in the context of a
document-centred Integrated Development Environment (although it is also required that
any Perfect program can be expressed in plain ASCII text form for listing and porting
purposes). For this reason, Perfect differs from some other programming languages in the
following ways:
- A wider range of symbols is used when displaying programs; however,
since users will generally have keyboards supporting standard character
sets, such symbols have simple equivalents (e.g. the predecessor operator will normally be
displayed as a downward-pointing arrow, but the equivalent symbol for this is "<").
- The concept of a file containing part of a complete program is not
central to Perfect. Information hiding is intended to be done by the IDE, not by splitting a
specification into separate parts in different files. However, a traditional multiple-file
compilation model is also supported (initially, it is the only model
supported).
- Since a Perfect program may be held as a single large document, the
language allows for the compiler to recompile only affected sections of the document when
changes are made.
- Most declarations may be forward-referenced without restriction.
- The grammar does not require the parser to distinguish identifiers
used as type names from other identifiers (making it possible to parse portions of Perfect
text without the need for context information).
Perfect Language Reference Manual, Version 5.0, September 2011.
© 2001-2011 Escher Technologies Limited. All rights reserved.