From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org  Fri Dec  5 07:32:32 2014
Return-Path: <owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org>
X-Original-To: sc22wg5-dom8
Delivered-To: sc22wg5-dom8@www.open-std.org
Received: by www.open-std.org (Postfix, from userid 521)
	id B544135852E; Fri,  5 Dec 2014 07:32:32 +0100 (CET)
Delivered-To: sc22wg5@open-std.org
Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51])
	by www.open-std.org (Postfix) with ESMTP id EFF03356E14
	for <sc22wg5@open-std.org>; Fri,  5 Dec 2014 07:32:31 +0100 (CET)
Received: by mail-pa0-f51.google.com with SMTP id ey11so81662pad.24
        for <sc22wg5@open-std.org>; Thu, 04 Dec 2014 22:32:31 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:subject:mime-version:content-type:from
         :in-reply-to:date:cc:content-transfer-encoding:message-id:references
         :to;
        bh=oxqiSXuqyGFn0bVEc6/tAgiBM2EcVUb0KfRolP2zqA4=;
        b=mXmhSaLYwswemp3Uq/6TcA+n+z48woXEMg0+1oN7SHAv4sQ7u3rH+j+/M8cDYnSxKY
         muRMn3dzr6uQ7x7EqTePQufGjbXdbaUUi9j/j75l/SPLlYGlbGN9822Ild6MUG5b9a+Y
         axsMgTwLXeULtwRzGGaUSFVLhjSmacdaqVNXtmO7o2x2ng9D5bwOiIzLZqP15HfxrOkW
         DpphMDlR116igbyLdKVvGbDOIhB6Umh0pL5WRonoHr3UO2XaDNHMvZ6DZK6E9uyhWrvF
         GFD9mgVInGkRFDNuGQH6qMSfu51N4mmQRUwuPw5HN+9nPYXIY6tQ9VfLSXqQv83fi/xP
         n8qA==
X-Gm-Message-State: ALoCoQk2W4LI6fqETcxX0RSR/F3BFdeiNnth/QvQFPG47Oy9pYnA2Hnj7Ek856TXR03IP6sq3Naa
X-Received: by 10.66.231.141 with SMTP id tg13mr25971539pac.122.1417761150858;
        Thu, 04 Dec 2014 22:32:30 -0800 (PST)
Received: from ?IPv6:2601:9:a80:179f:3854:97ee:be9c:f448? ([2601:9:a80:179f:3854:97ee:be9c:f448])
        by mx.google.com with ESMTPSA id ml5sm28123925pab.32.2014.12.04.22.32.29
        for <multiple recipients>
        (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
        Thu, 04 Dec 2014 22:32:30 -0800 (PST)
Subject: Re: (j3.2006) (SC22WG5.5373) [ukfortran] Question on PURE subroutines
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: text/plain; charset=windows-1252
From: Damian Rouson <sourcery@rouson.net>
X-Priority: 3
In-Reply-To: <20141205014042.EC050358538@www.open-std.org>
Date: Thu, 4 Dec 2014 22:32:28 -0800
Cc: WG5 <sc22wg5@open-std.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6EC948C0-0499-4360-A131-F5A4192B0A94@rouson.net>
References: <20141204170247.9A28E35837D@www.open-std.org> <20141205014042.EC050358538@www.open-std.org>
To: fortran standards email list for J3 <j3@mailman.j3-fortran.org>
X-Mailer: Apple Mail (2.1878.6)
Sender: owner-sc22wg5@open-std.org
Precedence: bulk



On Dec 4, 2014, at 5:25 PM, Malcolm Cohen <malcolm@nag-j.co.jp> wrote:

> [of a pure subroutine]
>> Yet it appears to implement a side effect in a PURE procedure. Was =
this=20
>> intended?
>=20
> I should point out that if a pure subroutine cannot have a side =
effect, it can=20
> be replaced by a NOP (since it has no return value).

which is exactly why I=92m not a huge fan of pure subroutines, =
especially those that have =93intent(inout)=94 arguments.  At least if =
all the arguments are either =93intent(in)=94 or =93intent(out)=94, then =
pure subroutines would seem to be no different from pure functions if =
one considers all of the subroutine's =93intent(out)=94 arguments to be =
one collective result. =20

On a somewhat related note, Tom Clune suggested a while back that there =
be a =93virtuous=94 attribute that would preclude any access to =
non-local state.   =46rom the standpoint of purely functional =
programming, I think this would remove a wart that exists with PURE =
procedures at least in terms of how many people would initially =
interpret the meaning of PURE.

Damian=