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.)
I *thought* it was just going to one person, but OK ...
The more general comment perhaps of interest to the whole list
is that all/most "revisionist" ideas to add a second way to do
something when a decision was made long ago not to do it that
way were rejected. Other examples were edit descriptors to do
advance="no" and cray pointers; there were others.
Also let me emphasize that what is going on is that J3 this
week has been sifting through some 150 suggestions and trying
to pick out those that seem worth pursuing. There is no
"approval" or "disapproval" of anything; however, it is unlikely
that things on the "don't pursue further" list will eventually
get done (that is a personal opinion).
> 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
>
>
--
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
|