ISO/IEC JTC1/SC22/WG5 N1596 (Draft of 29 Apr 2004)

        Topics within a Discussion of Extensions to CoCo

                          Dan Nagle

I do not want to discuss command line, methods of invocation
or other "outside the source file" issues.  I do want to require
that extensions made which may be controlled via command line
options also be controllable via set file directives.  An f90
or f95 implementation might not have access to the command line,
or a particular processor might not have the concept
of command lines.

Should coco apply file-by-file,
or should multi-file invocations be allowed?
One input file gives one output file may be simpler,
but multi-file invocation may have an ease-of-use
advantage.  My coco allows, but does not require,
multi-file invocation.

If a multifile invocation is allowed,
do coco definitions propagate from file to file?
The advantage of multi-file propagation is that it allows
a single "definitions" file to be the first file processed.
This effect may be obtained via an include file read
into each separate file.

Should coco provide that the values of coco integers
and coco logicals should be available in the source as text?
That is, should
?? integer :: what =3D 4
expand when
real( ?what?) :: foo
is seen?

integer, parameter :: isize =3D 3
type :: vector
   real, dimension( isize) :: elements
end type vector
character( len=3D *), parameter :: vector_fmt =3D '( <?isize?>es16.8 )'

Should coco support any further macro (text substitution)
capability?  Many folks view a preprocessor without a general
macro ability as severely wanting.

If macros are supported, should coco wrap lines?
I think so, otherwise macros are a trap.

If coco supports macros, should file/line/date/time
and coco version be predefined?  I think so, these
are minimal services which a compiler, working with the output
of the preprocessor, will not be able to supply.

If macros are supported, should macros support arguments?
I think so, something as simple as a "preprocessor
statement function" is useless without arguments.
Should arguments be protected from "improper" expansion?
That is, should coco  wrap parenthesis around
macro arguments so ?a?*?a? works with x+y as a?
(so one doesn't have the result x+y*x+y, which is
almost certainly not what is intended).

Should the text/copy mechanism be supported?
On the one hand, these may be viewed as a poor man's
generic feature, on the other, they are more general,
if lower level.  I invented text/copy to make
a "file scope include file" mechanism, originally
aimed towards f77 common blocks.  Nowadays, I use it
more for repeating function definitions with different
kind values in modules.  YMMV, I suppose.  I believe
the value of text/copy is greatly enhanced by arguments,
but strictly, arguments are a separate question.

Should the doc/docfile mechanism be supported?
How valuable is documentation within the source file?
That is, does anyone write LaTex or Unix man page
source within their Fortran source?

Should the assert mechanism be supported?
Preprocessor asserts are a poor man's assert mechanism,
but we presently have no other.

Should the diagnostic mechanisms (dump, options, report)
be supported?
These directives allow documentation of coco's
expanded state, they are useful if the results
of using coco aren't what is expected.

Should the file control mechanisms (endfile, output)
be supported?
These provide a basic file control capability.
Does anyone want to be able to (probably conditionally)
truncate the current input file or to change
the output file?

Should the symbol control mechanisms (ifdef, ifndef, undefine)
be supported?
I don't especially like the spellings (from cpp) but
they are the traditional spellings.  I believe
the capability is useful.