🚀 go-pugleaf

In article <5490@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe,2847,) writes:

   Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu
   Lines: 108

   From tada@athena.mit.edu (Michael Zehr):
     There have been a couple of good comments about using software
     components, but so far most of them have been along the lines of
     "such-and-such a language does this."  Could you describe *how*
     the language provides both efficiency and quick building time?
     For example, one person mentioned Ada's "re-binding" of
     executables.  What does this do?

	... many good descriptions of separate compilation ...

       Another mechanism is the "package".  One use of packages is to
       describe specifications (*compilable* specifications) for
       subsystems which collectively interact to form a larger system.
       Once the high-level specifications have been compiled together,
       the information flows across the subsystem interfaces have been
       verified for completeness and consistency.

this `checking for completeness and consistency' is actually nothing
more than a static type check.  since in a large application, the
constraints on the interface between packages is considerably more
complex than just having the communication merely be of the correct
type, this should not be characterized as a full verification.

	... more good comments are modular development ...

       The package specification forms a contract between the
       implementor and the other project members; if everyone fulfulls
       their end of the deal, then the entire system is guaranteed to
       work as far as information flows are concerned.

again, this checking is far from complete (as it must be at the
current state of the art).  satisfaction of the type constraints is a
BIG step along the way toward making things work smoothly, but there
are an enormous number of constraints in a real program that cannot
reasonably be expressed as type constraints.  some, such as the sum of
the squares of the first two arguments is greater than the square of
the third, could be effectively checked by assertions.  other aspects
of the interface cannot even theoretically be checked by a compiler
(such as the values returned by a function will be returned with 10
ms. of a call).

again, type checking is almost always a GOOD THING, but it is also
almost always not enough to verify that the communication between
parts of programs are correct.

	... more good comments about the benefits of libraries and
	separate compilation ...

   Someone also mentioned being able to reuse components in
   different languages.  I agree that this is crucial in combining
   efficiency with productivity.  So far, my experience with
   mixed-language coding is that it is very easy on Vaxes (becuase
   of the forced procedure interface of the CALLS instruction) but
   extremely difficult on IBM mainframes (because there is no
   standard calling sequence).  Does anyone have any experience in
   mixed-language coding on newer RISC machines?  Do compiler witers
   stick to "standardized" calling mechanisms?

	... good stuff about the ada party line ...


----------------------------------------------------------------

and now for the view from the rest of the world.

type checking is a good thing.  separate compilation is a good thing.
libraries and linkers that understand type checking are a good thing.

none of these are particular to ada.  some or all of these can be
found in ansii c, commercially available pascals, c++ and other
languages.  some of these solutions are partitioned differently from
the way specified by ada orthodoxy, often with the result of more
flexibility.  this is the case with make.

one place that most of these tools fall down at the current time is
with program generators and preprocessors.  the requirement that we
specify interfaces completely in terms of base language leads to very
serious awkwardness if when we try to replace the functionality of
yacc or make heavy use of precompilation as do the internals of the
gnu c compiler.

the failure of tools in the face of language extension is an issue
that has been long recognized in lisp circles.  only recently are
conventional languages being used (and shown insufficient to the task)
in such advanced applications.  a serious case in point is the x
toolkit as implemented in c.