From owner-sc22wg5@open-std.org  Mon Mar  3 06:54:47 2008
Return-Path: <owner-sc22wg5@open-std.org>
X-Original-To: sc22wg5-dom6
Delivered-To: sc22wg5-dom6@open-std.org
Received: by open-std.org (Postfix, from userid 521)
	id 03559DA6BD; Mon,  3 Mar 2008 06:54:47 +0100 (CET)
X-Original-To: sc22wg5@open-std.org
Delivered-To: sc22wg5@open-std.org
Received: from ns.nag-j.co.jp (218-42-159-107.cust.bit-drive.ne.jp [218.42.159.107])
	by open-std.org (Postfix) with ESMTP id 1045038508
	for <sc22wg5@open-std.org>; Mon,  3 Mar 2008 06:54:29 +0100 (CET)
Received: from 218-42-159-108.cust.bit-drive.ne.jp ([218.42.159.108] helo=marucomputer)
	by ns.nag-j.co.jp with esmtp (Exim 4.50)
	id 1JW3Vo-0001nk-62
	for sc22wg5@open-std.org; Mon, 03 Mar 2008 14:46:56 +0900
Date: Mon, 03 Mar 2008 14:57:02 +0900
To: WG5 <sc22wg5@open-std.org>
Subject: Re: [ukfortran] (SC22WG5.3538) N1718: co_lbound and co_ubound
From: "Malcolm Cohen" <malcolm@nag-j.co.jp>
Organization: =?iso-2022-jp?B?GyRCRnxLXCVMJWElaiUrJWslIiVrJTQlaiU6JWAlOiUwGyhC?=
 =?iso-2022-jp?B?GyRCJWshPCVXM3Q8MDJxPFIbKEI=?=
Content-Type: text/plain; charset=iso-2022-jp
MIME-Version: 1.0
References: <20080229200013.07177D8911@open-std.org>
Content-Transfer-Encoding: 7bit
Message-ID: <op.t7fetcwdfmufgt@marucomputer>
In-Reply-To: <20080229200013.07177D8911@open-std.org>
User-Agent: Opera Mail/9.26 (Win32)
Sender: owner-sc22wg5@open-std.org
Precedence: bulk

On Sat, 01 Mar 2008 04:59:51 +0900, John Reid <j.k.reid@rl.ac.uk> wrote:
> N1718 is without co_lbound and co_ubound. I think this is a mistake.

I agree.

In retrospect it is a pity that 08-131 didn't have a reminder NOT to
delete those (they are mixed in with the collectives), as it was a
pretty easy mistake to make...

...but the mistake and the responsibility are certainly mine alone.
My apologies.

But does this mean we need a new document before proceeding to CD?
The missing routines are certainly convenient (and should be reinstated
in the next revision whenever that is) but they are I think not
essential to coarray programming (unlike THIS_IMAGE et al), so
it doesn't appear to be a fatal flaw.

(Producing a new document is neither cost-free nor risk-free...)

Opinions?

Cheers,
-- 
................Malcolm Cohen (malcolm@nag-j.co.jp)

