From owner-sc22wg5@dkuug.dk Thu Jun 26 17:11:51 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h5QFBpa3067325 for sc22wg5-domo; Thu, 26 Jun 2003 17:11:51 +0200 (CEST) (envelope-from owner-sc22wg5@dkuug.dk) X-Authentication-Warning: ptah.dkuug.dk: majordom set sender to owner-sc22wg5@dkuug.dk using -f Received: from mailhub.dfrc.nasa.gov (mailhub.dfrc.nasa.gov [130.134.81.12]) by dkuug.dk (8.12.8p1/8.9.2) with ESMTP id h5QFASEc067319 for ; Thu, 26 Jun 2003 17:11:47 +0200 (CEST) (envelope-from maine@altair.dfrc.nasa.gov) Received: from mail.dfrc.nasa.gov by mailhub.dfrc.nasa.gov with ESMTP for sc22wg5@dkuug.dk; Thu, 26 Jun 2003 08:07:46 -0700 Received: from altair.dfrc.nasa.gov ([130.134.20.211]) by mail.dfrc.nasa.gov (Post.Office MTA v3.5.3 release 223 ID# 0-71686U2500L200S0V35) with ESMTP id gov for ; Thu, 26 Jun 2003 08:10:22 -0700 Received: by altair.dfrc.nasa.gov (Postfix, from userid 201) id 0115D350D0; Thu, 26 Jun 2003 08:10:17 -0700 (PDT) From: Richard Maine MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <16123.3289.864752.30730@altair.dfrc.nasa.gov> Date: Thu, 26 Jun 2003 08:10:17 -0700 To: WG5 Subject: (SC22WG5.2829) IMPORT and separate interfaces] In-Reply-To: <200306260900.h5Q907VA065499@dkuug.dk> References: <200306260900.h5Q907VA065499@dkuug.dk> X-Mailer: VM 7.07 under 21.4 (patch 12) "Portable Code" XEmacs Lucid Sender: owner-sc22wg5@dkuug.dk Precedence: bulk Malcolm writes: > Having two kinds of interface bodies with a subtle difference (whatever the > chosen syntax is - a keyword on the interface block or a keyword on the > procedure heading, it's still subtle) control whether host association is > applied or not is IMO immeasurably worse than either having it always or > not having it ever. > > We got this wrong once, we cannot ever fix it there, let's just stick > with it. Consistency and simplicity IMO override having some weird effect > even if it is "nice". I completely agree here. As Malcolm says, we got it wrong once, trying to special-case interface bodies for one particular perceived stlye of application. People make errors because of this all the time. I am convinced that the errors arise mostly not because one way is better or worse than the other - but because we don't consistently use either way. Well, we've blown consistency already unless someone wants to make an incompatible change in that rule. But that doesn't mean that since we have an inconsistency anyway, we might as well forget the whole question. It is bad enough that interface bodies are different from everything else, but having different kinds of interface bodies use different rules is just making the inconsistency more esoteric and harder to remember. No matter what we argue here, people *WILL* get it wrong if there are such subtle differences. They get it wrong today (quite often); I've even seen compilers get it wrong. Making the distinctions more subtle will make the problem worse. People won't think through whatever reasoning we come up with. (We'll probably have trouble recalling it ourselves in 5 years). They will just see the inconsistency... or more likely it won't even occur to them that there is an inconsistency until someone explains that it is why their code isn't working. I'd be happier going the other direction - removing the inconsistency by making an incompatible change in the language so that interface bodies are just like other scoping units. That, of course, would be very controversial...and likely even more so in a TR; it would also invariably mean that compiler writers would end up having to do a switch to provide both behaviors. I don't have quite the guts to seriously propose something so drastic...but I think it would be better than pushing the inconsistency to a more subtle level. At least, if you want to have 2 different host association rules for interface bodies, make it depend in some keywprd directly related to the association instead of making people memorize that some other keyword is changing the host association rules as a side effect. The keyword could be FIXED, with BROKEN being the default for compatibility :-(, but that seems out of scope for the TR. -- Richard Maine | Good judgment comes from experience; Richard.Maine@nasa.gov | experience comes from bad judgment. | -- Mark Twain