From jkr@jkr.cc.rl.ac.uk  Wed Feb 28 16:46:59 2001
Received: from nameserv.rl.ac.uk (nameserv.rl.ac.uk [130.246.135.129])
	by dkuug.dk (8.9.2/8.9.2) with ESMTP id QAA24019
	for <SC22WG5@dkuug.dk>; Wed, 28 Feb 2001 16:46:59 +0100 (CET)
	(envelope-from jkr@jkr.cc.rl.ac.uk)
Received: from jkr.cc.rl.ac.uk (jkr.cc.rl.ac.uk [130.246.8.20])
	by nameserv.rl.ac.uk (8.8.8/8.8.8) with ESMTP id PAA30504
	for <SC22WG5@dkuug.dk>; Wed, 28 Feb 2001 15:46:58 GMT
Received: (from jkr@localhost)
	by jkr.cc.rl.ac.uk (8.8.8+Sun/8.8.8) id PAA26499
	for SC22WG5@dkuug.dk; Wed, 28 Feb 2001 15:48:48 GMT
Date: Wed, 28 Feb 2001 15:48:48 GMT
From: John Reid <jkr@rl.ac.uk>
Message-Id: <200102281548.PAA26499@jkr.cc.rl.ac.uk>
To: SC22WG5@dkuug.dk
Subject: Iterpretation 22 (Use of NULL() as initialization):
 Revised draft response
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"


Dear WG5,
         Here is a major revision of my draft interpretation response
following comments from Malcolm. The conclusion is unaltered, but the
wording of the answer and edits are much improved. Please ignore my
first draft and look at this one. I have also corrected the typo
DISSASSOCIATE in three places in the question.

I would appreciate comments before I send it to J3, preferably to me in
private.

Cheers,

John. 



NUMBER: 000022
TITLE: Use of NULL() as initialization
KEYWORDS: NULL intrinsic, initialization, default initialization,
          DATA statement
DEFECT TYPE: Erratum
STATUS: J3 consideration in progress

QUESTION: Rules R429, R505 and R540 respectively describe the syntax for
default initialization of pointer components, pointer objects in type
declaration statements and pointer objects in DATA statements.  These rules
seem to indicate that NULL is to be considered a keyword in those contexts.
This has the surprising effect that the first example below is a standard
conforming program, while the second is not.  That is, in some contexts,
something that looks very much like a reference to an intrinsic function, is
in fact a keyword followed by parentheses.

Example 1:

      MODULE MOD
        INTRINSIC NULL
      END MODULE MOD

      PROGRAM PROG
        USE MOD, DISASSOCIATE=>NULL
        INTEGER, PARAMETER :: NULL = 17
        INTEGER :: J = NULL

        INTEGER :: I
        INTEGER, POINTER :: P => NULL(), P2
        DATA P2, I/NULL(), NULL/
        TYPE DT
          INTEGER, POINTER :: P => NULL()
        END TYPE DT
        TYPE DT2
          INTEGER, POINTER :: I
          INTEGER :: J
        END TYPE DT2
        TYPE(DT2) :: S = DT2(DISASSOCIATE(), NULL), S2
        DATA S2/DT2(DISASSOCIATE(), NULL)/
      END PROGRAM PROG

Example 2:

      MODULE MOD
        INTRINSIC NULL
      END MODULE MOD

      PROGRAM PROG
        USE MOD, DISASSOCIATE=>NULL

        INTEGER, POINTER :: P => DISASSOCIATE(), P2
        DATA P2/DISASSOCIATE()/
        TYPE DT
          INTEGER, POINTER :: P => DISASSOCIATE()
        END TYPE DT
      END PROGRAM PROG

In some places in the scoping unit of PROG example 1, NULL() is used to
specify initialization or default initialization, while in others NULL is
a named constant, and DISASSOCIATE() must be used to specify initialization.

1) Is example 1 a standard conforming program?

2) Is example 2 a standard conforming program?

3) Was it the intent of the committee that, within the contexts of R429,
R505 and R540, NULL should be treated strictly as a keyword rather than as a
reference to an intrinsic function?

DISCUSSION:

The intention is that the intrinsic function NULL be referenced with no
arguments in initialization contexts. This is made clear in the middle
of page 49 in the paragraph that begins 'If <initialization>'
[49:20-21] and also in 7.1.4.1. If the intrinsic function has been
renamed, the new name should be used.

ANSWER:

(1) No, the example is not conforming because it references two different
    entities with the same name (NULL the local variable, and NULL the
    intrinsic function).  See 14.1.2.

(2) No, the example does not conform to the standard as published.  This
    is an error, corrected by the supplied edits which make this example
    conforming.

(3) No, the intention was that "NULL()" should be a reference to the
    intrinsic function.  Edits are supplied to remove the keyword status
    of this syntax.


EDITS:

Page 39, subclause 4.4.1, replace the second line of R429 [39:20] by
                     <<or>> => <pointer-initialization-expr>
          R429a  <pointer-initialization-expr> <<is>> <function-reference> 
          Constraint: <function-reference> shall be a reference to the  
                 intrinsic function NULL with no arguments.

Page 47, subclause 5.1, replace the second line of R505 [47:40] by
                     <<or>> => <pointer-initialization-expr>

Page 49, subclause 5.1, in the paragraph that begins 'If
     <initialization>' [49:20-21], replace 'NULL()' by 
     '<pointer-initialization-expr>' twice. 
 
Page 62, subclause 5.2.10, replace the fifth line of R540 [62:19] by
                     <<or>> <pointer-initialization-expr>

Page 62, subclause 5.2.10, in the penultimate line of the page [62:48],
      replace 'NULL()' by 'pointer association status'. 

Page 63, subclause 5.2.10, in lines 1, 7 and 10 of the page [63:1,7,10],
      replace  'NULL()' by  '<pointer-initialization-expr>' thrice. 

SUBMITTED BY: Henry Zongaro

HISTORY: 98-151   m145 Submitted