Home > Archive > Fortran > July 2004 > Extensible Types
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Gary Scott 2004-07-13, 8:58 pm |
| The draft 2K3 standard is quite verbose as to when a type is to be
considered extensible. When is a type not considered to be
extensible?
| |
| Richard Maine 2004-07-13, 8:58 pm |
| gary.l.scott@lmco.com (Gary Scott) writes:
> The draft 2K3 standard is quite verbose as to when a type is to be
> considered extensible. When is a type not considered to be
> extensible?
Verbose? Maybe you looked in the wrong place? The definition easily
fits on one line, namely the first line of 4.5.6
"A nonsequence derived type that does not have the BIND attribute is
an extensible type."
Admitedly, if I had my way with some of the definitions, we could
have dropped the bit about the BIND attribute and just made this
"A nonsequence derived type is an extensible type."
which would be less verbose, but I lost that one. :-(
By the way, what I lost on was saying that BIND types were a
special kind of sequence types. They act just like sequence types
with some extra restrictions and with special interpretation in
regards to C interop. But since we didn't define them that way,
lots of places in the standard have to say the same thing about
sequence types and bind types.
To reorganize the words, but say the same thing as the standard,
to be an extensible type, it needs to be a derived type and
not be a sequence (or BIND) type. I.E. most derived types are
extensible.
I think that Giles once commented that he might start regarding
SEQUENCE as a way to spell non-extensible, since he objected to
making so many types extensible by default. (Apologies if I
misrecalled or misstate his comment).
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| James Giles 2004-07-13, 8:58 pm |
| Gary Scott wrote:
> The draft 2K3 standard is quite verbose as to when a type is to be
> considered extensible. When is a type not considered to be
> extensible?
Unfortunately *all* derived types are extensible. They
removed the (useful) keyword EXTENSIBLE from the
final draft. The default *used* to be that types were
not extensible unless they were explicitly declared to
be. Now the rule is that all type are extensible. This
means that if you change a type that you weren't aware
was being extended by other code, you've changed the
meaning of that other code (possibly without any
warning to the developer or maintainer of that code).
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| James Giles 2004-07-13, 8:58 pm |
| Richard Maine wrote:
....
> I think that Giles once commented that he might start regarding
> SEQUENCE as a way to spell non-extensible, since he objected to
> making so many types extensible by default. (Apologies if I
> misrecalled or misstate his comment).
Nope, I had forgotten making the comment (as well as the
fact that SEQUENCE types were not extensible). But, I was
right then, and I'll start to remember the rules once implementations
exist that have the problem.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| Gary L. Scott 2004-07-14, 3:57 am |
| Richard Maine wrote:
>
> gary.l.scott@lmco.com (Gary Scott) writes:
>
>
> Verbose? Maybe you looked in the wrong place? The definition easily
> fits on one line, namely the first line of 4.5.6
Verbose in the sense that it describes what makes a type extensible in
about 60 places. My Acrobat 6 doesn't work well with my Netscape 4 so I
was having trouble with the search tool (could not access the search
results (was simply blank so I didn't know it was missing) to step to
the next one). I eventually figured it out and switched to IE (haven't
recovered Mozilla yet since the "upgrade") but by that time I had spent
too much time looking.
>
> "A nonsequence derived type that does not have the BIND attribute is
> an extensible type."
Yup, read that. It defines a condition that makes a type always
extensible. It doesn't necessarily imply that a sequence type is never
extensible. I guess the other problem is that I don't understand why a
sequence type can't be extensible. Why does defining the order of the
components prevent extensibility? It seems like that would facilitate
extensibility.
>
> Admitedly, if I had my way with some of the definitions, we could
> have dropped the bit about the BIND attribute and just made this
>
> "A nonsequence derived type is an extensible type."
>
> which would be less verbose, but I lost that one. :-(
>
> By the way, what I lost on was saying that BIND types were a
> special kind of sequence types. They act just like sequence types
> with some extra restrictions and with special interpretation in
> regards to C interop. But since we didn't define them that way,
> lots of places in the standard have to say the same thing about
> sequence types and bind types.
>
> To reorganize the words, but say the same thing as the standard,
> to be an extensible type, it needs to be a derived type and
> not be a sequence (or BIND) type. I.E. most derived types are
> extensible.
>
> I think that Giles once commented that he might start regarding
> SEQUENCE as a way to spell non-extensible, since he objected to
> making so many types extensible by default. (Apologies if I
> misrecalled or misstate his comment).
>
> --
> Richard Maine | Good judgment comes from experience;
> email: my first.last at org.domain | experience comes from bad judgment.
> org: nasa, domain: gov | -- Mark Twain
--
Gary Scott
mailto:garyscott@ev1.net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
Why are there two? God only knows.
Democracy is two wolves and a sheep, voting on what to eat for dinner...
Liberty is a well armed sheep contesting the vote. - Thomas Jefferson
| |
| Richard Maine 2004-07-14, 3:57 am |
| "Gary L. Scott" <garyscott@ev1.net> writes:
>
> Yup, read that. It defines a condition that makes a type always
> extensible. It doesn't necessarily imply that a sequence type is never
> extensible.
That's the definition of extensible type. I think it is bolded. Yes,
sometimes the words of the standard are a bit confusing about whether
something is a definition or just a condition. The bolding is sometimes
the best way to tell this.
> I guess the other problem is that I don't understand why a
> sequence type can't be extensible. Why does defining the order of the
> components prevent extensibility? It seems like that would facilitate
> extensibility.
A sequence type does more that just define the order of the
components. A very critical property of sequence types is that you
can define "the same" type with completely separate type definitions
in different scoping units. So there is not a single unique
definition of a given sequence type - it can be defined in multiple
places. I really don't recall all the details, but I don't think
there is any "place" to store type signature information so that
things like select type work.
Anyway, though I forget he details, the problems have to do with
such things as select type. If a procedure gets passed an object
of an extended type, it is supposed to be able to figure out
which type that was. The implementation details pass me by at
the moment, though I do recall them being discussed, but that's
the general area at issue.
--
Richard Maine
email: my last name at domain
domain: summertriangle dot net
| |
| Jan Vorbrüggen 2004-07-14, 4:00 pm |
| > This means that if you change a type that you weren't aware
> was being extended by other code, you've changed the
> meaning of that other code (possibly without any
> warning to the developer or maintainer of that code).
It's unclear to me how that could actually happen. Being a non-
SEQUENCE type, the base type must be in a module seen by all
users. An extension doesn't touch the basic type itself (I am
assuming...). Could you show the outline of a scenario of where
the effect you dread actually happens?
Jan
| |
| James Giles 2004-07-14, 4:00 pm |
| Jan Vorbrüggen wrote:
>
> It's unclear to me how that could actually happen. Being a non-
> SEQUENCE type, the base type must be in a module seen by all
> users. An extension doesn't touch the basic type itself (I am
> assuming...). Could you show the outline of a scenario of where
> the effect you dread actually happens?
Module A
... contains some type declarations ...
End Module A
Module B ! written by a different programmer
Use A
... contains extentions to the types in A ...
End Module B
How does the author of B necessarily know that the author
of A has changed the type declarations in A. But don't those
changes have consequences on the meaning of B's code?
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| Jan Vorbrüggen 2004-07-16, 3:57 am |
| > Module A
> ... contains some type declarations ...
> End Module A
>
> Module B ! written by a different programmer
> Use A
> ... contains extentions to the types in A ...
> End Module B
>
> How does the author of B necessarily know that the author
> of A has changed the type declarations in A. But don't those
> changes have consequences on the meaning of B's code?
Ah yes, now I see what you meant. But that isn't any different than
when B would be using A's type(s) without extending them, methinks.
The social aspects of concurrent software "engineering" are, of course,
an interesting subject in and of itself...
Jan
| |
| James Giles 2004-07-16, 8:57 am |
| Jan Vorbrüggen wrote:
>
> Ah yes, now I see what you meant. But that isn't any different than
> when B would be using A's type(s) without extending them, methinks.
Well, it is different since the types in A may have type-bound
procedures and such. In addition, there are (apparently) places
where procedure dummy arguments declared to be of some type
in A may actually be associated with actual arguments of an
extended type. The point is that there as a *lot* more ways to
have problems with extension than with mere inclusion as
components.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
|
|
|
|
|