This page can be safely skipped by the casual reader.
The key words "MUST",
in this document are to be interpreted as described in RFC
is a conformace criteria where the imperative is MUST, MUST NOT, SHALL,
SHALL NOT, or REQUIRED. A RECOMMENDATION
is a conformace criteria where the imperative is SHOULD, SHOULD NOT, or
RECOMMENDED. Adapting the notation of the Conformance
section of the Character Model
for the World Wide Web (hereafter CharMod), we say
A specification, let's say S1, extends this spec (i.e., is
a conforming extension of this spec) if it does not violate any RULE
preceded by [Spec].
An extension of this spec, S1, defines conformance criteria for specifications,
for source text, and for various kinds of software for handing source
text. To aid the reader, all conformance criteria are preceded by '[X]'
where 'X' is one of
- 'Spec' for specifications
- 'Src' for source text
- 'Producer' for producers -- software for producing source
- 'Validator' for validators -- software that reads source
text input and either accepts it or rejects it.
- 'Advisor' for advisors -- software for reporting warnings
about source text input
Any of these conform to an extension of this spec, S1, if it
does not violate any RULE preceded by '[X]' (for the appropriate 'X')
in either this spec or in S1.
[Spec] A spec MUST document the reason for any deviation from a RECOMMENDATION.
[Producer] For a producer to conform to spec S1, the source text it produces
MUST conform to S1.
[Validator] A validator for spec S1 MUST reject source text that does
not conform to S1. The validator SHOULD report an informative enough problem
to help a human diagnose the violation, including source position if possible.
[Validator] A validator for spec S1 SHOULD accept source text that conforms
to S1. If the validator rejects source text for reasons other than lack
of conformance with S1 (whether the text actually conforms or not), the
reported problem MUST clearly indicate the fault lies with the validator
rather than the source text. For example, a validation attempt MAY enounter
resource limits in a validator that are not reflected in the spec.
[Advisor] An advisor for spec S1 SHOULD report a warning about source
text that deviates from any RECOMMENDATIONS in S1. The warning SHOULD
be informative enough to help a human diagnose the violation, including
source position if possible.
[Spec] A spec MUST therefore only state source text conformance criteria
that are feasibly computable (given adequate resources).
The E family
is intended to support secure
programming and adversarial code
reviews. The authors of the source text, the reviewers reading
it to understand what it might do, and the owners of the language
processor on which it runs may all be mutually suspicious parties
with somewhat divergent interests. The conformance criteria on source
text are designed to enable these parties to safely cooperate by use
of these source texts. If source-author (or source-producer-author)
Arthur has a reasonable expectation that a violation by Arthur's source
text might not be caught by code reviewer Raven or language processor
host Hazel, then Arthur may choose to violate that rule, independent
of the wording in standards documents such as this.
For her own protection (and for the protection of those
who rely on her), Hazel's language processor should only load code
that has been accepted by a conforming validator. Likewise, when Raven
reviews Arthur's source text, for her own protection (and for the
protection of those who rely on her), Raven should examine the source
text together with the diagnostics produced by conforming validators
and advisors regarding that source text. (By "code review",
we don't necessarily mean a formal process. Every time Raven looks
at code in her IDE, she's reviewing code. It would be good for IDEs
to incorporate conforming validators and advisors.)
Dependencies and Versions
Some of the E
family of languages -- the E
language, Kernel-E, and TermL -- delegate aspects of their specifications
to other specifications, such as this page. This page in turn delegates
to yet other specifications, such as Java, Unicode, and various IETF and
W3C standards. This page currently intends to support the specifications
of the E family as of the upcoming
E 0.9 release (also to be known
as E alpha). For each E
release, the Version Dependencies Table to the right specifies the minimal
version of these other standards it depends on.
- [Src] Source text written for a given version of E
MUST conform to that version of the E
spec interpreted in light of the specified minimum versions of the dependent
- [Src] Within the limits of knowledge avalable at the time, source
text SHOULD be compatible with that version of the E
spec interpreted in light of the minimal versions of the dependent specifications
For example, the E
language 0.9 spec depends on Java 1.3.1 or later. Therefore, an E
0.9 program SHOULD also be compatible with, for example, the E
0.9 spec interpreted in light of the Java 1.5 spec. Below, we generally
leave out the version number of dependent specifications, and try to link
to the latest relevant version of each one. Please consult this Version
Dependencies Table for the actual minimal dependencies.
[Spec] Note the combinatorial effect: E
0.9 depends on Unicode 4.0 and Java 1.3.1. Java 1.3.1 in turn depends
on Unicode 2.1, so, by implication, to conform to the E
0.9 spec, one MUST conform to Unicode 2.1 through 4.0, and SHOULD conform
to Unicode versions after 4.0.
Besides covering E
0.9, we will also explain how we hope to evolve in upcoming E
releases, and discuss the potential compatibility implications.