On Tue, Jul 25, 2017 at 9:56 PM, Malcolm Cohen <[log in to unmask]> wrote:
>..
>
> But there are NO processors which implement SAME_TYPE_AS as distinguishing between kinds for all types (as SELECT TYPE does).  Not a single one.  That is because the standard requires them not to distinguish between kinds for derived types.
>
> Focussing on efficiency is anyway a red herring.  What was asked for was to make an incompatible change to the semantics of SAME_TYPE AS.  In my opinion this would be completely unacceptable.  Quibbling with a compiler writer who grumbles about efficiency does not address this rather more important issue.
>..

It was Malcolm who expressed two concerns: semantics and performance.
When asked further about performance, it is now pushed aside.  That is
in a way good because it is highly unlikely anyone is going to do any
quantitative analysis on this matter and in vacuo considerations
surrounding performance and efficiency are usually misplaced,
especially when indulged by those with experience for they are then
heavily riddled with bias.  I expect any focus on efficiency in this
discussion will now remain "a red herring".

So what's left is semantics.  Can other readers please chime in and
indicate their views on this?  To me, it seems debatable as to whether
it is such an incompatible change as presented by Malcolm.  Please the
current standard draft (N2123) on SAME_TYPE_AS intrinsic states:

-------------------------------------------------------
  16.9.165 SAME_TYPE_AS (A, B)
1 Description. Dynamic type equality test.
2 Class. Inquiry function.
3 Arguments.
  A shall be an object of extensible declared type or unlimited
polymorphic. If it is a polymorphic
  pointer, it shall not have an undefined association status.
  B shall be an object of extensible declared type or unlimited
polymorphic. If it is a polymorphic
  pointer, it shall not have an undefined association status.
4 Result Characteristics. Default logical scalar.
5 Result Value. If the dynamic type of A or B is extensible, the
result is true if and only if the dynamic type of
  A is the same as the dynamic type of B. If neither A nor B has
extensible dynamic type, the result is processor
  dependent.
-------------------------------------------------------

I think what is being asked is to either to remove the last sentence
i.e., delete "If neither A nor B has extensible dynamic type, the
result is processor dependent." entirely.  Or as some measure of
consistency with SELECT TYPE block construct, modify this last
sentence to read, "If either A or B is a type of BIND(C) or SEQUENCE
attribute, the result is processor dependent."

Why is this change such an adverse impact on semantics?  I would like
readers to keep in mind SAME_TYPE_AS semantics was revised
significantly starting with Fortran 2008 when support for unlimited
polymorphic was introduced.  Can this intrinsic not be fine-tuned a
bit further to make it useful?

Now if the question is about the benefit of this change, then please
keep in mind every Jane Doe or Joe Blo coder out there using a
compiler with some level of support for Fortran 2008 features
gravitates toward unlimited polymorphic dummy arguments and
SAME_TYPE_AS intrinsic whenever they face a need for some generic
functionality in their code.  This is only because the standard has
not addressed their needs in generic programming adequately yet and
they are looking at 15 years or more (at least 5 for the next revision
and a minimum of 10 for implementations) before they will have better
support..  Here is but one recent example of this:
https://software.intel.com/en-us/node/738294.  There is considerable
disappointment and distress among these coders when they realize the
"processor dependent" aspect to the intrinsic.  To me, they constitute
the voiceless majority who seem to have little to no institutional
support during committee discussions and whose "use cases" seem to go
unnoticed or inadequately represented during discussions.

The point is that regardless of what anyone might feel how a Fortran
user should be coding and whether unlimited polymorphic or any other
related aspect is appropriate, this matter appears important and a
refinement can be beneficial.  It should not just be a ping-pong of
individual likings and preferences, it can do with further engagement
from more readers even if status quo prevails.

Thanks,
Vipul