From keith.bierman@Eng.Sun.COM Thu Jan 23 20:41:33 1997 Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id UAA11067 for ; Thu, 23 Jan 1997 20:41:30 +0100 Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA10951; Thu, 23 Jan 1997 11:40:44 -0800 Received: from chiba.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA20586; Thu, 23 Jan 1997 11:40:08 -0800 Received: from chiba by chiba.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA25222; Thu, 23 Jan 1997 11:39:48 -0800 Message-Id: <199701231939.LAA25222@chiba.eng.sun.com> To: Miles Ellis cc: sc22wg5 Subject: Re: (SC22WG5.1251) Informal Review of Conditional Compilation Draft Standard In-reply-to: Your message of "Mon, 20 Jan 1997 17:52:56 GMT." <199701201750.SAA16714@dkuug.dk> Date: Thu, 23 Jan 1997 11:39:47 -0800 From: Keith Bierman QED I believe that the current draft is ready for | | NO | submission to SC22 for its first CD ballot |_____|____| If NO, please provide details of what changes you wish to see made in order that the document will be suitable for submission to SC22 for balloting. 1) Replace the text with that submitted by lrr. The lrr proposal is in keeping with existing practice, and meets more of the details of the user requests which motivate this work. Assuming (1) isn't implemented: 2) "ISO/IEC 1539 is an auxiliary standard to ISO/IEC 1539" I know we've gone around in circles on this for years, but I thought that once we'd gone to multiparts of a single standard that the term "auxiliary" was effectively meaningless. If not, the text should make clear what the term means in the formal ISO context. 3) "Coco execution is a sequence, in time, of actions specified by the coco directives. The actions are performed in the order that the directives appear. The result is conceptually a sequence of lines that is identical" I was unaware that we wrote standards specifying the "time" of actions. I thought we restricted ourselves to something along the lines of observable sequences (I'd just say sequence, but we usually leave room for optimization ;> not that I think we need that latitude in this area). 4) note cc6.4, it seems that a processor can essentially do anything; what is the utility of this note? If the goal is to specify that if a file is produced, how the FALSE blocks should be written, it should say so more clearly. 5) "processor-dependent manner. Execution of a coco ERROR directive does not halt coco execution." Sounds more like what the English word "WARNING" usually means. STOP seems to be used for "fatal error". So I take it the intended idiom is for careful programmers to use "ERROR" to produce messages, and STOP to halt processing. If so, "ERROR" is really more of a generic coco PRINT statement, isn't it? If so, the name "ERROR" seems awkward in the extreme. 6) The same users that have asked for conditional compilation nearly always ask for macro expansion. This proposal is defective in addressing the clearly articulated user request. 7) "from the coco program. A processor may allow many coco-set-options." I don't understand, is this saying that a processor *may* allow for several different mechanisms to propagate options into coco processing or that a processor may allow more than one value to be set (if the latter, doesn't that have the effect of only allowing users to set a single option if they have any plans for portability?). I would not be surprised if a close examination by the committee (or a serious public review) revealed other shortcomings. (signed) Keith Bierman (date) 1/23/97