From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e977cd3ab4e49fef X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: Question about record rep spec placement Date: 1997/01/17 Message-ID: #1/1 X-Deja-AN: 210529940 references: <32DF9F55.7EA3@lmtas.lmco.com> <5bof0o$q0i@zeus.orl.mmc.com> organization: The World Public Access UNIX, Brookline, MA newsgroups: comp.lang.ada Date: 1997-01-17T00:00:00+00:00 List-Id: In article <5bof0o$q0i@zeus.orl.mmc.com>, Bob Gilbert wrote: >In article <32DF9F55.7EA3@lmtas.lmco.com>, Ken Garlington writes: [stuff about rep clauses in private parts] I agree with the reasons Ken stated for putting rep clauses in private parts. However, because of the freezing rules, it is not always possible to do that. Therefore, my style is to put the rep clause right after the type. This makes various changes less painful -- e.g. suppose you want to add something into the visible part that freezes the type. You'll have to move the rep clause to do that. Besides, a style rule that says "Put this info in the private part when possible, but otherwise put it in the visible part" seems kludgy to me -- knowing that rule, I have no idea what it means that a rep clause is in the visible part. Is it because clients are supposed to take advantage of it? Or is it merely because there happens to be some freezing point of the type, and the programmer couldn't put the rep clause in the private part. This problem existed in Ada 83, too. The freezing rules are slightly more permissive than the forcing occurrence rules of Ada 83, but not to the point where I've changed my mind about where to put rep clauses. IMHO the freezing/forcing rules are a serious flaw in the language. > type T is {whatever}; > for type T use private; -- Tell the user and compiler to look for > -- further specifics about T's representation > -- elsewhere in the package, perhaps even in > -- the package body. What is the point of this idea? Nobody said "Gee, wouldn't it be more readable if we knew a rep clause is coming later?" So it's unclear to me why you would want the above. Are you saying it makes life easier for the compiler? What matters is where the rep clause gets elaborated -- it's of no help to the compiler to know that it's coming, because the compiler can't "look ahead" to the rep clause and get any useful information, because that information might consist of non-static expressions (in a few rep clause cases), and anyway, you can't elaborate a variable declaration (for example) at run time without knowing how to represent the variable. Putting rep clauses in the body is not feasible. If you could do that, you might as well put the full type of a private type in the body, too, and completely eliminate the concept of a private part. This is certainly possible, but leads to a less-efficient run-time model. Or it leads to a different program-library model. It might be a reasonable idea, but it's not Ada. Ada 83 was designed so that the compiler never needs to look at bodies when compiling a client [unless it, ahem, wants to do something useful with pragma Inline], and so that private types can be implemented as efficiently as an equivalent non-private type. Incremental compilation was not considered a requirement. Note the different design decisions made by Eiffel, with respect to specs/bodies/private parts, given that the Eiffel design assumes that all Eiffel compilers will be incremental. - Bob