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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,cb04cee6116c8ced X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!bloom-beacon.mit.edu!newsswitch.lcs.mit.edu!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Package's private parts and protected types Date: Thu, 11 Feb 2010 18:46:23 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <7ff3810f-3ee3-4f39-a54c-933ad7d0655c@36g2000yqu.googlegroups.com> <1v2la97s2yyvd.1rcy0ana8mver.dlg@40tude.net> <3bb38996-47f7-4f30-8255-f011501404b5@b10g2000yqa.googlegroups.com> <1qttzk1jbh24i$.xid2h7me3oec.dlg@40tude.net> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1265931982 16832 192.74.137.71 (11 Feb 2010 23:46:22 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Thu, 11 Feb 2010 23:46:22 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:npsKzc/OxZ462MPGkJyn89L60uI= Xref: g2news1.google.com comp.lang.ada:9130 Date: 2010-02-11T18:46:23-05:00 List-Id: "Randy Brukardt" writes: > "Robert A Duff" wrote in message > news:wccy6j2mpa0.fsf@shell01.TheWorld.com... >> AdaMagica 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