1.1.1. Extent¶

1.1.1:1 This document specifies:

• 1.1.1:2 The form of a program written in Hash;

• 1.1.1:3 The effect of translating and executing such a program;

• 1.1.1:4 The language-defined libraries that a confirming tool is required to supply;

• 1.1.1:5 The violations that a conforming tool is required to detect, and the effect of attempting to translate or execute a program containing such violations;

• 1.1.1:6 The violations that a confirming tool is not required to detect.

1.1.1:7 This document does not specify:

• 1.1.1:8 The means by which a Hash program is transformed into object code executable by a processor;

• 1.1.1:9 The means by which translation or execution of Hash programs is invoked and the executing unite are controlled;

• 1.1.1:10 The size of speed of the object code, or the relative execution speed of different language constructs;

• 1.1.1:11 The form or content of any listings produced by a tool; in particular, the form or contents of error or warning messages;

• 1.1.1:12 The size of a program or program unit that will exceed the capacity of a conforming tool.

1.1.2. Structure¶

1.1.2:1 This document contains 16 chapters, 1 appendix, and an index.

1.1.2:2 The specification of the Hash language is separated into:

• 1.1.2:3 Chapters 1 through 16,

• 1.1.2:4 Glossary

1.1.2:5 Each chapter is divided into subchapters that have a common structure. Each chapter and subchapter is then organised to include the following segments as is relevant to the topic:

Syntax

1.1.2:6 The syntax representation of a construct.

Legality Rules

1.1.2:7 Compile-time rules and facts for each construct, A construct is legal if it obeys all of the Legality Rules.

1.1.2:8 Legality rules are verified at various stages of the compilation process. The specification may not explicitly state when each legality rule is verified. Conforming tools must only respect the order of verification when it is explicitly stated.

Dynamic Semantics

1.1.2:9 Run-time effects of each construct.

Implementation Requirements

1.1.2:10 Additional requirements for conforming tools.

Examples

1.1.2:11 Examples illustrating the possible forms of a construct. This material is informative.

1.1.3. Conformity¶

Implementation Requirements

1.1.3:1 A conforming tool shall:

• 1.1.3:2 Translate and correctly execute legal programs written in Hash, provided that they are not so large as to exceed the capacity of the tool,

• 1.1.3:3 Identify all programs or program units that are so large as to exceed the capacity of the tool (or raise an appropriate exception at runtime).

• 1.1.3:4 Identify all programs or program units that contain errors whose detection is required by this document.

• 1.1.3:5 Supply all language-defined library units required by this document.

• 1.1.3:6 Contain no variations except those explicitly permitted by this document, or those that are impossible or impractical to avoid given the tool’s execution environment.

• 1.1.3:7 Specify all such variations in the manner prescribed by this document.

1.1.3:8 The external effect of the execution of a Hash program is defined in terms of its interactions with its external environment. The following are defined as external interactions:

• 1.1.3:9 Any call on a foreign function, including any argument operands passed to it;

• 1.1.3:10 Any result returned or panic propagated from a main function or an exported function to an external caller;

• 1.1.3:11 The imported and exported values at the time of any other interaction with the external environment.

1.1.3:12 A tool that conforms to this document shall support each capability required by the language as specified.

1.1.3:13 A tool that conforms to this document may provide additional attributes as long as their names are not the same as the names of built-in attributes.

1.1.4. Method of Description and Syntax Notation¶

1.1.4:1 The form of a Hash program is described by means of a context-free syntax together with context-dependent requirements expressed my narrative rules.

1.1.4:2 The meaning of a Hash program is described by means of narrative rules defining both the effects of each construct and the composition rules for constructs.

1.1.4:3 The context-free syntax of Hash is described a simple variant of the Backus-Naur form, In particular:

• 1.1.4:4 a monospaced font is used to denote Hash syntax.

• 1.1.4:5 Non-monospaced fonts are used to denote a syntactic category e.g.

IntegerLiteral

• 1.1.4:6 Worlds in bold font are used to indicate literal words, and keywords:

struct
if
else

• 1.1.4:7 Characters in bold font are used to indicate literal characters and literal punctuation, for example:

1
N
)
->
<<=

• 1.1.4:8 A character preceded by \ (bold backslash) is used to denote an escaped character, for example:

\n
\t
\
\"
\\

• 1.1.4:9 A prefix followed by ? (question mark) is used to denoted an optional prefix, for example:

IntegerSuffix?

• 1.1.4:10 A prefix followed by * (asterisk) is used to denote a repetition of zero or more occurrences of the prefix, for example:

TokenTree*

• 1.1.4:11 A prefix followed by + (plus sign) is used to denote a repetition of one or more occurrences of the prefix, for example:

TokenTree+

• 1.1.4:12 [ ] (square brackets) indicate any character within, for example:

[a _]

• 1.1.4:13 ~[ ] (square brackets preceded by tilde) indicate any character except the characters within:

~[\r \n :]

• 1.1.4:14 [ - ] indicates any character within the specified range, inclusive:

[a..z A..Z]

• 1.1.4:15 A | (vertical bar) separates alternative items, for example:

Identifier | DecimalLiteral

• 1.1.4:16 ( ) (parentheses) are used to group items, for example:

(, MatchArm)

• 1.1.4:17 Whenever the run-time semantics define certain actions to happen in an arbitrary order, this means that a tool arranges for these actions to occur in a way that is equivalent to some sequential order, following the rules that result from that sequential order. This can happen for example, if two parameters of a given call expression have side effects.