Oberon/Naming

Conventions for names of constants, variables, types, procedures, functions and modules are in the Oberon language FAQ.

Files, Servers and Viewers

In The Oberon System; User Guide and Programmer's Manual, p. 42, Martin Reiser stated,

2.7 Naming

Oberon provides structured names to identify objects such as files, servers and viewers. The syntax of names is:

Name = NamePart { "." NamePart }

NamePart = Letter { Letter | Digit }

Why such primitive syntax? Readability an obvious factor. Security an intrepid actor. Linux file names illustrate.

Naming in A2

To identify target hardware, A2 has adopted conventions for file name extensions.

Within software, A2 has the Oberon subsystem. Distinction of the name of a module of the subsystem from the name of a module of A2 was addressed in "Proposal for Modules Contexts" by F. Friedrich and F. Negele. The syntax to prevent name conflict is in Active Oberon.

Module := 'MODULE' [TemplateParameters] Identifier ['IN' Identifier] ';' ...

Hence this example.

MODULE System IN Oberon;

By convention only, the file may be named with the identifiers separated by ".". Hence the file name associated with the preceding example is "Oberon.System.Mod".

Context in General

In a syntax lacking context, an identifier in a comment may help to explain module usage.

Module := 'MODULE' Identifier '(* IN' Identifier '*);' ...

The Oberon filesystem does not support folders but the name of a file containing a module source can differ from the name of the module. Therefore file name conflict can be avoided by prefixing.

NameOfModuleFile := Identifier Identifier '.Mod'

In ETH Oberon for example, jdEdit.Mod would suggest that J. Doe had revised the Edit module from a release.