J3/04-304

Date: 5-May-2004
To:   J3
From: Interop/interp/Bill Long
Subj: Answer to F90 interpretation # F90/000206

NUMBER: F90/000206
TITLE: Collating sequence inconsistencies
KEYWORDS: Collating sequence, ACHAR, CHAR, ICHAR
DEFECT TYPE:
STATUS: J3 consideration in progress

[F95 CD 36:28+] says that "A <<collating sequence>> is a one-to-one
mapping of the characters into the nonnegative integers such that
each character corresponds to a different nonnegative integer."

QUESTION 1: Does this definition imply that the one-to-one mapping is
dense? That is, is there a requirement that if the default CHARACTER
type has <n> characters, the corresponding collating sequence maps
to 0..<n>-1 ?

QUESTION 2:
If the answer to question 1 is NO: is it correct that the restriction
  0 <= i <= <n>-1
on argument I of the intrinsic procedure CHAR (13.14.19) is inappropriate?

QUESTION 3: If the answer to question 1 is NO: is it correct that the
description of the << Result Value>> of the intrinsic procedure ICHAR
(13.14.45), 0 <= ICHAR(C) <= <n>-1 is inappropriate?

QUESTION 4: Shouldn't argument I of the intrinsic procedure ACHAR
(13.14.2) be restricted to the nonnegative integers?

ANSWER:

(1) Yes. In the context of Fortran the character collating sequence is
    an ordered list of the characters in the character set associated
    with a list of integers denoting the position of each
    corresponding character in the ordered list of characters. The
    position number 0 is associated with the first character in the
    list. As position numbers, the list of integer values is
    necessarily dense. These position numbers are referenced in the
    descriptions of the CHAR and ICHAR intrinsic functions. The
    position numbers may be, but are not necessarily, equivalent to
    the bit patterns used to represent the associated characters in
    the computer hardware.

(2) Moot because the answer to (1) is Yes.

(3) Moot because the answer to (1) is Yes.

(4) No.  For characters that are not part of the ASCII character set,
    IACHAR  returns a processor-dependent value that need not be in
    the ASCII collating sequence.  ACHAR, being the inverse of
    IACHAR, should accept such values.


EDIT: None.

SUBMITTED BY: Michael Hennecke (hennecke@rz.uni-karlsruhe.de)

HISTORY: submitted Feb. 17, 1996    (first appeared in 96-006r2)
         WG5/N1404          Draft answer
         00-260      m154   Passed by J3 meeting
         00-329      m155   Failed J3 letter ballot
         04-304      m168   Submitted for J3 meeting vote