From david@imagine1.com Wed Jan 24 08:07:47 1996 Received: from kitsune.swcp.com (swcp.com [198.59.115.2]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id IAA12279 for ; Wed, 24 Jan 1996 08:07:34 +0100 Received: from ppp19.swcp.com (ppp39.swcp.com [198.59.115.149]) by kitsune.swcp.com (8.6.9/8.6.9) with SMTP id AAA14135 for ; Wed, 24 Jan 1996 00:07:25 -0700 Date: Wed, 24 Jan 1996 00:07:25 -0700 Message-Id: <199601240707.AAA14135@kitsune.swcp.com> X-Sender: evt@swcp.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: SC22WG5@dkuug.dk From: david@imagine1.com (David L. Epstein) Subject: CoCo FAQs (from non-CoCo observers) X-Mailer: A follow-up note. Here are some frequently asked questions about the recent Conditional Compilation (CoCo) straw definition and some answers. Those that have been following the CoCo email reflector will not see anything new. If you want to be added to the CoCo email list, send me a note at david@imagine1.com stating that you want to become a CoCo observer or developer. In general, future technical email on CoCo will not be sent to this (SC22WG5) list. >#1 Why a parameter attribute? For example, the PARAMETER makes sure that DOS or UNIX are not accidently given an override value on the command line. Also, Fortran requires init-expr in the following stmt integer :: system = init_expr So the corresponding CoCo directive also requires an init_expr ... ? integer :: system = DOS ! DOS allowed on rhs since it is a PARAMETER >#2 r8. I'd allow a ?use in an ?if construct. >something like ?if (comand line thing) then > ?use a_big_module > ?else > ?use a_different_big_module > ?endif >seems like a natural way to control things. The other option seems to >be do some sort of file renaming before compiling which is >always risky. Recall that the ?USE directive will supply CoCo variables only. You may be thinking of ?if (comand line thing) then use a_big_module ?else use a_different_big_module ?endif If you did mean ?USE and not USE, I would need to see what the code that follows your chunk of code looks like. My bet is that you can't finish the example without another copy of your ?IF (maybe a different code structure is called for.) This was discussed on the CoCo email and no good example that requires placing ?USE directives inside a CoCo ?IF construct has appeared. >#6 I assume an INCLUDE can contain further coco directives. Probably >want a rule that an INCLUDE can't contain an ?ELSE that matches up >with a ?IF from before the include. X3J3 discussed this in San Diego and everybody disliked the idea, "Keep the INCLUDE the same as in Fortran which allows an ELSE that matches up with a previous IF from a different source text." >#13 Would be nice (I think) if exprs could include a few simple intrinsic >functions; max, min, abs The majority direction of "Minimal, usable subset of Fortran" just says NO to intrinsic functions. This was a biggie when we decided against ?CHARACTER as it would require some intrinsic functions like LEN_TRIM and TRIM and the intrinsic functions are not really needed for ?INTEGER and ?LOGICAL. >#16 Can a ?use appear anywhere or are there rules like in fortran > that it must only appear in a "declaration" section? If I wrote the rules down correctly in the straw vote definition, it would state that a ?use can go anywhere except inside an ?if construct. The obvious way to code is to put it up top, but an INCLUDE may be expanded that brings in somebody elses obvious way of coding. Putting this together, we have a scenario that looks like ?use mod1 ... ?use mod1 where the ... may even be empty (the unobvious way to code ;). This all works ok with the plan. The idea is that a ?use shall appear before any references to the names that exist inside a module (no implicit declarations.) If it weren't for the existing practice of the Fortran INCLUDE, CoCo would be able to require that the ?use directive are "up top". We (X3J3) straw voted on recognizing the Fortran INCLUDE at CoCo-time, this essentially forces a relaxation of ordering rules (unless you have any ideas that we haven't thought of.) The whole idea is that Fred, Wilma, Barney and Betty can each write their own code with CoCo in it. At one point, they all bring their code together with INCLUDE lines and the CoCo works the exact same as when they were in their own offices INCLUDE 'fred' INCLUDE 'wilma' INCLUDE 'barney' INCLUDE 'betty' program everybody call foo() endprogram everybody Since everybody had their own CoCo directives working before bringing all the code together, it shall work the exact same when all these directives are concatenated. Note that Fred and the gang did have to agree on names in this scenario, regardless of CoCo -- external procedure names and module names shall be unique.