J3/99-153

Date:    06 June 07, 1999
From:    W. Clodius
To:      J3
Subject: Comments on Section 15


I wanted to make J3 aware of an issue I just noticed.

In thinking about the terminology problems for C interoperability, I decided
to examine the glossary for further problems, and, of course, saw the
editor's note on issues involving the term "IEEE exceptions". This appeared
to be an easy term to resolve after consultation with Section 15.  I was
wrong. Instead I now have several terminology issues to raise, primarily
concerning the title of Section 15: "Intrinsic modules for support of
exceptions and IEEE arithmetic," and the definitions of the terms intrinsic
and exception.

I. The definition of intrinsic

The usage of the term intrinsic in this title is not in agreement with its
definition in the glossary, "An adjective applied to data types, operations,
assignment statements, and procedures that are defined in the standard and
may be used in any scoping unit without further definition or
specification," for two reasons:

        1. the definition of intrinsic doesn't recognize the existence of
intrinsic modules. This can, and should be, easily fixed.

        2. More troublesome is the phrase in the definition of intrinsic,
"and may be used in any scoping unit without further definition or
specification." However every aspect of these modules is processor
dependent.  There are numerous points in this section that imply that
the processor should provide further definition or specification. To me
these are standard extension modules, and not intrinsic modules.

This raises a host of questions that should be addressed:

        1. Should the definition of these modules be as processor dependent
as the draft proposes?
        2. If the modules must be highly processor dependent should they be
defined in the core language or in a separate part of the standard?
        3. If this extension is defined in  Part I, should  the other
extensions defined in Parts II and III, be incorporated into Part I?
        4. If these modules are retained what is the appropriate term to
describe them, i.e., extension modules? How does that interact with the term
extension type, and the definition of intrinsic?
        5.  Some language standards, e.g., Forth, have a separate part of
the document set aside for standard extensions, usually as an appendix not as
part of the main draft. Should that concept be applied to Section 15?

I suspect that many of the same issues extend to the C interoperability
modules.

II. The definition of exception

The usage of the term exception in the title and the first paragraph (and
perhaps other points in the document) imply that what is being defined are
exceptions in general. However, what is really defined are floating point
exceptions that are consistent in their usage with the floating point
exception model defined by the IEEE floating point standards. The term
"floating point exception" appears to be the most descriptive, but "IEEE
exception" may be acceptable.