Re: Separate Compilation in Programming Languages

[Robert A Duff <bobduff@shell01.TheWorld.com>]

<adaworks@sbcglobal.net> writes:

> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
> news:wcc63wfpus7.fsf@shell01.TheWorld.com...
>> <adaworks@sbcglobal.net> writes:
>>
>>> My concern is dependency management.
>>
>> OK, but I still don't fully understand what you're getting at.
>> You said elsewhere in this thread that you are NOT concerned with
>> recompilation costs.  That's good -- recompilation cost should
>> primarily be an implementation concern.
>>
> Sometimes recompilation costs are important.

Yes, of course.  If the implementation can't recompile my entire program
in less than 0.2 second, then it's too slow.  Here, "too slow" means I
wish it would be faster.  ;-)  But recompilation speed is primarily
an implementation issue, although the language design can facilitate
fast compilers.

>...This is true for very
> large software systems where one does not want to recompile the
> entire system for one change somewhere way down in a function
> within one package body.

Sure, but a well-designed incremental compilation facility is strictly
better than the usual Ada way of doing this.

>> I'm guessing that your point has nothing to do with "compilation" at
>> all, separate or otherwise.  It has to do with the organization of the
>> program into separate source files -- specifically separation of spec
>> and body (interface and implementation, to use more language-neutral
>> terms).  Right?
>>
> Right.  My primary concern, in this discussion,is with dependency management.
>
>>
>> OK, so you like having textually separate spec and body,
>> as do I.  But what specific advantages are you talking
>> about in this thread?
>>
>> Readability?  That is, when looking at a client of A, you don't
>> need to worry about X,Y,...S.  This is good, but it's got little to do
>> with separate compilation.
>>
> In my view, it does.  The less code I have to look at to make a
> change or to understand the code, the better.  Granted, this does
> not always work as well as I might like, but it frequently is of
> value.

I don't understand the above paragraph.  You claim it DOES have to do
with compilation, but then you talk about how much code you (a human)
have to look at, which has nothing whatsoever to do with compilation.

