From maine@altair.dfrc.nasa.gov Thu Mar 30 18:01:13 2000 Received: from mailhub.dfrc.nasa.gov (mailhub.dfrc.nasa.gov [130.134.81.12]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id SAA27137 for ; Thu, 30 Mar 2000 18:01:12 +0200 (CEST) (envelope-from maine@altair.dfrc.nasa.gov) Received: from mail.dfrc.nasa.gov by mailhub.dfrc.nasa.gov with ESMTP; Thu, 30 Mar 2000 08:00:11 -0800 Received: from altair.dfrc.nasa.gov ([130.134.129.8]) by mail.dfrc.nasa.gov (Post.Office MTA v3.5.3 release 223 ID# 35-62055U1500L100S0V35) with ESMTP id gov for ; Thu, 30 Mar 2000 08:00:10 -0800 Received: (from maine@localhost) by altair.dfrc.nasa.gov (8.9.3/8.9.3) id IAA27357; Thu, 30 Mar 2000 08:00:08 -0800 From: Richard Maine MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14563.31240.842279.479989@altair.dfrc.nasa.gov> Date: Thu, 30 Mar 2000 08:00:08 -0800 (PST) To: SC22WG5@dkuug.dk Subject: (SC22WG5.1760) Interpretation 001 In-Reply-To: <200003301526.RAA26952@dkuug.dk> References: <200003291659.SAA22556@dkuug.dk> <200003301526.RAA26952@dkuug.dk> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Kurt W. Hirchert writes: > I am relatively comfortable with "fixing" the standard to eliminate phantom > exports, because I seriously doubt that anyone has caused one intentionally > (other than in test programs). I am much less comfortable with the > specific changes you propose, because they have other effects that do have > the potential to invalidate real programs. Yes. Please remember that this is an interpretation against an officially published standard that has existing compilers and existing programs. Clarifying things is good - particularly where they are ambiguous enough that different implementations have interpreted things differently. Fixing things that are flat wrong is also necessary. But some of the discussion has wandered into what I can only call redesign. I strongly feel that the interpretation process is not appropriate for things like revisiting restrictions and other design issues that aren't provably wrong - just inconvenient for some applications. If you do so, you are likely to break existing legal programs, or require changes to existing conforming compilers, or both. Perhaps some of this discussion was meant to be suggestions for f2k or future changes. If so, that's more plausible. And it may well be useful, in debating an interp, to consider how the interp would fit with proposed future changes. But I feel it important that it be clear exactly what context a change is being proposed in. It makes a *BIG* difference to me whether a particular change is proposed as part of an interp or as part of a language revision. It hasn't always been clear to me which is being discussed in this thread. (The thread certainly started about an interp, but some of the discussion has been less clear to me on this matter). -- Richard Maine maine@altair.dfrc.nasa.gov