[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

conformance

Since this issue will map directly into section 1.5 of the standard, I thought
you might want to review it before I send it to X3J13. I'll be sending it
out next Monday.
kathy



Issue:        CONFORMANCE-POSITION
References:   Chapter 1, Section 1.5, Working draft of standard
Category:     Clarification
Related Issues: EXTENSIONS-POSITION, LISP-SYMBOL-REDEFINITION, PACKAGE-CLUTTER
Edit history: 12-DEC-88, Version 1 by Chapman
              20-DEC-88, Version 2 by Chapman 
              9-JAN-89, Version 3 by Chapman 
              10-JAN-89, Version 4 by Chapman 
              6-FEB-89, Version 5 by Chapman 
              20-FEB-89, Version 6 by Chapman 
              5-MAY-89, Version 7 by Chapman 
 
Problem Description:
 
Two ways of defining conformance are in terms of conforming code
and in terms of a conforming implementation. How should our standard
define conformance? What is the relationship between conformance and
portability?
 
 
Proposal (CONFORMANCE-POSITION:IMPLEMENTATION-AND-CODE)
 
The standard presents the syntax and semantics to be implemented by
a conforming implementation. In addition, it levies requirements on
conforming code and documentation.
 
Definitions:

Code: One or more Common Lisp forms meant to be evaluated.

Processor: A system or mechanism that accepts code as input, prepares
it for execution, and executes the process so defined with data to produce
results.

Implementation-dependent: Possibly differing between processors and not
necessarily defined for any particular processor.

Implementation-defined: Possibly differing between processors, but defined
for any particular processor.

Extension: A facility in the implemented language that is not given in this
standard but that does not cause any ambiguity or contradiction when added
to the language standard.


Conformance:

A processor conforming with the requirements of this standard shall:

1. accept all the features of the language specified in this standard, 
with the meanings defined in this standard.

2. not require the inclusion of substitute or additional language elements in 
code in order to accomplish a feature of the language that is specified
in this standard.

3. be accompanied by a document that provides a definition of all
implementation-defined features.

4. treat exceptional situations in the manner specified in section 1.4 of
the standard (i.e. the Definitions section. It contains the error terminology.).

5. be accompanied by a document that separately describes any features accepted
by the processor that are prohibited or not specified in this standard.
Such extensions shall be described as  being ``extensions to Common Lisp
as specified by ANSI ...''.

6. produce a conformance statement as a consequence of using the processor,
or that statement shall be included in the accompanying documentation.
If the processor conforms in all respects with this standard, the conformance
statement shall be

``<This processor> conforms with the requirements of ANSI <standard number>''

If the processor conforms with some but not all of the requirements of this
standard, then the conformance statement shall be

``<This processor> conforms with the requirements of ANSI <standard number>
with the following exceptions:
<followed by a reference to, or a complete list of, the requirements of
the standard with which the processor does not conform>.



Code conforming with the requirements of this standard shall:

1. use only those features of the language specified in this standard.

2. not rely on any particular interpretation of implementation-dependent 
features.



Note that code that conforms with the requirements of this standard
may rely on particular implementation-defined values or features. Also note
that the requirements for conforming code and conforming processors do
not require that the results produced by conforming code are always
the same when processed by a conforming processor. They may be, or they may
differ, depending on the code.

Informally, the basic rules for conformance are as follows:
1. Conforming code uses only the syntax specified in the standard.
2. Conforming code is written in only the sequence specified in the standard.
3. Conforming code is written using only the functions, macros,
special forms, variables, and constants specified in the standard.
4. Conforming implementations provide the functions, macros, special
forms, variables, and constants specified in the standard, 
and arrange that they behave in ways 
that conform to the specifications of them in the standard.
The definitions of all other functions, macros, or symbols must accompany 
the code. Extensions to syntax are not allowed in conforming code.
5. Conformance will not be machine-checkable.
6. Conforming code will only be defined in terms of its structure.
 
It's possible for a conformal code to
run in all conformal implementations, but to have allowable
implementation-defined behavior that could make it non-portable.
Insofar as we allow options in the standard this will be true.
 
Portable code is required to produce equivalent results and 
observable side effects in all conforming implementations.   
Portable code is written using only STANDARD-CHAR-P characters.
Portable code is written using no extra optional keyword arguments.
 
 
 
Rationale:
 
The standard must contain information about conformance. Only including 
requirements that would be placed on implementations, however, leaves
the possibility open that something would be overlooked, and so 
implementations may well conform without processing correctly
conforming code. 
 
Current Practice:
 
CLtL generally describes things in terms of what correct code can
expect, but the document itself levies the requirement on an implementation
to support all the described functionality.
 
dpANS C also defined conformance in terms of code.
It has further defined both "conforming" and "strictly conforming" code.
 
Pascal defines conformance in terms of both, PL/I defines conformance in 
terms of conforming code only.
Fortran and Ada say that a conforming implementation correctly processes
conforming code. Ada goes on to say other specific things about
a conforming implementation, Fortran does not at this time but probably
will in its next standard. The ISO conformance guidelines, and the
draft of the SPARC proposal discuss both code and implementations.
 
Adoption Cost:
 
The use of the words "implementation-defined" and "implementation-dependent"
in CLtL and the standard will have to be checked to make sure the uses
and the definitions given above coincide. Any changes that occur as a 
result of this check could potentially affect some user code, but it's 
unlikely. 
Implementations will have to be checked to make sure they conform with the
rules stated above, and conformance statements will have to be added.
Documentation may have to be updated.

Benefits:
 
This definition will give readers and validators a basis on which to read
the standard.
 
Conversion Cost:
 
See Adoption Cost.
 
Aesthetics:
 
None.
 
Discussion:

The information in this issue was derived from three documents:
the C ANSI standard, the "Proposed Draft Techinical Report-Guidelines on the 
preparation of conformity clauses in porogramming languages and Letter Ballot"
(CT22/87-094, ISO/TC97/SC22/WG12 N133 Rev 1, October, 1987), and 
"Specification for Computer programming language Pascal" (BS 6192:1982,
UDC 681.3.06 Pascal: 519.682).