>> Source modification?  A change in X could introduce a bug
>> into a client of A -- so there really _is_ a dependency
>> in that sense.
>>
> However, the dependency is at the iimplementation level, not at
> the specification level.
>
>> One advantage of Ada over some languages (e.g. C) is that the
>> implementation can know what source files are part of each program,
>> by following the with clauses.  I really hate having to write a make
>> file that lists out all the .o files that need to be linked together --
>> Ada allows that to be completely automated (that's what gnatmake does).
>>
> Well, Yes.   If, in one of my separately compiled subprograms within a
> package body Q, uses a depth-search routine from a parent package
> specification K, and we decide to use the breadth-search instead, there
> is no need to alter any part of the package specification of Q.  It remains
> stable.
>
> This becomes an architectural issue, as well.   The more stable my
> architecture when a change is made to some element of that architecture,
> the better for my overall design.
>
>> Something else?
>>
>> Note that Ada requires some implementation details to appear in the
>> package spec -- namely, the stuff that goes in the private part, plus
>> the with clauses needed by that private part.  That's ugly, IMHO.
>>
> Modula-2 solved that problem through the use of opaque types. I
> often code opaque types in Ada using access types.   This eliminates
> any dependencies at the specification level, in many cases.

Right, but there's a huge disadvantage of Modula-2's opaque types, and
the Ada equivalent using access types: namely, you now have to deal
with heap management.

>...As you
> know, the private part of a package was a compromise that allows
> separate compilation.

A completely unnecessary compromise.  This particular area of Ada
(private parts) really is a mess, IMHO.

> We can even create a tagged type as an opaque type, thereby hiding
> any implementation details and still making that type extensible.  This
> was difficult in Modula-2, so the designers of Modula-3 also had to
> make some compromises.   Engineering is always about trade-offs
> between conflicting solutions.

Not always.  Sometimes there's a way that's uniformly better
than the alternatives.

>...Java certainly has its share of trade-offs.
>>
>> Shrug.  I don't use "is separate" much.  Child packages are almost
>> always better, because you can separate the spec _and_ the body,
>> and because the parent need not know about the child.  Child packages
>> provide the same advantage of being able to "push down" the
>> dependencies.
>>
> I did not mention Child packages, but you are certainly correct that they
> are a powerful contributing solution to this issue.   In particular, private
> children are a great benefit.   However, in very large software systems,
> a million SLOC or more, "is separate" continues to play an important
> role.

I don't see why the size of the software has anything to do with
subunits vs. child units.  Subunits are occassionally useful,
but child units are usually better (for large systems and small),
and are never much worse.  You can always change code that uses
subunits to use child units instead, in a way that avoids changing
any clients, at the cost of some annoying verbosity.

>...As noted earlier, specifications should be an architectural concern,
> and the more stable an architecture, the better.   Implementation should
> be dependent on architecture, not the other way around.
>
> When I want to change the upholstery in my car, I don't want to have to
> alter the architecture of that car.   I don't want the performance of the car
> to depend on whether I choose Zebra seat covers or chartreuse trim
> on green Naugahyde.
>
>>> I don't think this is possible in Java, Eiffel, or C#.
>>
>> It's possible using interfaces.  Clients of an interface do not depend
>> on classes that implement the interface, any more than clients of an Ada
>> package spec depend on its body.  You suggested otherwise elsewhere in
>> this thread, but I think you're wrong, or else I'm misunderstanding what
>> you mean by "depend".
>>
>> Interfaces are more flexible than spec/body in that they allow multiple
>> "bodies".  And of course Ada 2005 has interfaces.  Note that an
>> interface will typically be declared in a package spec with no
>> corresponding body.
>>
> Even with an interface, a la Java, once the interface is implemented, the
> children dependent on that unit will be dependent on the implementaion,
> not on the interface.

You said that before, and my response is as above: I think you're wrong,
or else I'm misunderstanding what you mean by "depend".  For example:

    package P1 is
        type Iface is interface;
        ... declare some abstract procedures ...
    end P1;

    package P2 is
        pragma Elaborate_Body;
        -- Note that this package spec can be entirely empty (except we
        -- need the pragma so we are allowed to have a body).
        -- So this package spec isn't defining any interface to
        -- anything at all!
    end P2;

    with P1;
    package body P2 is
        type Impl is new P1.Iface with ...
        ... override procedures ...
        ...
    end P2;

    -- No body for P1!

Then the client can "with P1", and call operations on Iface objects
without knowing anything about package P2 (neither spec nor body).
There is no dependence of clients on P2 (unless I'm misunderstanding
what you mean by "depend").

It works the same way in Java, which is not surprising, since Ada's
interfaces were designed with Java interfaces in mind.

>...And Java still has no way of separating the
> specification of that implementing class from its implementation.

...which is irrelevant, since clients don't depend on that class.

>...In
> another forum (comp.lang.programming) someone submitted an
> example to show how interfaces would solve this problem, but the
> example did not separate interface from implementation..
> 
>> Eiffel has separate specs and bodies -- except that the spec is
>> automatically generated from the body, rather than being written by
>> hand.  I prefer to consider the spec to be a source file in its own
>> right, as in Ada, but it's not _that_ different from Eiffel.
>>
> Yes.  In Ada, the specification is most certainly a separate source
> file.  As noted earlier, the specifications and the relatioships between
> specifications, represent the overall architecture of the software
> system.   I'll take another look at Eiffel, a language design I do admire,
> and examine this in more detail.   However, at my present understanding,
> the implementation and specification do not present the same independence
> one finds in Ada.   Perhaps someone will post an example.

Eiffel doesn't have specs in the language.  They're just pieces of text
automatically generated by a separate tool.  But they serve the same
purpose as Ada's specs -- you can read them to understand the interface
supported by a given class.

> Thanks for your details reply.

...and thanks for an interesting discussion.

> Richard 

- Bob