From gls@Think.COM Mon Jun 6 08:29:51 1994 Received: from Mail.Think.COM by dkuug.dk with SMTP id AA05212 (5.65c8/IDA-1.4.4j for ); Mon, 6 Jun 1994 18:30:00 +0200 Received: from Galileo.Think.COM by mail.think.com; Mon, 6 Jun 94 12:29:53 -0400 From: Guy Steele Received: by galileo.think.com (4.1/Think-1.2) id AA25337; Mon, 6 Jun 94 12:29:51 EDT Date: Mon, 6 Jun 94 12:29:51 EDT Message-Id: <9406061629.AA25337@galileo.think.com> To: meissner@lynx.cs.usfca.edu Cc: gls@Think.COM, sc22wg5@dkuug.dk In-Reply-To: Loren P. Meissner's message of Fri, 3 Jun 1994 10:45:45 -0700 <9406031745.AA42198@lynx.cs.usfca.edu> Subject: IF CONDITION X-Charset: ASCII X-Char-Esc: 29 Date: Fri, 3 Jun 1994 10:45:45 -0700 From: meissner@lynx.cs.usfca.edu (Loren P. Meissner) Instead of IF Condition (...) then wouldn't IF (CONDITION (...)) then work just as well, where CONDITION is an intrinsic procedure with various arguments Could be. I thought of that, but assumed that for some reason the proposer was trying to avoid the use of functions whose values change "under the table". (There is ample precedent for this in Fortran; else why not have a function RANDOM_NUMBER instead of requiring use of a subroutine?) Moreover, the proposer seemed to avoid even the use of a subroutine, instead preferring the special syntax CONDITION_INQUIRE; I guessed that there might be some efficiency concern, and in any case tried to propose a solution in keeping with the overall tenor of what was already there in the proposal. Anyway, now the issues are more explicitly out on the table, which is good. --Guy