(j3.2006) defining a type with no components

[Malcolm Cohen]

On Apr 16, 2014, at 17:34 , Malcolm Cohen <malcolm at NAG-J.CO.JP> wrote:
> Try [452:34].  This answers all the definition questions.
>
>Which reads ?A derived-type scalar object is defined if and only if
>all its nonpointer components are defined.?
>
>So since foo has no nonpointer components, they?re all defined.

Dan Nagle writes:
>It seems just as logical to say they?re all not defined,
>or all green, or all not green.
>
>Is there a more clear statement I missed?

You literally ***CAN NOT*** get more clear than an "if and only if" definition.

...
>If this were merely a case of ?one must read the whole section to understand?

You only need to read the definition quoted above, which categorically states 
the definition status of a derived-type scalar object.  The are no "ifs buts or 
maybes" in that definition.

Bill Long writes:
>For me, the confusion is that we have a specific subclause, 16.6.2 ?Variables 
>that are always defined? which lists zero-size arrays and strings, but NOT 
>variables of an empty type.

Fair enough, but that subclause does NOT state that there are not other 
variables that are always defined.  In fact we know for a fact that there are 
other variables that are always defined: for example,
   REAL :: x = 3
when the program contains no assignments etc. to X.

16.6.2 is dangerously incomplete!  You cannot draw ANY inference from what it 
does not say.

>If variables of an empty type are, in fact, always defined, it would be a 
>helpful clarification to actually say so in 16.6.2.

It could equally well be contended that 16.6.2 is pointless misleading waffle 
and should be deleted with extreme prejudice.

I find it somewhat boggling that anyone can read a sentence that is not there 
and therefore ignore the categorical statements that *ARE* there!

It would be better to replace the whole of 16.6.2 with a NOTE saying
  "A consequence of the above rules is that a zero-sized array or a zero-length 
character string will always be defined.  Similarly, a derived-type object which 
has no nonpointer components will always be defined."

But adding any complicated case to 16.6.2 which will invariably be incomplete 
would be very likely to increase the risk of a misunderstanding, not decrease 
it.

>See 14-144

Not much of an improvement - it still misses out plenty of cases I can think of. 
Really, if we are going to change 16.6.2 at all it needs to be a note.  And some 
wording improvements elsewhere in 16.6 would be in order.

The fact is that 16.6.2 is simply a consequence of other rules, i.e. it is 
completely duplicative text.  We all know what happens with duplicative text - 
if you are extremely lucky only one of the copies will be wrong.  The more I 
look at this case the more I think that 16.6.2 is harmful duplication.

> Is the simple act of including a declaration sufficient to cause
> the result to ?be defined by the function??

No, but executing the function is.  Just like
   CHARACTER(0) FUNCTION f()
   END
and
  FUNCTION g()
    REAL g(0)
  END

Yes the function return result requirements could be better worded (it's already 
been noted that the wording is not quite right viz its use of "value" - if we 
are going to fix that I do not think I would be in favour of fixing it 
wrongly!).  Anyway, I don't see any serious problem here though, as executing 
the function WILL cause the result variable in ALL of these cases to become 
defined (it is not defined beforehand because it does not even exist).

Oh and similarly the "events that cause" subclauses are chock-full of unstated 
"actually this does not apply to a zero-sized array" etc.  I'm not terribly 
sympathetic.  People trying to rules-lawyer based on what is not said in 16.6 
are on a hiding to nothing (even rules-lawyering based on what *is* said in the 
"events" clause is pretty edgy).  It is very very easy to leap into 16.6 with 
some edit that on the appears to make sense and fixes some things, but actually 
breaks other things as well - i.e. not progress.

I am sure we can make some progress to make this a bit easier to read, but 
largely 16.6 however badly worded is not leading to significant implementation 
difficulties, so let's not get too concerned about its flaws.  Which have been 
there like forever man.

Cheers,
-- 
................................Malcolm Cohen, Nihon NAG, Tokyo.