(j3.2006) [Fwd: Fortran 2008 query]

Thu Oct 26 17:16:15 EDT 2017

I would also like to add that Van?s reason is not the only driver for such an extension.    Most of my other use cases would involve some form of automated code-generation.    Now, the most sophisticated of these can of course introduce their own line-breaks and fit within the standard.     But at the simpler end are common preprocessors including FPP/CPP that have no such capability.    This is increasingly a problem for me because I use CMake as my configuration engine, and CMake prefers to use absolute paths for files that it sends to the compiler.    This means that diagnostics that use things like __FILE__ can easily exceed 132 characters.    Now, all the compilers provide some means by which this is not an issue.   Some because they count the characters _before_ the expansion, and the others have switches to accept longer lines.  And others simply allow it with an (annoying) warning.   But why should we have to rely on nonstandard support for such a common problem?

Instead of allowing arbitrarily long lines, we could introduce some concept of ?line-feed? which the compiler would interpret as an explicit continuation.    It will not help with all the use cases, but if I could simply get something like ?\\? to be treated as a new line in the generated code then it would fix most of my use cases.   Van would still need an extension to the maximum number of continuation lines though, if I?ve understood correctly.

My 2 cents.

On Oct 26, 2017, at 4:44 PM, Van Snyder <Van.Snyder at jpl.nasa.gov<mailto:Van.Snyder at jpl.nasa.gov>> wrote:

On Thu, 2017-10-26 at 20:27 +0000, Bill Long wrote:
> On Oct 26, 2017, at 2:58 PM, Van Snyder <Van.Snyder at jpl.nasa.gov<mailto:Van.Snyder at jpl.nasa.gov>> wrote:
>
>>
>> We could say that it is a processor-dependent value greater or equal to 1023.
>
> Ridiculously small. Why design a language for machines that were obsolete twenty years ago? We should be designing for the future, not the past.

You mean the real future where the amount of memory/core continues to decline, and where broadcasting the executable out to all the participating processors becomes slower as the size of the executable increases (because of initialized arrays)?    The better option in cases like this is usually to read the data in from an unformatted file when the program starts.  Maybe just to image 1 and broadcast it from there.

The systems we use have had memory per core increase by a factor of four during the last decade.

Memory per core might decline, but memory per node, i.e., memory directly addressable by a core without going through a transport network, probably won't.  Is the lexer phase of the compiler going to be a coarray program?  Maybe so, but will it use all the cores on the processor?  Would every image need to have a buffer for the entire statement?  Is per-image memory going to be limited by (total memory per node) / (cores per image)?

Just because it's possible to read data from a file doesn't mean that's always the best solution (unless you myopically make it the only solution).  Are all the intrinsic function routines (and other math software) that use Pad? approximations going to read their constants from files?  I don't think so.  There is still a need for programs to have constants.  The standard ought not to judge how many are "reasonable" for every program.

Cheers,
Bill

Bill Long                                                                       longb at cray.com<mailto:longb at cray.com>
Principal Engineer, Fortran Technical Support &   voice:  651-605-9024
Bioinformatics Software Development                      fax:  651-605-9143
Cray Inc./ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425

_______________________________________________
J3 mailing list
J3 at mailman.j3-fortran.org<mailto:J3 at mailman.j3-fortran.org>
http://mailman.j3-fortran.org/mailman/listinfo/j3

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.j3-fortran.org/pipermail/j3/attachments/20171026/4f6758a1/attachment.html>