🚀 go-pugleaf

From ted@nmsu.edu (Ted Dunning):
>        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.

   I don't think I characterized this as a full verification, since I
   did explicitly refer to integration testing.  If a "full verification"
   was done, including semantics, then integration testing would become
   unnecessary.  "Completeness and consistency" was intended to make it
   clear that I was excluding semantics.

> 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.

    I don't think make has any more flexibility than the tools
    provided by Ada compiler vendors; see Telesoft's amake, for example.

> 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.

    My program generator experiences lead me to believe that such
    software should generally have an interactive interface.  For
    example, a generator which assists in the design of screen layouts
    should do so on the basis of interactive inputs, in conjunction
    with the selective employment of screen editors when the programmer
    needs to specify a procedure for handling the user input of a 
    particular data item.  I think this tactic can be used to successfully
    handle program generation requirements, since I have used it myself
    with extremely satisfying results.  As for precompilation, I see no
    reason why this should be a problem.   

    (This seems to be getting away from software components, 
     so I've redirected followups to comp.software-eng...)


    Bill Wolfe, wtwolfe@hubcap.clemson.edu