J. Overbey, Matthew J. Fotzler, Ashley J. Kasza, Ralph E. Johnson
{"title":"fortran 95重构规范的集合","authors":"J. Overbey, Matthew J. Fotzler, Ashley J. Kasza, Ralph E. Johnson","doi":"10.1145/1883575.1883577","DOIUrl":null,"url":null,"abstract":"This article contains detailed specifications of several automated refactorings for Fortran 95. These have been used to implement refactorings in Photran [1], an integrated development environment and refactoring tool based on Eclipse. Our purpose in publishing these specifications is twofold. First, we would like to encourage other Fortran tool vendors to consider adding refactoring support to their own IDEs; we hope that making our detailed specifications publicly available will allow others to benefit from our experience. Indeed, many details of the refactorings are quite subtle. Second, we are interested in receiving feedback on both the form and content of these specifications. Although they been carefully constructed and used as a basis for implementation, some errors, oversights, and ambiguities are inevitable. The first author will post errata, clarifications, and links to updated versions of this document at [2]. To the extent possible, we have attempted to use the same terminology as the Fortran 95 ISO standard [3], and we have attempted to describe the mechanics of the refactorings syntactically (i.e., in terms of the standard grammar). For example, we define an External Subprogram to be a 〈 function-subprogram〉 or a 〈subroutine-subprogram〉 in the context of an 〈external-subprogram〉. Such 〈bracketed-names〉 correspond to nonterminal symbols in the ISO grammar. Section numbers (e.g., §14.1.1) and rule numbers (e.g., R201) are also references to the ISO standard. All algorithms are described imperatively, as a sequence of steps that may be executed to test the precondition or perform the transformation. It is not always essential that an implementation execute these steps in the order listed; in many cases, the steps can be reordered and still produce the same results. For example, many precondition checks require a number of conditions to be checked, but these conditions are mutually disjoint, and therefore the order in which they are checked is inconsequential.","PeriodicalId":379614,"journal":{"name":"ACM SIGPLAN Fortran Forum","volume":"336 1","pages":"0"},"PeriodicalIF":0.0000,"publicationDate":"2010-11-12","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"15","resultStr":"{\"title\":\"A collection of refactoring specifications for fortran 95\",\"authors\":\"J. Overbey, Matthew J. Fotzler, Ashley J. Kasza, Ralph E. Johnson\",\"doi\":\"10.1145/1883575.1883577\",\"DOIUrl\":null,\"url\":null,\"abstract\":\"This article contains detailed specifications of several automated refactorings for Fortran 95. These have been used to implement refactorings in Photran [1], an integrated development environment and refactoring tool based on Eclipse. Our purpose in publishing these specifications is twofold. First, we would like to encourage other Fortran tool vendors to consider adding refactoring support to their own IDEs; we hope that making our detailed specifications publicly available will allow others to benefit from our experience. Indeed, many details of the refactorings are quite subtle. Second, we are interested in receiving feedback on both the form and content of these specifications. Although they been carefully constructed and used as a basis for implementation, some errors, oversights, and ambiguities are inevitable. The first author will post errata, clarifications, and links to updated versions of this document at [2]. To the extent possible, we have attempted to use the same terminology as the Fortran 95 ISO standard [3], and we have attempted to describe the mechanics of the refactorings syntactically (i.e., in terms of the standard grammar). For example, we define an External Subprogram to be a 〈 function-subprogram〉 or a 〈subroutine-subprogram〉 in the context of an 〈external-subprogram〉. Such 〈bracketed-names〉 correspond to nonterminal symbols in the ISO grammar. Section numbers (e.g., §14.1.1) and rule numbers (e.g., R201) are also references to the ISO standard. All algorithms are described imperatively, as a sequence of steps that may be executed to test the precondition or perform the transformation. It is not always essential that an implementation execute these steps in the order listed; in many cases, the steps can be reordered and still produce the same results. For example, many precondition checks require a number of conditions to be checked, but these conditions are mutually disjoint, and therefore the order in which they are checked is inconsequential.\",\"PeriodicalId\":379614,\"journal\":{\"name\":\"ACM SIGPLAN Fortran Forum\",\"volume\":\"336 1\",\"pages\":\"0\"},\"PeriodicalIF\":0.0000,\"publicationDate\":\"2010-11-12\",\"publicationTypes\":\"Journal Article\",\"fieldsOfStudy\":null,\"isOpenAccess\":false,\"openAccessPdf\":\"\",\"citationCount\":\"15\",\"resultStr\":null,\"platform\":\"Semanticscholar\",\"paperid\":null,\"PeriodicalName\":\"ACM SIGPLAN Fortran Forum\",\"FirstCategoryId\":\"1085\",\"ListUrlMain\":\"https://doi.org/10.1145/1883575.1883577\",\"RegionNum\":0,\"RegionCategory\":null,\"ArticlePicture\":[],\"TitleCN\":null,\"AbstractTextCN\":null,\"PMCID\":null,\"EPubDate\":\"\",\"PubModel\":\"\",\"JCR\":\"\",\"JCRName\":\"\",\"Score\":null,\"Total\":0}","platform":"Semanticscholar","paperid":null,"PeriodicalName":"ACM SIGPLAN Fortran Forum","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1145/1883575.1883577","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
A collection of refactoring specifications for fortran 95
This article contains detailed specifications of several automated refactorings for Fortran 95. These have been used to implement refactorings in Photran [1], an integrated development environment and refactoring tool based on Eclipse. Our purpose in publishing these specifications is twofold. First, we would like to encourage other Fortran tool vendors to consider adding refactoring support to their own IDEs; we hope that making our detailed specifications publicly available will allow others to benefit from our experience. Indeed, many details of the refactorings are quite subtle. Second, we are interested in receiving feedback on both the form and content of these specifications. Although they been carefully constructed and used as a basis for implementation, some errors, oversights, and ambiguities are inevitable. The first author will post errata, clarifications, and links to updated versions of this document at [2]. To the extent possible, we have attempted to use the same terminology as the Fortran 95 ISO standard [3], and we have attempted to describe the mechanics of the refactorings syntactically (i.e., in terms of the standard grammar). For example, we define an External Subprogram to be a 〈 function-subprogram〉 or a 〈subroutine-subprogram〉 in the context of an 〈external-subprogram〉. Such 〈bracketed-names〉 correspond to nonterminal symbols in the ISO grammar. Section numbers (e.g., §14.1.1) and rule numbers (e.g., R201) are also references to the ISO standard. All algorithms are described imperatively, as a sequence of steps that may be executed to test the precondition or perform the transformation. It is not always essential that an implementation execute these steps in the order listed; in many cases, the steps can be reordered and still produce the same results. For example, many precondition checks require a number of conditions to be checked, but these conditions are mutually disjoint, and therefore the order in which they are checked is inconsequential.