## 10 Conclusions
### ICOREs as a Declarative Specification Framework
So the question is: What can be done conveniently and _efficiently_ with ICOREs? Our hope and goal of future research is to show that if a class of problems over sequences or trees has a known, efficient dynamic programming solution, then we can model such problems as ICOREs. Constraints and benefits in building ICOREs.ICOREs are based on a small number of well-understood formal concepts: Algebras, grammars, and rewrite systems. Although those concepts are likely to be familiar to any computer science graduate and have a strong intuitive appeal, we are that aware that designing an ICORE requires some discipline. Assume [PERSON] is a programmer, experienced in the implementation of dynamic programming algorithms in the classical, non-algebraic style. The last thing [PERSON] would think of when facing a new problem is to design a data type to explicitly represent the candidates in the search space. Indeed, the efficiency of dynamic programming comes from the fact that candidates are not constructed explicitly. Dynamic programming only derives score values from (some) candidates, and for the optimal one(s), the backtrace constructs (only) a visualization. What is eventually printed in the output need not reflect in full detail the case analysis that has rendered this particular candidate optimal. Therefore, from the experience of [PERSON], there is no need for a candidate data type. In fact, when we look at present-day algorithm textbooks, such as [47, 48], there is not one case where such a data type is introduced. With ICOREs, [PERSON] will have to explicitly declare a core signature on which terms represent solution candidates. The whole problem is now split in three parts: A grammar defines the universal search space, rewrite rules define the search space of a problem instance (as the inverse rewrite image of the problem inputs), and algebras provide scoring and optimization objective. If all [PERSON] plans to do is solving a single optimization problem under a simple scoring scheme, all this machinery must appear unnecessary and verbose. However, we hope to have demonstrated that this separation of concerns, which emerges from the core signature, has a profound and beneficial effect on how we develop specifications in more sophistcated application scenarios. * The definition of the search space is independent of any scoring algebra. We can experiment with alternative models, we can refine rules and/or grammar, for example to eliminate mal-formed candidates from the search space (rather than tricking with \(\pm\infty\)). We can test how the size of the search space is affected by design decisions, independent of scoring. We can worry about (non-)ambiguity of our problem decomposition by studying properties of the grammar. * When it comes to evaluating candidates, we can formulate arbitrary algebras over the given signature. For each, we need to prove that it satisfies Bellman's Principle. Fortunately, this is independent of the search space and how it is constructed. * Rewrite systems and algebras can be combined correctly in a modular fashion, bringing to bear the software engineering principles of component re-use and ease of modification. * Finally, as seen in Section 8, the ability to define product operations on algebras and produce refined analyses from simpler ones is also due to the perfect separation of search space and evaluation of candidates.