Re: Package's private parts and protected types

["Randy Brukardt" <randy@rrsoftware.com>]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccvde3gwts.fsf@shell01.TheWorld.com...
> "Randy Brukardt" <randy@rrsoftware.com> 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.