ijd@camcon.co.uk (Ian Dickinson) (06/29/87)
> Xref: camcon comp.lang.ada:166 comp.lang.misc:164 Clearly from foregoing discussions, software re-use at the code level does present significant problems: * there is a trade-off - sometimes quite severe - between generality and efficiency * we can never be quite sure of the routine doing exactly what we need in a given circumstance * management of libraries is difficult, as is retrieval * routines in one language are not portable (without effort) to another. So what's the _real_ problem? I think that we are trying to define re-use at too *low* a level. What we really want to re-use are ideas - algorithms, standard ways of performing defined operations, etc,. Hence a solution: we somehow encode _abstractions_ of the ideas and place these in the library - in a form which also supplies some knowledge about the way that they should be used. The corollary of this is that we need more sophisticated methods for using the specifications in the library. (Semi)-automated transformations seem to be the answer to me. Thus we start out with a correct (or so assumed) specification, apply correctness-preserving transormation operators, and so end up with a correct implementation in our native tongue (Ada, Prolog etc, as you will). The transformations can be interactively guided to fit the precise circumstance. The advantages are: * library specifications are easier to understand, hence easier to maintain * the library can contain a smaller number of more general routines, since essentially similar operations can be encoded as one library entry * the additional knowledge can be used to provide an intelligent interface for browsing and retrieval * routines can be transformed to many different languages. I see this field as essentially a synthesis between AI and software engineering, and potentially of benefit to both. [Credit] I originally got this idea from my supervisor: Dr Colin Runciman @ University of York. I have been tinkering around with it in my spare time a bit since then. Who knows, maybe one day I'll get to work on it seriously (dream on :-) !!). -- | Ian Dickinson Cambridge Consultants Ltd, AI group (0223) 358855[U.K.] | | uucp: ...!seismo!mcvax!ukc!camcon!ijd or: ijd%camcon.uucp | >> To dance is to live, but the dance of life requires many strange steps << >> Disclaimer: All opinions expressed are my own (surprise!). <<
jbn@glacier.STANFORD.EDU (John B. Nagle) (07/05/87)
The trouble with this idea is that we have no good way to express
algorithms "abstractly". Much effort was put into attempting to do so
in the late 1970s, when it looked as if program verification was going to
work. We know now that algebraic specifications (of the Parnas/SRI type)
are only marginally shorter than the programs they specify, and much
less readable. Mechanical verification that programs match formal
specifications turned out not to be particularly useful for this reason.
(It is, however, quite possible; a few working systems have been
constructed, including one by myself and several others described in
ACM POPL 83).
We will have an acceptable notation for algorithms when each algorithm
in Knuth's "Art of Computer Programming" is available in machineable form
and can be used without manual modification for most applications for which
the algorithm is applicable. As an exercise for the reader, try writing
a few of Knuth's algorithms as Ada generics and make them available to
others, and find out if they can use them without modifying the source
text of the generics.
In practice, there now is a modest industry in reusable software
components; see the ads in any issue of Computer Language. Worth noting
is that most of these components are in C.
John Nagledinucci@ogcvax.UUCP (David C. DiNucci) (07/06/87)
In article <titan.668> ijd@camcon.co.uk (Ian Dickinson) writes: >> Xref: camcon comp.lang.ada:166 comp.lang.misc:164 >Hence a solution: we somehow encode _abstractions_ of the ideas and place >these in the library - in a form which also supplies some knowledge about the >way that they should be used. The corollary of this is that we need more >sophisticated methods for using the specifications in the library. >(Semi)-automated transformations seem to be the answer to me. > >Thus we start out with a correct (or so assumed) specification, apply >correctness-preserving transormation operators, and so end up with a correct >implementation in our native tongue (Ada, Prolog etc, as you will). The >transformations can be interactively guided to fit the precise circumstance. >[Credit] I originally got this idea from my supervisor: Dr Colin Runciman >@ University of York. In his Phd thesis defense here at Oregon Graduate Center, Dennis Volpano presented his package that did basically this. Though certainly not of production quality, the system was able to take an abstraction of a stack and, as a separate module, a description of a language and data types within the language (in this case integer array and file, if I remember correctly), and produce code which was an instantiation of the abstraction - a stack implemented as an array or as a file. I haven't actually read Dennis' thesis, so I don't know what the limitations of constraints on his approach are. I believe he is currently employed in Texas at MCC. --- Dave DiNucci dinucci@Oregon-Grad