Walt Brainerd wrote:
> 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.
> 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)
