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

Clune, Thomas L. GSFC-6101 thomas.l.clune
Fri Oct 27 12:43:26 EDT 2017


I have no problem with going for a specific value rather than ?unlimited?.  (Though I am interested in responses to Van?s point about other ?unlimited? things such as lines in a module.)

I would, however, push to be ?out ahead? of the issue rather than simply making the line length sufficient for existing use cases.   History suggests that the requirements for such things do grow over time.    For my immediate use cases  512 characters would be sufficient.   I would like to see at least a 2x safety factor on that though, so 1024 (or above) would have my vote.   

And, since a big driver on my side is the practical need to use __FILE__ for code diagnostics, i.e, we want to know which file and line number detected an error or warning, I would also be open to a Fortran replacement for FPP.   Note that this would not obviate my requirement for FPP/CPP as there is also conditional logic in isolated (but by no means rare) parts of our model, but it would eliminate my current need for longer lines.

- Tom


> On Oct 27, 2017, at 12:21 PM, Bill Long <longb at cray.com> wrote:
> 
> 
>> On Oct 26, 2017, at 7:56 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:
>> 
>> On Thu, 2017-10-26 at 21:47 +0000, Bill Long wrote:
>>> Future memory schemes will involve (faster) memory incorporated into the processor chip, or stacked very close.  And less memory/chip.  With more cores, definitely less memory/core.
>> 
>> This is almost irrelevant to compiling long statements or even long definitions of named constants.  There will almost certainly be more memory per node.  
> 
> I do not understand why you think that.
> 
>> And nobody is advocating gigabytes in a named constant.  
> 
> A gigabyte is way smaller than ?unlimited? which is what some are advocating. 
> 
>> Stop the exaggeration.  If statement length is made unlimited in the standard, which I think is the case in every other real language, and somebody stumbles over a processor's limitation (in the same category as a limit on construct nesting), that's his problem instead of the standard's problem.  It's not the standard's duty to protect every moron from having to think.
> 
> 
> There is no responsible way to say ?unlimited? in the standard.  Instead, we say processor dependent, with a required minimum, which is what I proposed and you rejected. Subclause 4.2 spells out the ?size and complexity? rules, which effectively make any claim about ?unlimited? source form characteristics meaningless.  We need to agree on a minimum requirement and include that in the standard.  We have already done that, and the current agreement is 255 for continuation lines.  If that needs to be changed, it needs to be changed to a specific (and not ridiculous) number. 
> 
> In C (2011), among 15 restrictions on program size, I see
> 
> this:  "	? 4095 characters in a logical source line?.   
> 
> and, for an enum, which is close to a long list in a named-constant declaration, the limit is "	? 1023 enumeration constants in a single enumeration?. 
> 
> I don?t think Fortran is as cripplingly restrictive as you seem to think.  I?d be open to numbers like 1023 or 4095.  
> 
> Cheers,
> Bill
> 
>> 
>> _______________________________________________
>> J3 mailing list
>> J3 at mailman.j3-fortran.org
>> http://mailman.j3-fortran.org/mailman/listinfo/j3
> 
> Bill Long                                                                       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
> http://mailman.j3-fortran.org/mailman/listinfo/j3




More information about the J3 mailing list