* Re: Package Parts [was: Ada GC and a bunch of other stuff] [not found] <NEWTNews.824443067.649.geneo@medusa.ppp.rational.com> @ 1996-02-18 0:00 ` Ken & Virginia Garlington 1996-02-21 0:00 ` John G. Volan ` (2 more replies) 1996-02-22 0:00 ` John G. Volan 1996-02-23 0:00 ` Robert I. Eachus 2 siblings, 3 replies; 10+ messages in thread From: Ken & Virginia Garlington @ 1996-02-18 0:00 UTC (permalink / raw) Norman H. Cohen <ncohen@watson.ibm.com> wrote: > Here is a half-baked proposal for Ada 0X: Allow a package to consist > of a sequence of compilation units of the form > > "package" name "(" expression "of" expression ")" "is" > { declaration } > [ "private " > { declaration } > [ "begin" > handled_sequence_of_statements ] > "end" name "(" expression "of" expression ")" ";" I missed the post describing the rationale for this proposal; could some one repost it? I have one question which may have already been answered. If you have a package in five parts, as in the original example, would you ever add a sixth part? If so, having to change all the other package names would seem to be counter-productive from a maintenance standpoint. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Package Parts [was: Ada GC and a bunch of other stuff] 1996-02-18 0:00 ` Package Parts [was: Ada GC and a bunch of other stuff] Ken & Virginia Garlington @ 1996-02-21 0:00 ` John G. Volan 1996-02-22 0:00 ` John G. Volan 1996-02-22 0:00 ` John G. Volan 2 siblings, 0 replies; 10+ messages in thread From: John G. Volan @ 1996-02-21 0:00 UTC (permalink / raw) In article <31273ED6.B9B@flash.net> Ken & Virginia Garlington, redhawk@flash.net writes: >Norman H. Cohen <ncohen@watson.ibm.com> wrote: >> Here is a half-baked proposal for Ada 0X: Allow a package to consist >> of a sequence of compilation units of the form >> >> "package" name "(" expression "of" expression ")" "is" >> { declaration } >> [ "private " >> { declaration } >> [ "begin" >> handled_sequence_of_statements ] >> "end" name "(" expression "of" expression ")" ";" > >I missed the post describing the rationale for this proposal; could >some one repost it? In the interest of bandwidth, rather than re-posting, I'll email you the original post (and my follow-up to it). But here's the gist of the rationale, as I see it: Norman Cohen was responding to a post from Henry Baker that was generally bemoaning the "arbitrary restrictions" imposed by Ada's syntax rules. Among other things, Henry voiced a criticism about the arbitrary ordering Ada imposes on declarations in a package spec: All the public declarations have to come first, and all the private declarations come after the keyword "private". There's no way to interleave public and private declarations in a way that's analogous to the "public:" and "private:" clauses in a C++ class declaration. Norman's proposal was in part a response to this criticism. Although his "package-part" syntax retains the ordering rule that puts all the public declarations before all the private declarations, you can still interleave public and private sections of a package by dividing it into several package-parts. However, Norman's proposal also attempted to tackle a couple of other issues: (1) Ada currently doesn't provide the capability to separately compile the public and private parts of a package spec, but it would be quite useful if it did. For one thing, it would reduce recompilation dependencies. From a design point of view, the full completion of a private type within the private part of a package spec represents a portion of the implementation of an abstraction. One's first instinct might be that such implementation details ought to go into the package body. But an Ada compiler needs to be able to get the completion of a type from the package spec, because it needs to be able to implement things like a client declaring an instance of the private type, or deriving a new type from it, etc. But suppose we could separate the public and private parts of a package spec. Then we could at least distinguish "partial" clients that only needed to "with" the public part, from "full" clients that needed to "with" the private part as well. That way, if the implementation of a private type needed to be changed later, only the "full" clients would need to be recompiled. If the public and private parts could be separate compilation units, presumably they could each have context clauses of their own. As it stands now, sometimes a package spec is forced to "with" some program unit that it needs for its private part, but not for its public part. Even though a client sees nothing in the public interface of the package that involves this "with" clause, it nevertheless becomes dependent on that "withed" program unit. This might be unavoidable for "full" clients, but it would be nice if we could avoid this dependency for "partial" clients. Also, if the public and private parts of a package spec could be managed as separate operating-system files, then this would simplify some aspects of the configuration management of packages. For instance, an abstraction might need different implementations when ported to different platforms. The public part of the package spec for this abstraction would be identical for all platforms, but the package body and the private part of the spec would need to be different on each platform. It would be nice if we could leave the file that contained the public part untouched, and just swap in new files for the private part and the body when porting. (2) Ada currently doesn't provide the capability to separately compile an incomplete forward-declaration of a type, but it would be quite useful if it did. This would solve the problem of how to declare two mutually-dependent tagged types in separate packages without running into the "withing" problem -- the chicken-and-egg dilemma of two package specs both trying to "with" each other. I once proposed the notion of a "package-abstract": an optional, separately-compilable part of a package, prior to the package-spec, in which incomplete declarations could be tolerated, on the assumption that their completions would eventually appear in the package-spec. A client could choose whether to "with" the whole package-spec or just the package-abstract. Mutually-dependent package-specs would not need to "with" each other, they could get by with just "withing" each other's package-abstracts. Norman's "package-parts" proposal is a neat generalization of this idea. Any package-part can play the role of one of my "package-abstracts," if it happened to contain an incomplete declaration that wasn't completed until a later package-part. ------------------------------------------------------------------------ Me : Person := (Name => "John G. Volan", E_Mail => "John_Volan@dayton.saic.com", Employer => "Science Applications International Corporation (SAIC)", Affiliation => "Enthusiastic member of Team-Ada!", Favorite_Slogan => "Ada95: The *FIRST* International-Standard OOPL", Shameless_Commercial_Plug => "RADSIM: Low-cost, real-time radar simulation *in Ada* " & "Check out: http://www.dayton.saic.com/aso_homepage.html ", Humorous_Language_Lawyerly_Disclaimer => "These opinions are undefined by my company, so any use of them" & "would be erroneous ... or is that a bounded error now? :-) " ); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Package Parts [was: Ada GC and a bunch of other stuff] 1996-02-18 0:00 ` Package Parts [was: Ada GC and a bunch of other stuff] Ken & Virginia Garlington 1996-02-21 0:00 ` John G. Volan @ 1996-02-22 0:00 ` John G. Volan 1996-02-23 0:00 ` Robert A Duff 1996-02-22 0:00 ` John G. Volan 2 siblings, 1 reply; 10+ messages in thread From: John G. Volan @ 1996-02-22 0:00 UTC (permalink / raw) In article <4gfmli$n0l@dayuc.dayton.saic.com> John G. Volan, John_Volan@ccmail.dayton.saic.com writes: >Also, if the public and private parts of a package spec could be managed >as separate operating-system files, then this would simplify some >aspects of the configuration management of packages. For instance, an >abstraction might need different implementations when ported to >different platforms. The public part of the package spec for this >abstraction would be identical for all platforms, but the package body >and the private part of the spec would need to be different on each >platform. It would be nice if we could leave the file that contained >the public part untouched, and just swap in new files for the private >part and the body when porting. It should be pointed out that the folks at ACT are planning to have GNAT provide something close to this capability, without changing the language. They're going to exploit the fact that the equation 1 Ada compilation unit = 1 operating system file is _NOT_ explicitly required by the language. GNAT will soon allow you to split an Ada package spec into a *.ads file containing everything up to and including the keyword "private" (i.e., the public part of the spec), and a *.adp file containing the rest (i.e., the private part of the spec). However, the two files together will still count as a single compilation unit. In other words, my guess is that GNAT will do little more than some text pre-processing, combining a *.ads with *.adp to generate a single file that is fed to the front end. This in itself will be useful, since it will allow the private part to be treated as a separate item for configuration management purposes. However, there are some desirable features that this will _not_ provide: (1) You won't be able to just "with" the *.ads. A "with" clause means that you're importing the whole compilation unit, including both the contents of the *.ads file and the *.adp file. (2) Unless the ACT folks intend to implement some fancy text-shuffling, a *.adp file will not be able to have its own context clause. If they go with a naive implementation that merely concatenates the *.ads with the *.adp, then the top of the *.ads file will have to contain all the "with" clauses for the package spec, including those that are only needed for the private part (and that presumably would be different for each different version of the *.adp). ------------------------------------------------------------------------ Me : Person := (Name => "John G. Volan", E_Mail => "John_Volan@dayton.saic.com", Employer => "Science Applications International Corporation (SAIC)", Affiliation => "Enthusiastic member of Team-Ada!", Favorite_Slogan => "Ada95: The *FIRST* International-Standard OOPL", Shameless_Commercial_Plug => "RADSIM: Low-cost, real-time radar simulation *in Ada* " & "Check out: http://www.dayton.saic.com/aso_homepage.html ", Humorous_Language_Lawyerly_Disclaimer => "These opinions are undefined by my company, so any use of them" & "would be erroneous ... or is that a bounded error now? :-) " ); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Package Parts [was: Ada GC and a bunch of other stuff] 1996-02-22 0:00 ` John G. Volan @ 1996-02-23 0:00 ` Robert A Duff 0 siblings, 0 replies; 10+ messages in thread From: Robert A Duff @ 1996-02-23 0:00 UTC (permalink / raw) I'll cc this to report@gnat.com, in case they're interested. In article <4gglnj$9r8@dayuc.dayton.saic.com>, John G. Volan <John_Volan@ccmail.dayton.saic.com> wrote: >It should be pointed out that the folks at ACT are planning to have GNAT >provide something close to this capability, without changing the >language. They're going to exploit the fact that the equation > > 1 Ada compilation unit = 1 operating system file > >is _NOT_ explicitly required by the language. Actually, the equation that most Ada 83 compilers followed was "1 Ada compilation = 1 operating system file". Until GNAT came along, everybody seemed to assume this. Although it's not required by the RM, the RM certainly implies that this was the intent, so it's not surprising that everybody did it that way. I'm glad the GNAT folks have recognized that it's possible to be more flexible. (Actually, GNAT is *less* flexible, in that they disallow multiple compilation units per file, but the case we're talking about here, of allowing the private part to be split out, is *more* flexible.) >(2) Unless the ACT folks intend to implement some fancy text-shuffling, >a *.adp file will not be able to have its own context clause. If they >go with a naive implementation that merely concatenates the *.ads with >the *.adp, then the top of the *.ads file will have to contain all the >"with" clauses for the package spec, including those that are only >needed for the private part (and that presumably would be different for >each different version of the *.adp). Yeah, this issue is a bit tricky. It is clearly desirable for the private part to have its own with_clauses. (In fact, I consider the lack of this feature to be a language design flaw.) Now suppose GNAT allows that, and does some fancy text shuffling. That is, they move the with_clauses up to the front. Well, that's certainly allowed by the RM (nobody says you have to store your code in any particular form). But it's undesirable, because it means that the foo.ads file can refer to things that are not mentioned in that file's with_clauses, but only in the corresponding foo.adp file. On the other hand, one might consider making the with_clauses in the foo.adp file just apply to the private part. That seems logical, but it would be an incorrect implementation of Ada, because then if somebody moved the with_clauses up, and concatenated the two files together, in order to feed it to another compiler, it could become illegal. (I don't care about the fact that an illegal package could become legal, but it should be impossible for a legal package to become illegal.) A third possibility would be to say that the with_clauses are moved up by the compiler, and the named packages can cause hiding and ambiguity, but it is illegal to refer to them. It's important that this be a (post-overload resolution) Legality Rule. This seems the most desirable from the user's point of view, but it's no longer a trivial text shuffle. This rule would ensure that any pair of .ads/.adp files can be text-shuffled and fed to another compiler, and it will still be legal. It seems like a correct implementation, in the sense that GNAT would be saying, "You may put some stuff in a .adp file, but if you do, you have to obey an extra rule." The extra rule would of course be wrong, if it were not conditional in that way. Another issue about this feature: The way it was originally described, it sounded like the rule was: If the .ads file ends in "private", without anything after it, then the compiler looks for a .adp file, and concatenates that onto the end. That seems undesirable. Instead, the rule should be: If a .adp file exists, then it is concatenated onto the end. In addition, if the .adp file exists, then the .ads file has to end in "private". This rule is better, because it avoids the problem of silently ignoring the .adp file. (GNAT has a similar bug, in that it silently ignores .adb files in the case where the .ads file does not require a body. ACT knows about that, and I believe they intend to fix it.) - Bob ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Package Parts [was: Ada GC and a bunch of other stuff] 1996-02-18 0:00 ` Package Parts [was: Ada GC and a bunch of other stuff] Ken & Virginia Garlington 1996-02-21 0:00 ` John G. Volan 1996-02-22 0:00 ` John G. Volan @ 1996-02-22 0:00 ` John G. Volan 1996-02-23 0:00 ` Robert A Duff 2 siblings, 1 reply; 10+ messages in thread From: John G. Volan @ 1996-02-22 0:00 UTC (permalink / raw) In article <31273ED6.B9B@flash.net> Ken & Virginia Garlington, redhawk@flash.net writes: >I have one question which may have already been answered. If you >have a package in five parts, as in the original example, would you >ever add a sixth part? If so, having to change all the other package >names would seem to be counter-productive from a maintenance standpoint. IMHO, adding a new part to an existing package would mean that you were making a profound change to the structure of the package. Remember that the parts are supposed to constitute a single extended declarative region with an explicitly prescribed sequence. Inserting a new part at the beginning or middle of this sequence affects all the following parts, but even adding a part onto the end of the sequence might have an affect on the preceding parts. I would not be surprised if this forced you to revisit the other parts for reasons beyond just changing their names. (Actually, it's not their "names" that would change. Rather, it's whatever clauses they each use to indicate the total set of parts they all belong to -- in Norman's syntax, it would be the "of Total" clauses). Indeed, I'd be suspicious if the language allowed you made such a profound change _without_ carefully revisiting the other parts. At the very least, the other parts would need to be recompiled. As an analogy, consider what happens if you, say, add a new procedure declaration into an existing package spec. Ada will force you to revisit the existing body of the package and add the corresponding procedure body. Is being forced to do this "counterproductive"? It does take a certain amount of effort to write that procedure body, but isn't it worth it to keep the spec and body of a package consistent with each other? What would the cost be in maintainability if Ada were more lax about this? (Is it true that you can declare a member function in C++ and then neglect to implement a "body" for it? If so, what's the cost in debugging time to catch this kind of error?) (Contrast this with adding a new child unit into an existing hierarchical library. That change should not affect existing parent and child units any more than introducing an unrelated package would. At worst, a new child unit might try to exploit internal details of its parent in ways that would cause parent code to break when both are linked into the same program, but the mere existence of a new child unit would not, for instance, require the parent unit to be re-compiled.) ------------------------------------------------------------------------ Me : Person := (Name => "John G. Volan", E_Mail => "John_Volan@dayton.saic.com", Employer => "Science Applications International Corporation (SAIC)", Affiliation => "Enthusiastic member of Team-Ada!", Favorite_Slogan => "Ada95: The *FIRST* International-Standard OOPL", Shameless_Commercial_Plug => "RADSIM: Low-cost, real-time radar simulation *in Ada* " & "Check out: http://www.dayton.saic.com/aso_homepage.html ", Humorous_Language_Lawyerly_Disclaimer => "These opinions are undefined by my company, so any use of them" & "would be erroneous ... or is that a bounded error now? :-) " ); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Package Parts [was: Ada GC and a bunch of other stuff] 1996-02-22 0:00 ` John G. Volan @ 1996-02-23 0:00 ` Robert A Duff 0 siblings, 0 replies; 10+ messages in thread From: Robert A Duff @ 1996-02-23 0:00 UTC (permalink / raw) In article <4ggpkg$bl4@dayuc.dayton.saic.com>, John G. Volan <John_Volan@ccmail.dayton.saic.com> wrote: >IMHO, adding a new part to an existing package would mean that you were >making a profound change to the structure of the package. >... >Indeed, I'd be suspicious if the language allowed you >made such a profound change _without_ carefully revisiting the other >parts. Then I guess you're suspicious of child packages, which allow you allow you to add new parts *without* modifying the existing stuff. >... At the very least, the other parts would need to be recompiled. ...and without recompiling the existing stuff. >As an analogy, consider what happens if you, say, add a new procedure >declaration into an existing package spec. Ada will force you to >revisit the existing body of the package and add the corresponding >procedure body. Is being forced to do this "counterproductive"? Yes. This was recognized as a real problem with Ada 83, which is why child packages were invented. (Part of the problem can be solved with incremental compilation, but incremental compilers aren't easy to write.) >... It >does take a certain amount of effort to write that procedure body, but >isn't it worth it to keep the spec and body of a package consistent >with each other? What would the cost be in maintainability if Ada were >more lax about this? (Is it true that you can declare a member >function in C++ and then neglect to implement a "body" for it? If so, >what's the cost in debugging time to catch this kind of error?) No, I believe that in C++ you will get an error at link time if you do that. (In Ada, you will get an error at link time if the entire package body is missing.) >(Contrast this with adding a new child unit into an existing hierarchical >library. That change should not affect existing parent and child units >any more than introducing an unrelated package would. At worst, a new >child unit might try to exploit internal details of its parent in ways >that would cause parent code to break when both are linked into the >same program, but the mere existence of a new child unit would not, for >instance, require the parent unit to be re-compiled.) OK, now I'm confused. I don't see the "contrast". You're building a subsystem out of multiple pieces. In one case, you're horrified at the idea of adding a new piece without having to modify existing pieces, and in the other case (child packages), you're perfectly happy with that. It seems to me that in *either* case, when you add a new piece, you *might* want to modify existing pieces, and you might not. I don't see how a language rule requiring you to make a particular modification is going to help you recognize the logically necessary modifications -- it's just going to cost extra compile time. You can break things by adding a procedure to a package, but only if you add some code that calls the new procedure. And you can break things by adding a child (your "at worst...") above, but only if you add some code that references the new stuff. I don't see any contrast, and I don't see any need for language rules to get in the way of making changes. - Bob ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Package Parts [was: Ada GC and a bunch of other stuff] [not found] <NEWTNews.824443067.649.geneo@medusa.ppp.rational.com> 1996-02-18 0:00 ` Package Parts [was: Ada GC and a bunch of other stuff] Ken & Virginia Garlington @ 1996-02-22 0:00 ` John G. Volan 1996-02-22 0:00 ` John G. Volan 1996-02-23 0:00 ` Robert A Duff 1996-02-23 0:00 ` Robert I. Eachus 2 siblings, 2 replies; 10+ messages in thread From: John G. Volan @ 1996-02-22 0:00 UTC (permalink / raw) In article <NEWTNews.824443067.649.geneo@medusa.ppp.rational.com>, Gene Ouye <geneo@rational.com> wrote: >:John Volan <volan@BABYLON.DAYTON.SAIC.COM> wrote: >:> (6) Here's a purely notational issue: Personally, I dislike the notion >:> of identifying a package-part by a number. Part-numbers wouldn't convey >:> any idea of the purpose that a programmer had in mind for each >:> package-part. I think using some kind of identifier would be a lot >:> better, in terms of readability, self-documentation, etc. >: >:Actually, it's relatively simple to convey the purpose of each part of >:the package. Norm's proposal doesn't say the part numbers have to be >:numeric literals, it says they're static universal integer expressions >:(something I've seen too much of in another thread :-). Assuming that >:context clauses go in the same place that they do in Ada 95, all you >:need to do is create a program configuration package (not to be confused >:with a configuration pragma, although they may be applicable ;-). In >:the configuration package, you can define named numbers that will convey >:both the purpose of the package part and the sequencing of the parts. >: >:> Of course, one of the things that Norman's syntax achieves is that it >:> imposes a definite sequential order on the parts of a package. >:> Furthermore, each package-part declares not only its own numeric >:> position, but also the total number of package-parts in the sequence. >:> (Presumably, all the package-parts would have to agree on this total.) >:> Thus, within any package-part, it's always possible to know how many parts >:> precede it and how many follow it. >: >:If you use named numbers for the part numbers, a cursory examination of >:the package part source file wouldn't necessarily show how many parts >:precede or follow the part. You'd have to look in the configuration >:package. That would make it a little more difficult to find out how many >:parts there were, but it would make it simple to change the number of >:parts. Of course, at compile time the package part will know how many >:parts could potentially precede and/or follow it (it couldn't know for >:sure unless there is some kind of requirement that there must be a part >:corresponding to each number in the part number range). Yes, I was assuming that there would be a consistency rule that said that there would actually have to be a compilation unit in the library for every part-name in the indicated set of part-names (whether that set is implied by a total count as in Norman's syntax, or explicitly enumerated as in my proposal). >:This would also >:make it easier to reorder the parts, although I would expect that to be >:infrequent due to problems with the arbitrary rearranging of the >:declarative region. However, if there were some problems, they would be >:found at compile time. >: >:> To achieve the same affects with identifiers instead of numbers, we'd >:> need to be able to enumerate the identifiers of all the parts of a >:> package somehow. The order in which the identifiers appeared in this >:> enumeration would determine the sequential order of the package-parts. >:> The position of a package-part's identifier within the enumeration >:> would determine the package-part's position within the sequence. >: >:I think named numbers achieves this, see the example. >: >: >: package My_Part_IDs is >: GUI : constant := 1; >: Business_Logic : constant := GUI + 1; >: DBMS : constant := Business_Logic + 1; >: >: Total_Parts : constant := DBMS; >: end My_Part_IDs; >: >: with My_Part_IDs; use My_Part_IDs; >: package My_Package (Business_Logic of Total_Parts) is >: ... >: end My_Package; For that matter, if we accept this notion of declaring the part-names in a prior configuration package, then there's no particular reason why the part names need to be named numbers. I have suggested that the part-names could be "enumerated" somehow. Although I didn't necessarily mean for this "enumeration" to be an enumerated _type_ per se, this configuration package idea would in fact allow us to use an actual enumerated type for the set of part names. Let's try out a hybrid of the syntax from Norman Cohen's proposal and the syntax from my counter-proposal, combine it with this notion of a configuration package, and see what we get: package Stack_Configuration is type Parts is (Interface, Completion); end Stack_Configuration; with Stack_Configuration; use Stack_Configuration; package Stack (Interface in Parts) is ... end Stack (Interface in Parts); with Stack_Configuration; use Stack_Configuration; package Stack (Completion in Parts) is ... end Stack (Completion in Parts); package body Stack is ... end Stack; Like Norman's proposal, a part-id is placed in parentheses along with an indication of the total set of part-ids from which it is taken. But here the part-id is an enumeration literal and the set of part-ids is indicated by the name of a previously-declared enumerated _type_. (Thus the use of the keyword "in" conveying a sense of membership in a set, rather than the keyword "of".) (Also, as in my counter-proposal, only the package spec is split into parts; the package body keeps its distinct syntax as in Ada 95.) However, regardless of whether the part-names are enumeration literals or named numbers, there's something a bit unsatisfying about having to declare a separate configuration package first just to house the part-names, before you can actually declare the target package in its various parts. I think it would be better if a package could remain an autonomous, self-contained entity, regardless of whether it happens to be decomposed into multiple parts or not. What happens at the client level? Before a client can "with" a specific package part, it seems that it would also have to "with" (and "use") the configuration package: with Stack_Configuration; use Stack_Configuration; with Stack (Interface in Parts); package Partial_Client is ... Again, there's something unsatisfying about having to bring in this configuration package before you can even mention the package-part you want to "with". >:Of course, you could also make the configuration package be the >:parent of the parts, and define the part IDs there. That might help alleviate some of the awkwardness, but I'd still prefer it if a package-with-parts could be as "idempotent" as any other package. That's why I'd favor some kind of special syntax that would allow a package to enumerate its parts, rather than using some kind of conventional Ada declaration (like an enumerated type) that requires a prior declarative region to be declared in. With regard to possibly needing to re-order the package parts: I think using an enumeration would actually be easier than a series of named numbers. All you'd have to do would be to change the order of the enumeration literals in the type declaration, whereas in a cascade of named numbers declarations not only do you have to change the order of the declarations, but you also have to make sure that each one is actually incremented from its new predecessor -- that might be quite error-prone. Another reason for favoring enumerations over named numbers is the impact part names would have on Ada library management. If package parts were identified in the library by part-numbers, then re-arranging the parts would force you to move all the parts to different part-numbers. (In terms of GNAT's source-file-based library management scheme, the first package part would have to go in, say, a file called *.ad1, the second in file *.ad2, and so forth, regardless of the names we happen associate with those numbers; changing the order would require moving the files to different names.) On the other hand, if package parts were stored in the library under part-names that were true identifier literals, presumably those literals wouldn't have to change if we re-ordered the parts. The only thing that would change would be the positional order the compiler associated with each literal. (In GNAT terms, we could, for instance, keep parts A and B of package P in files named, let's say, "p=a.ads" and "p=b.ads". If we happened to switch the order of the parts so that B came before A, we'd need to edit the enumeration declaration, but we wouldn't need to rename the files.) ------------------------------------------------------------------------ Me : Person := (Name => "John G. Volan", E_Mail => "John_Volan@dayton.saic.com", Employer => "Science Applications International Corporation (SAIC)", Affiliation => "Enthusiastic member of Team-Ada!", Favorite_Slogan => "Ada95: The *FIRST* International-Standard OOPL", Shameless_Commercial_Plug => "RADSIM: Low-cost, real-time radar simulation *in Ada* " & "Check out: http://www.dayton.saic.com/aso_homepage.html ", Humorous_Language_Lawyerly_Disclaimer => "These opinions are undefined by my company, so any use of them" & "would be erroneous ... or is that a bounded error now? :-) " ); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Package Parts [was: Ada GC and a bunch of other stuff] 1996-02-22 0:00 ` John G. Volan @ 1996-02-22 0:00 ` John G. Volan 1996-02-23 0:00 ` Robert A Duff 1 sibling, 0 replies; 10+ messages in thread From: John G. Volan @ 1996-02-22 0:00 UTC (permalink / raw) In article <4gh2da$ffb@dayuc.dayton.saic.com> John G. Volan, John_Volan@ccmail.dayton.saic.com writes: >...I'd still prefer >it if a package-with-parts could be as "idempotent" as any other >package. That's why I'd favor some kind of special syntax that would >allow a package to enumerate its parts, rather than using some kind of >conventional Ada declaration (like an enumerated type) that requires a >prior declarative region to be declared in. How about this 7/8-baked counter-counter-proposal for Ada 0X? :-) Introduce a new kind of compilation unit called (let's say) a "package-spec configuration unit", with the following syntax perhaps: package <name> separate ( <identifier> {, <identifier> } ); For instance, here's the configuration unit for the Stack package example: package Stack separate (Interface, Completion); This unit provides one handy place where all the package-spec-parts can be enumerated. Each individual package-spec-part implicitly imports this unit, and does not need to repeat the enumeration. Then we could have the following syntax for a package-spec-part: package <name> ( <identifier> ) is { <basic-declaration> ; } private { <basic-declaration> ; } end <name> ( <identifier> ); For example, the parts of the Stack package-spec would be: package Stack (Interface) is type Object is ... private; ... end Stack (Interface); package Stack (Completion) is private type Object is ... [full type declaration]; ... end Stack (Completion); If a compiler saw this <name>(<identifier>) syntax, it would know that it was dealing with a package-spec-part, so it would look for the package-spec configuration unit in the library. That would enable it to determine the part's position in the sequence of parts, as well as the prior parts implicitly "withed" into that part. For backwards compatibility with Ada 95, we'd still support the existing syntax of single-part package specs, but this syntax would be mutually-exclusive with the multi-part syntax -- either you have a simple package spec, or you have one of those configuration units and the corresponding package-spec-parts. We'd also have the following alternative syntax for a "with" clause: with <name> ( <identifier> ); For example, a "partial" client of Stack could be: with Stack (Interface); package Partial_Client is ... and a "full" client could be: with Stack (Completion); package Full_Client is ... but given that Completion was the last part in the sequence, this would be considered equivalent to: with Stack; package Full_Client is ... A GNAT-like compiler could use a source-file naming convention something like the following: - p.ads would either contain a conventional single-part package-spec for package P, or it would contain a package-spec configuration unit for package P. - In the latter case, for every part-name X enumerated in p.ads, there should be a file p,x.ads containing package-spec-part P(X). (Note: I'm using "," to separate the part name vs. GNAT's "-" for child units. Various UNIXes I've tried seem to accept this, but I don't know whether other OS's (DOS, etc.) will like it.) - When a client says "with P;", the compiler will look for p.ads. If it finds an ordinary package spec there, it procedes as usual. But if it finds a package-spec configuration unit instead, the compiler will procede to "with" the whole sequence of p,x.ads package-spec-parts. - When a client says "with P(X);", the compiler will look for p,x.ads. It will also get file p.ads so it can determine P(X)'s position in the part sequence; it then will get the appropriate files for all the parts prior to P(X). ------------------------------------------------------------------------ Me : Person := (Name => "John G. Volan", E_Mail => "John_Volan@dayton.saic.com", Employer => "Science Applications International Corporation (SAIC)", Affiliation => "Enthusiastic member of Team-Ada!", Favorite_Slogan => "Ada95: The *FIRST* International-Standard OOPL", Shameless_Commercial_Plug => "RADSIM: Low-cost, real-time radar simulation *in Ada* " & "Check out: http://www.dayton.saic.com/aso_homepage.html ", Humorous_Language_Lawyerly_Disclaimer => "These opinions are undefined by my company, so any use of them" & "would be erroneous ... or is that a bounded error now? :-) " ); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Package Parts [was: Ada GC and a bunch of other stuff] 1996-02-22 0:00 ` John G. Volan 1996-02-22 0:00 ` John G. Volan @ 1996-02-23 0:00 ` Robert A Duff 1 sibling, 0 replies; 10+ messages in thread From: Robert A Duff @ 1996-02-23 0:00 UTC (permalink / raw) In article <4gh2da$ffb@dayuc.dayton.saic.com>, John G. Volan <John_Volan@ccmail.dayton.saic.com> wrote: >For that matter, if we accept this notion of declaring the part-names in >a prior configuration package, then there's no particular reason why >the part names need to be named numbers. I have suggested that the >part-names could be "enumerated" somehow. You're getting closer and closer to child packages. It seems to me that if you want to think about this, you should start out with child packages, and enumerate the things they can't do, or can't do well enough for your taste (such as the mutually recursive types thing), and think about how to modify the semantics of child packages to fix those problems. Inventing a whole new feature seems like overkill. - Bob ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Package Parts [was: Ada GC and a bunch of other stuff] [not found] <NEWTNews.824443067.649.geneo@medusa.ppp.rational.com> 1996-02-18 0:00 ` Package Parts [was: Ada GC and a bunch of other stuff] Ken & Virginia Garlington 1996-02-22 0:00 ` John G. Volan @ 1996-02-23 0:00 ` Robert I. Eachus 2 siblings, 0 replies; 10+ messages in thread From: Robert I. Eachus @ 1996-02-23 0:00 UTC (permalink / raw) In article <4gh2da$ffb@dayuc.dayton.saic.com> John G. Volan <John_Volan@ccmail.dayton.saic.com> writes: > However, regardless of whether the part-names are enumeration literals > or named numbers, there's something a bit unsatisfying about having to > declare a separate configuration package first just to house the > part-names, before you can actually declare the target package in its > various parts. I think it would be better if a package could remain an > autonomous, self-contained entity, regardless of whether it happens to > be decomposed into multiple parts or not. How about: package Stack(Interface, Extended_Interface, Completion); package Stack(Interface) is... end Stack(Interface); package Stack(Extended_Interface) is... end Stack(Extended_Interface); etc. (Lots of other good ideas that work well with this approach deleted.) In the GNAT library model, the one line declaration of the parts would have to be in a separate file with a new extension, .adp?, but other than that no problem. Or you could make the part enumeration a header for the first package part: parts(Interface, Extended_Interface, Completion); package Stack(Interface) is... end Stack(Interface); Making each part list all of the partitions is the third approach: package Stack(Interface of Interface, Extended_Interface, Completion) is end Stack(Interface); But this could lead to more hassle in maintenance. Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~1996-02-23 0:00 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <NEWTNews.824443067.649.geneo@medusa.ppp.rational.com> 1996-02-18 0:00 ` Package Parts [was: Ada GC and a bunch of other stuff] Ken & Virginia Garlington 1996-02-21 0:00 ` John G. Volan 1996-02-22 0:00 ` John G. Volan 1996-02-23 0:00 ` Robert A Duff 1996-02-22 0:00 ` John G. Volan 1996-02-23 0:00 ` Robert A Duff 1996-02-22 0:00 ` John G. Volan 1996-02-22 0:00 ` John G. Volan 1996-02-23 0:00 ` Robert A Duff 1996-02-23 0:00 ` Robert I. Eachus
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox