To: J3                                                          07-156
From: Bill Long
Subject: UTI 16: bits compatible
Date: 2007 February 05
References: J3/07-007, J3/06-214, J3/06-324


Discussion:

 Unresolved Technical Issue 16 (page 314) asks 'Can "bits compatible"
be folded into a new concept of "type and kind compatible"?'

The present uses of "bits compatible" in 07-007 are as follows:

1) 10.7.2.4 Bits editing [271:7-8] which discusses the use of B, O,
          and Z edit descriptors with input list items that are not of
          type bits.  In this usage, there is no mention of type or
          kind compatibility.

2) 12.4.3.4.5 Restrictions on generic declarations [306:8-11] where
            "bits compatible" is used as part of the definition of
            "TKR compatible".  In this usage, bits compatible is
            paired with type compatible and equal kind type
            parameters, but no mention of len type parameters.

3) 12.5.2.5 Ordinary dummy variables [314:27, 28] which specifies the
          rules for matching of actual and dummy arguments (two uses).
          In this usage bits compatible is paired with type compatible
          and type paramters, both kind (first use) and len (second
          use), with exceptions for character len type parameters.


and corresponding definitions are at:

12.5.2.4 Compatibility with bits objects [314:20-22] which is the
          definition of "bits compatbile".

Annex A [506:10-12] which is the Glossary entry for "bits compatbile".

There are two options for answering the UTI question.

OPTION 1: Leave the text as is.  This was proposed before and approved
by J3 vote. But it was rejected by the editor.

OPTION 2: Invent a new term, X compatible, with some word or phrase
substituted for X. Since uses (2) and (3) are fairly similar, the
logical choice would be to tailor the definition of X compatible for
those cases and just incorporate the current definition of bits
compatible into the text for use (1) without having a term defined for
the concept.

Option 2 requires choosing a phrase for X.  The term "type compatible"
is used in many places in the standard, mostly traceable to type
extension and polymorphism. Examples include [46:19], [66:20],
[126:20], [126:35], [158:15], [163:19], [314:6, 12], [316:2],
[317:Note 12.29], and [408:25].  The suggested phrase of "type and
kind compatible" could easily be misinterpreted as meaning "type
compatible and kind compatible". Given the very different uses for
"type compatible" and "bits compatible", trying to merge these
together seems unwise.  For the purposes of a place holder, I'll use
"argument compatible".


-----

Edits to J3/07-007:

OPTION 1

  (none)

OPTION 2

[271:7-8] In 10.7.2.4 Bits editing, replace the second paragraph with:

"If the input list item is not of type bits, the input field is edited
as if the input list item were of type bits with a kind value equal to
the size of the actual list item in bits."

[306:8-11] Replace the second paragraph of 12.4.3.4.5 Restrictions on
generic declarations with:

"A dummy argument is type, kind, and rank compatible, or <<TKR
compatible>>, with another dummy argument if both have the same rank
and are argument compatible."


[314:19-22] Replace the current 12.5.2.4 Compatibility with bits
objects with:

"12.5.2.4 Argument compatibility

An entity is <<argument compatible>> with another entity if and only
if either one is of type bits, the other is of type bits, integer,
real, complex, or logical, and scalar entities of these types have the
same size expressed in bits, or the entities are type compatible and
the kind type parameters of one have the same values as the
corresponding kind type parameters of the other."

[314:26-31] Replace the second and third paragraphs of 12.5.2.5
Ordinary dummy variables with:

"If the actual argument is of type bits the dummy argument shall be of
type bits. The dummy argument shall be argument compatible with the
actual argument and the length type parameters of the actual argument
shall agree with the corresponding ones of the dummy argument that are
not assumed, except for the case of the length parameter of an actual
argument of type default character associated with a dummy argumnet
that is not assumed shape."

[506:10-12] Delete the current Glossary entry for "bits compatible"
and add a Glossary entry for "argument compatible".