 |
Section 4: Requirements for Implementations
|
 |
4.1 Language
- The implementation of the pervasive class BIT shall be such that any array of bits
shall be implemented as a sequence of binary digits adjacent to each other
in storage. This is required to permit the implementations of library
classes to define such a sequence as a single entity which has semantics
defined by the features of the class being defined. An implementation is
not restricted to this when single binary digits are being
manipulated.
NOTE This requirement is independent of whether
or not an implementation includes the Required Library.
- An implementation of an external class which contains
attributes shall so arrange attributes of these in computer storage that
they shall be allocated storage in the same order as the sequence of
definitions in the corresponding source text. Subject to computer system
storage access alignment
restrictions, they shall be packed in adjacent storage locations. An
implementation shall document any such packing restrictions.
4.2 Required Library
- Numeric
Classes - There shall be a mode of operation of the
implementation in which any over or underflow of a numeric operation shall
raise an exception in respect of the object involved.
NOTE This does not apply to the class FIELD for which there cannot be
under or overflow.
- Numeric
Classes - there shall be an implementation-defined value for the number of contiguous binary digits used in implementing the classes CARD, FIELD and INT. This is referred to as num_bits as needed in the remainder of this document. (see also Annex A.2)
- Class FLT -
An implementation shall implement this class in accordance with the IEEE 754 standard for single length
floating point arithmetic. A conforming implementation is required to
document the means of providing an indication if some arithmetic error
occurs.
- Class FLTD
- An implementation shall implement this class in accordance with the IEEE 754 standard for double length
floating point arithmetic. A conforming implementation is required to
document the means of providing an indication if some arithmetic error
occurs.
4.3 Resources
An implementation conforming to this Language specification component shall provide the resources required by the Resource component of this specification.
4.4 Translation
A conforming implementation shall satisfy the following requirements when
used in Standard Mode in respect
of translation of Sather source text into an executable image.
- Provide a means for the user to specify the name of the distinguished program class and, in that
class, the distinguished program method which is the
routine to be used as the program starting point. This shall be
documented.
- Ensure that only those features of classes which are accessible from any possible sequence of feature executions form part of an executable program.
- Accept the source text of a Sather program as given in the Lexis (Section 5 of this
specification).
NOTE |
This requirement is not intended to exclude the possibility that
an implementation can accept input from some tokenised form of program
or library classes. However, an implementation is
required to produce such a tokenised form from original source
text in the form specified in the Lexis. |
- In Standard Mode an implementation shall detect and notify the user in a
human readable manner any element of a source text which does not conform
to the syntax, static semantics and declaration semantics as defined in
this document. Any program which fails to meet these criteria shall be
deemed invalid and, as such, shall be untranslatable.
A translation of a translatable program shall
provide a mechanism whereby any exception raised for which the
program does not provide a handler shall be propagated into the environment
from which the program was invoked.
NOTE |
Such a notification may
be handled in the environment in any appropriate way, which
may (if a human program user is interacting with that
environment) include presentation of a human readable message
relating to the exception which occurred. |
Comments
or enquiries should be made to Keith Hopper.
Page last modified: Wednesday, 25 October
2000. |
 |