(j3.2006) New symbol needed in 007

Van Snyder Van.Snyder
Fri Mar 4 16:45:41 EST 2016


On Fri, 2016-03-04 at 21:30 +0000, Bill Long wrote:

> Considering the number of edits in this section, I prefer to wait
> until I see 16-007r1 before deciding if it is something ?entirely
> different from what you?d expect?.


Well, in 16-007, clearly erroneous, not yet complete, and definitely to
be larger and more complicated in 16-007r1, it was already "entirely
different from what you'd expect."




If you compare the descriptions of the attributes of construct entities
in the case of the ASSOCIATE, SELECT TYPE, SELECT RANK, and now the
locality specs of the DO CONCURRENT construct, you will notice that
they're all subtly different.  We've given little attention to
regularity.  I'm becoming more sympathetic to Lawrie Schonfelder's
complaints.


> Do you also find the OpenMP descriptions of private, firstprivate, and
> shared difficult to comprehend?


Anybody who writes things like "undefined allocation status" doesn't
understand Fortran.  Why should we dump stuff from OpenMP directly into
Fortran without pondering how it fits with the rest of the language?

Everything wanted from locality specs, except LOCAL_INIT, can be gotten
with a BLOCK construct, without needing to explain which attributes of
an entity of the same name in the containing construct or scoping unit
the thing has, and which ones it doesn't have, and leading readers to
post "why is that?" questions on comp.lang.fortran.

Users have been asking for decades for a specification in its
declaration that a variable has a value specified by a specification
expression (actually a generalization of it that doesn't restrict to
type INTEGER), instead of a constant expression, without giving it the
SAVE attribute.  Had we ever gotten around to doing that, LOCAL_INIT
would be trivial in a BLOCK construct as well.  If you really want it to
have the same name and initial value as one in the enclosing scope or
construct, you could rename the imported one in an IMPORT statement --
except we rejected that too.

If adding BLOCK ... END BLOCK is too much work for programmers, allow a
<block-specification-part> in a DO CONCURRENT construct.  Why we
insisted we couldn't simply allow it in every construct is still a
mystery to me.


> Cheers,
> Bill
> 
> 
> On Mar 4, 2016, at 3:18 PM, Van Snyder <van.snyder at jpl.nasa.gov> wrote:
> 
> > For the locality specs, we need to add the "dangerous bend" symbol from Knuth's TeXBook:
> > 
> > <db.jpg>
> > 
> > This symbol means "I'm about to explain something that turns out to be entirely different from what you'd expect."
> > 
> > If we insist on adding irregular features that require explanations of byzantine complexity for users to understand that they're not what they expect, we should at least warn readers.
> > 
> > _______________________________________________
> > J3 mailing list
> > J3 at mailman.j3-fortran.org
> > http://mailman.j3-fortran.org/mailman/listinfo/j3
> 
> Bill Long                                                                       longb at cray.com
> Fortran Technical Support  &                                  voice:  651-605-9024
> Bioinformatics Software Development                     fax:  651-605-9142
> Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101
> 
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20160304/202348e6/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: db.jpg
Type: image/jpeg
Size: 2505 bytes
Desc: not available
Url : http://mailman.j3-fortran.org/pipermail/j3/attachments/20160304/202348e6/attachment.jpg 



More information about the J3 mailing list