Re: Separate Compilation in Programming Languages

<adaworks@xxxxxxxxxxxxx> writes:

"Robert A Duff" <bobduff@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:wcc63wfpus7.fsf@xxxxxxxxxxxxxxxxxxxxxxx
<adaworks@xxxxxxxxxxxxx> 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
.

Relevant Pages

  • Re: Separate Compilation in Programming Languages
    ... within one package body. ... all, separate or otherwise. ... OK, so you like having textually separate spec and body, ... Clients of an interface do not depend ...
    (comp.lang.ada)
  • Re: [SV] Interfaces should be compiled or included?
    ... If you're using a virtual interface to connect things to an ... it cannot go in a package. ... You could create a package with a typedef in it for the virtual, ... keeping separate those things that should be separate ...
    (comp.lang.verilog)
  • Re: reason for having separate package.lisp?
    ... reasons given *not* to put the package forms in the same file: ... that you achieve modularity when you *separate* different ... implementations that package.lisp be a separate file. ... you'll achieve a separation of interface and implementation. ...
    (comp.lang.lisp)
  • Re: parent package referring to child
    ... handle this in all Ada's spec. ... That is split the FOO package into smaller files and use the "seperate" ... package body Ch10 is separate; ...
    (comp.lang.ada)
  • Re: object system...
    ... In a typed system you can separate implementation from the interface ... How to express in the language a wish to delegate, A of X to B of Y. ... Performance of hash tables is less predictable, ...
    (comp.object)