Walt Brainerd wrote:

[log in to unmask]">Just so you won't have to worry. The suggestion to use .
was soundly squashed yesterday by J3. (Note that this is
sent to you only.)

    Uh, I got this via the comp-fortran-90 mailing list.

    I'm not surprised. There are many reasons not to implement this feature. J3 has a long history of not liking syntax synonyms, even if some persons consider the original syntax decision(s) to be sub-optimal. Also, it is part of human nature generally not to be willing to admit mistakes or the weaknesses of previous positions. That is why so many individuals and groups often persist in maintaining previous positions even after serious weaknesses become glaringly obvious. And this is clearly a cosmetic issue, not a serious defect in the language. Cosmetic fixes are clearly far less important than fixing serious defects or providing important new functionality. But putting any feature into the standard takes limited resources away from other features.

    I was the person who submitted this feature for inclusion in Fortran 2003++. I knew when I submitted it that it would be a long shot at best. Oh well, I tried.

[log in to unmask]">J.L.Schonfelder wrote:

--On 02 March 2004 12:48 -0700 James Giles <[log in to unmask]>
wrote:

Craig Dedo wrote:
...

[...]               All of
the vendors that have implemented this extension use the same rule in
cases of ambiguity. In such cases, structure component delimiter takes
precendence over other uses of period, i.e., the period is a structure
component delimiter and **NOT** an operator delimiter.

That can't be the rule. The whole purpose of defined operators is
to allow the programmer to create operators that work on his
derived types. What you mean is that the implementations apply
the rule you cite *only* if there's an ambiguity, not that they
*always* treat period as a component selector. That is, the
string X.Y.Z will be interpreted as a single qualified name if Y
is a component name of the X's type, even if .Y. is an operator
that's visible in the same context. But, .Y. will be treated as an
operator if X's type has no component called Y. Of course, it's
just an error if Y is neither an operator nor a component name.

Given that clarification, I'm still not sure I like the rule, but I
suppose it's tolerable.

No it is not tolerable. It is a totally unecessary cosmetic change to add
the use of period as the component selector.

However in a private reply a suggestion that should be considered was to
use @ as an alternative selector when the order is component@structure and
also to permit arraycomp@arraystructure selections that map simply to
multidimensional array.

--
J. Giles

--
Lawrie Schonfelder
Honorary Senior Fellow
University of Liverpool
1 Marine Park, West Kirby,
Wirral, UK, CH48 5HN
Phone: +44 (151) 625 6986

--
Walt Brainerd         +1-877-355-6640 (voice & fax)
The Fortran Company   +1-520-760-1397 (outside USA)
6025 N. Wilmot Road   [log in to unmask]
Tucson, AZ 85750 USA http://www.fortran.com

--
Sincerely,
Craig T. Dedo
17130 W. Burleigh Place             E-mail:       [log in to unmask]
Brookfield, WI   53005-2759         Voice Phone:  (262) 783-5869
USA                                 Fax Phone:    (262) 783-5928

"They that can give up essential liberty to obtain a little temporary
    safety deserve neither liberty nor safety."  -- Benjamin Franklin
    (1759)