Package's private parts and protected types
in [ADA]
|
From: sjw on 10 Feb 2010 15:17 On Feb 10, 4:05 pm, Adam Beneschan <a...(a)irvine.com> wrote: > And that > issue exists with GNAT also---you delete some files from your > directory with a wildcard, somehow foo.adb accidentally gets deleted > along with them, and the compiler still thinks your program is OK. "that issue *would* exist with GNAT also", I think.
From: Hibou57 (Yannick Duchêne) on 10 Feb 2010 17:21 On 10 fév, 17:09, Robert A Duff <bobd...(a)shell01.TheWorld.com> wrote: > > Remainder of [ARM 6.5(5.2/2)] > > The type of the subtype_indication shall be the result type of the > > function. > > Ah, I see the problem. This is a mistake in the RM, and there's > an AI that fixes it. The real rule is that (in my example) T2 > must be covered by T'Class, which it is. > > Recent versions of GNAT correctly implement this new rule, > but I don't know what version you're using. Ok, I was thinking your way of writing thing was not so silly, but as there was the ARM... My GNAT is GPL 2009 (20090519). I had a look to see if there is an update, but I did not find one (on AdaCore website, its still saying GPL 2009). Do you have a reference for this Ada Issue ? Which number ? About the crash while compiling, I've found a workaround which "solve" it in an acceptable manner, I will open a thread later or tomorrow to tell about it. At the time, I'm facing another trouble, which seems as much strange. Not a crash, but I wonder if either GNAT is wrong of if I did not understood the RM about 9.7.2(3.2/2) and controlling parameters (
From: Robert A Duff on 10 Feb 2010 19:48 "Hibou57 (Yannick Duch�ne)" <yannick_duchene(a)yahoo.fr> writes: > My GNAT is GPL 2009 (20090519). I had a look to see if there is an > update, but I did not find one (on AdaCore website, its still saying > GPL 2009). I don't keep track of what public versions of GNAT are out there, or which fixes are in them, so I can't help you on that. > Do you have a reference for this Ada Issue ? Which number ? AI05-0032-1. There's another AI on this same paragraph, AI05-0103-1, but I don't think it's relevant to this discussion. > About the crash while compiling, I've found a workaround which "solve" > it in an acceptable manner, I will open a thread later or tomorrow to > tell about it. If GNAT crashes, you should report the bug to AdaCore. AdaCore accepts bug reports from the public, and eventually fixes them, but of course at lower priority than bugs reported by paying customers. > At the time, I'm facing another trouble, which seems as much strange. > Not a crash, but I wonder if either GNAT is wrong of if I did not > understood the RM about 9.7.2(3.2/2) and controlling parameters ( Something missing here? - Bob
From: Robert A Duff on 11 Feb 2010 18:46 "Randy Brukardt" <randy(a)rrsoftware.com> writes: > "Robert A Duff" <bobduff(a)shell01.TheWorld.com> wrote in message > news:wccy6j2mpa0.fsf(a)shell01.TheWorld.com... >> AdaMagica <christoph.grein(a)eurocopter.com> writes: >> >>> OK, but then you have a similar problem to Ada83's syntactically >>> unneeded bodies which Ada95 solved with a pragma. >> >> I think that problem is an illusion. There was a problem, >> but it was a problem with implementations, not with the >> language. How do we know if a given package spec has >> a body? Simple: look on the disk and see if there's >> a source file containing that body. In GNAT, that would >> mean looking for foo.adb. > > I think you're forgetting how this happens in practice. And the actual > problem with Ada 83, which was that a unneeded unit with an error had to be > ignored when linking. Well, that's what the Ada 83 RM seemed to require. I thought so at the time. But later I realized that the RM could be interpreted to mean something different -- after all, it doesn't actually talk about "linking". >...(The ACVC used to insist on that.) Yeah. The implementers should have fought against that, rather than damaging their compilers. Or, they could at least have given warnings, which is good enough to solve the problem. Or fix the problem in the "build" command (I mean gnatmake or whatever). >... Ada surely needed a > fix to that problem, and it wasn't one with the implementations -- at least > not until they were changed to match the ACVC. (I remember doing that in > Janus/Ada, it was a lot of work and it made things worse for users. > Wonderful.) > > Moreover, it is easy to imagine errors that would cause the unit to no > longer be the body (such as misspelling the name, or misspelling "body"), at I see your point about misspelling the name. But misspelling "body"? That would just be a syntax error. > which point the implementation would have to guess. But the problem of a > body that the programmer expected to be included being left out would > continue. But the so-called "solution" in Ada 95 didn't actually solve anything. Early versions of GNAT had the same bug -- they ignored a non-required body, simply by saying it's not part of the program library. That was fixed because it's bad behavior, not because it failed to conform to the Ada 95 rules. >...So while I don't doubt that implementations could have reduced the > problem (in the absense of the ACVC test - the main thing I wanted from Ada > 95 was to change the rules enough to repeal that stupid test!), they > couldn't have fixed it completely. Surely the same dynamic would occur for a > separate private part. > > I'm also dubious of the basic idea. I suppose you could keep the private > part in a separate file, but I can't imagine any useful way to *compile* it > separately (you'd have to have both parts available in order to do any sort > of code generation). I don't think you need to look at the private part to generate code. If you change it to "to generate efficient code", then I'll agree. >...So there wouldn't be much, if any, advantage in terms > of development. I disagree -- I think there are big advantages to storing the private part in a separate file. I don't much care what files the compiler wants to look at, so long as it's not too slow. The private part is part of the implementation. It's useful to manage it separately in your CM system (and CM systems are file based). Consider, for example, a visible part that has multiple implementations (maybe target dependent), selected by the build scripts. It's really annoying to have to duplicate the visible part. >... (For Janus/Ada, at least, every source file is compiled > separately, and code is generated as necessary without needing anything > other than direct semantic dependencies to have been previously compiled. > That model is impossible for separate private parts; the specification would > not contain enough information to generate any code or any code for calls to > it.) This seems backwards. Of course you chose a compilation model based on the rules of Ada (Ada 83, in fact). But I'm speculating about what Ada should have been -- a language very similar to Ada, but slightly different. You can't argue against such a language by saying existing Ada compilers can't handle it. If Ada had been designed differently, then so would the compilers have been. Ada allows recursion. Therefore, an Ada implementation must use a stack. I can't say, "I want to statically allocate all variables at link-time-known addresses." Sorry, that's just a wrong implementation of Ada. It's not a valid argument against allowing recursion. - Bob
From: Robert A Duff on 11 Feb 2010 18:53
"Randy Brukardt" <randy(a)rrsoftware.com> writes: >...(For Janus/Ada, at least, every source file is compiled > separately, and code is generated as necessary without needing anything > other than direct semantic dependencies to have been previously compiled. > That model is impossible for separate private parts; the specification would > not contain enough information to generate any code or any code for calls to > it.) The Ada 83 model seemed to be that the compiler doesn't need to look at with'ed bodies to generate code. But that's bogus. All Ada compilers other than Janus/Ada look at bodies to generate code for generic instantiations. And you need to look at bodies to implement inlining properly. (Does Janus/Ada implement inlining?) Similarly for any other inter-package optimizations. Given that compilers do, in fact, look at bodies of with'ed packages, they could use the same mechanism for separate private parts. Or, if private parts didn't exist, to look at bodies to find the completion of private types, for example. - Bob |