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!news4.google.com!proxad.net!feeder1-2.proxad.net!feeder.erje.net!nuzba.szn.dk!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Package's private parts and protected types Date: Thu, 11 Feb 2010 19:29:48 -0600 Organization: Jacob Sparre Andersen 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: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1265938189 14961 69.95.181.76 (12 Feb 2010 01:29:49 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 12 Feb 2010 01:29:49 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5843 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Xref: g2news1.google.com comp.lang.ada:9143 Date: 2010-02-11T19:29:48-06:00 List-Id: "Robert A Duff" wrote in message news:wccvde3gwts.fsf@shell01.TheWorld.com... > "Randy Brukardt" writes: ... >> 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. I often leave out "body" altogether. But either are a syntax error, but only if the build system tries to compile the file! And why is it doing that, build systems don't compile random files that aren't needed. I could imagine a warning if you have strong links (naming conventions, whatever) to this particular file, but that is often not the case. (It wasn't in Janus/Ada until we added the project manager in the mid-90's - if the file didn't have the right name or the right contents, it was ignored. We didn't want to be picking up random documents and leftover debugger files, which used to happen in the old days.) >> 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. I don't see how you could "fix" it in general. If the file matches the naming conventions or already has a link from a project manager, sure you can see it. But if those things aren't true, are you going to nag the user everytime? (No body found for package X!) We actually did that for a while in late Ada 83 days and it drove everybody nuts. ... >> 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. I don't know how to compile a subprogram call if I don't know the parameter passing kind (by-copy or by-reference). You could make everything by-reference, but then you have to fake by-copy at the call site. Not sure how you could do that if you don't know anything about the type. It's the reason you can't make calls to subprograms with parameters of incomplete types. (We recently discovered that Ada has been wrong about disallowing the *declaration* of such subprograms; the only problem is *calling* them; Ada 2012 will relax that restriction, which will be great for "limited with".) >>...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. Maybe. It sounds like more separate windows to juggle in the editor. > 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. CM systems have been a pet peeve of mind for years. File-based management simply doesn't work; unfortunately, everything else is too complex to use. Janus/Ada plenty of files that are mostly shared (like the definition of Standard for different targets), and it is pain to keep them all consistent. I built a front-end to our CM system to track those relationships, but it doesn't work that well because of the need to manually update things, even when the change is in the shared part (which is the usual case). There is no particular part of the code that is more or less common for these "unshared" parts to occur. Bodies, private declarations, and visible constants all are involved. So you're fixing one corner of a wide tools problem with a language feature. If you really wanted to fix that (without creating a new kind of CM system!), I think you would need to support putting arbitrary parts of compilation units in different files. Almost like the old include files, but with first class support in the programming environment so it is easy to see and work on the assembled result. But that isn't a language enhancement per-se. >>... (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. We're talking about Ada here (and possibly enhancements to Ada). I'm not talking about the Duff language, nor am I very interested in it. Ada is going to be compiled by Ada compilers, and the vast majority of them already exist. How they work *is* relevant. Randy.