-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use ABSTRACT keyword to indicate an abstract deferred type, in order to resolve issues with the distinction of deferred-type vs deferred-class #120
Conversation
…to resolve issues with the distinction of deferred-type vs deferred-class
Extend C703 from: | ||
(R702) The <derived-type-spec> shall not specify an abstract | ||
type (7.5.7) | ||
To: | ||
(R702) The <derived-type-spec> or <deferred-type> shall not specify | ||
an abstract type (7.5.7) except when used as an <instantiation-arg>. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I put this back because I realized why it's necessary for this edit.
The "except when used as an <instantiation-arg>" is not directly relevant to this edit, but is important, so I gave it its own PR: #127
But indicating that <deferred-type> must not be abstract is important because it solves the issue @everythingfunctional was talking about: it prevents you from using an abstract deferred-type in a TYPE IS statement.
Add constraint, or amend C1166 to include: | ||
(R1156) <deferred-type> shall specify an extensible type. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that "extensible type" here is a generalization of "abstract type" and allows us to expand to something like TYPE, EXTENSIBLE :: T
in the future without needing to change this constraint. Abstract should imply extensible.
I'm coming around to @aury6623 's proposal here. I think we should go ahead and include |
Addressed by #131 |
There are inconsistencies with the usage of "deferred type"/<deferred-type> and "deferred class"/<deferred-class>
generics/J3-Papers/syntax-intro-and-deferred-args.txt
Lines 112 to 114 in cc42f87
generics/J3-Papers/syntax-intro-and-deferred-args.txt
Lines 318 to 319 in cc42f87
generics/J3-Papers/syntax-intro-and-deferred-args.txt
Lines 437 to 449 in cc42f87
In the third of those 3 snippets, we assume that "deferred type" and "deferred class" are mutually exclusive categories. However, in the first snippet, as well as the section headers in the document, we refer to both things together as "deferred type". We also say "can appear in a <type-spec>" in the first snippet, which is not true of deferred class. We also group them in the BNF, such as "<deferred-type-declaration-stmt>" which is either TYPE, DEFERRED or CLASS, DEFERRED. We need to be more precise with the terms here.
In the existing standard, "class" is not a term used to describe a type, and it's not really even a word used to describe a data object. I think the closest it gets to that is the "CLASS IS" syntax in a <type-guard-stmt>. CLASS is only a type specifier which declares polymorphic data objects. I think our problem might be the use of the word "class" at all to describe the concept we want; when I see CLASS in Fortran, I think "declaration of an object", not "definition of a type".
The
TYPE, DEFERRED :: type-name
declaration is supposed to be analogous to theTYPE :: type-name
construct, right? So I think it would be more clear to useTYPE, ABSTRACT, DEFERRED :: type-name
as the declaration, analogous toTYPE, ABSTRACT :: type-name
.With that notion, this PR is my proposal to address the inconsistencies between <deferred-type> and <deferred-class>.
If the
TYPE, ABSTRACT, DEFERRED :: type-name
syntax is not preferred, we could still revert back to theCLASS, DEFERRED :: type-name
syntax and keep everything else in this edit the same, except the normative text would change to: