added a missing summary section to each chapter

Signed-off-by: Konstantin Läufer <laufer@cs.luc.edu>

Author: klaeufer

source/20-imperative.rst

@@ -934,3 +934,19 @@ The following example goes through several evolutions of a simple example to ill
 
 Upon reflection, this journey also leads us away from simple, straight-line imperative or scripting code toward a more complex design involving higher-order parametrization and custom abstractions, which are hallmarks of object-oriented and functional programming.
 The endpoint of this journey thereby marks our transition to the object-oriented paradigm.
+
+
+Summary and further reading
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The imperative paradigm is the foundational model of computation, directly reflecting the von Neumann machine architecture. Its core ideas — named mutable state, sequencing, branching, iteration, and procedural abstraction — appear in virtually every programming language and provide the baseline against which other paradigms are defined.
+
+Working with built-in types and the Scala REPL or scripting tools offers a low-friction entry point into practical programming. As applications grow, concerns such as testability, constant-space complexity, and the separation of logic from I/O motivate the richer abstractions explored in the object-oriented (:doc:`/30-objectoriented`) and functional (:doc:`/40-functional`) chapters. The journey from a straight-line script to a testable, memory-efficient application already hints at these richer paradigms.
+
+Further reading:
+
+- Robert W. Sebesta, *Concepts of Programming Languages* (12th ed., Pearson) — broad survey of imperative, procedural, and other language paradigms.
+- Donald E. Knuth, *The Art of Computer Programming* (Vols. 1–4, Addison-Wesley) — deep treatment of algorithms and data structures from an imperative perspective.
+- `Scala 3 official documentation <https://docs.scala-lang.org/scala3/book/>`_ — authoritative reference for the Scala language used throughout this chapter.
+- `ScalaTest documentation <https://www.scalatest.org/>`_ — reference for the testing framework used in the examples.
+- Gamma et al., *Design Patterns: Elements of Reusable Object-Oriented Software* (Addison-Wesley, 1994) — the canonical catalog of patterns that arise as simple scripts evolve into larger designs.

source/30-objectoriented.rst

@@ -447,3 +447,19 @@ The concrete ``fold.Main`` object is the only place where the two sides are conn
 This arrangement means we can swap in a different implementation—or a test double—without changing ``common.Main`` at all.
 
 
+Summary and further reading
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The object-oriented paradigm extends the imperative model by organizing code around objects — bundles of state and behavior — that communicate through method invocation (message passing). Encapsulation, inheritance, and polymorphism enable the definition of reusable domain models and frameworks, and are the building blocks of many widely used languages and ecosystems.
+
+Scala's combination of classes, traits, case classes, and higher-order capabilities makes it well suited for idiomatic OO design, including clean separation of interface from implementation, dependency injection via the Thin Cake pattern, and progressive refinement of abstractions. Design principles such as SOLID — and in particular the Dependency Inversion Principle — guide the construction of maintainable, modular systems. The endpoint of this chapter, reached by applying these principles, prepares the ground for the functional paradigm (:doc:`/40-functional`), where abstraction is taken further through higher-order functions and algebraic data types.
+
+Further reading:
+
+- Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, *Design Patterns: Elements of Reusable Object-Oriented Software* (Addison-Wesley, 1994) — the canonical catalog of OO design patterns.
+- Robert C. Martin, *Clean Architecture* (Prentice Hall, 2017) — design principles, including SOLID, applied to system-level structure.
+- Martin Odersky, Lex Spoon, and Bill Venners, *Programming in Scala* (5th ed., Artima) — authoritative Scala reference covering classes, traits, and the object model.
+- `Scala 3 official documentation <https://docs.scala-lang.org/scala3/book/>`_ — language reference for features used in this chapter.
+- Wikipedia, `SOLID <https://en.wikipedia.org/wiki/SOLID>`_ and `Dependency injection <https://en.wikipedia.org/wiki/Dependency_injection>`_ — accessible overviews of key OO design principles.
+
+

source/40-functional.rst

@@ -1191,8 +1191,14 @@ Observations
 - The `Cats documentation <https://typelevel.org/cats/>`_ is the primary reference for these abstractions.
 
 
-References
-~~~~~~~~~~
+Summary and further reading
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The functional paradigm treats computation as the evaluation of mathematical functions, emphasizing immutability, first-class and higher-order functions, recursion, and algebraic data types. These properties enable equational reasoning, compositional design, and strong static guarantees via the type system. Compared with the imperative paradigm (:doc:`/20-imperative`), functional code avoids mutable state and side effects; compared with the object-oriented paradigm (:doc:`/30-objectoriented`), it shifts the emphasis from class hierarchies to function composition and algebraic structure.
+
+Scala supports the full spectrum from basic functional idioms — pattern matching, case classes, immutable collections, and for-comprehensions — to category-theoretic abstractions such as functors, monads, and recursion schemes, especially when combined with the Cats and Droste libraries. These abstractions appear throughout the representation and interpretation (:doc:`/50-representationinterpretation`) and concurrency (:doc:`/60-concurrency`) chapters as well.
+
+Further reading:
 
 - Jeremy Gibbons, *Origami Programming* (2003): `PDF <http://www.cs.ox.ac.uk/publications/publication2335-abstract.html>`_ — introduces folds and unfolds as general-purpose programming patterns.
 - Luca Cardelli and Peter Wegner, *On Understanding Types, Data Abstraction, and Polymorphism* (1985): `PDF <http://lucacardelli.name/papers/onunderstanding.a4.pdf>`_ — foundational paper on parametric and subtype polymorphism.

source/50-representationinterpretation.rst

@@ -445,3 +445,19 @@ Additional information is available here:
 - https://martinfowler.com/books/dsl.html
 - https://en.wikipedia.org/wiki/Domain-specific_language
 - `SE Radio episode 182 <http://feedproxy.google.com/~r/se-radio/~3/2VCOnKZ97MU/>`_
+
+
+Summary and further reading
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This chapter connects the study of programming paradigms to the mechanisms that make programs executable and meaningful. A language toolchain — lexer, parser, type checker, and interpreter or compiler — transforms source text into something a machine can evaluate. Formal semantics (operational, denotational, and axiomatic) provide rigorous frameworks for specifying and reasoning about program behavior, complementing the informal descriptions given in the paradigm chapters.
+
+Type systems add static guarantees that eliminate entire classes of runtime errors and guide program construction. Domain-specific languages extend these ideas to specialized vocabularies, either embedded within a host language (internal DSLs built on the functional and object-oriented abstractions of earlier chapters) or implemented as standalone tools. Together, these techniques are the foundation of programming language design and implementation, and they recur throughout the study of every paradigm in this book.
+
+Further reading:
+
+- Alfred V. Aho, Monica S. Lam, Ravi Sethi, and Jeffrey D. Ullman, *Compilers: Principles, Techniques, and Tools* (2nd ed., Addison-Wesley, 2006) — the authoritative reference on lexing, parsing, semantic analysis, and code generation.
+- Benjamin C. Pierce, *Types and Programming Languages* (MIT Press, 2002) — comprehensive treatment of type theory and its applications.
+- Glynn Winskel, *The Formal Semantics of Programming Languages* (MIT Press, 1993) — rigorous introduction to denotational and operational semantics.
+- Terence Parr, *The Definitive ANTLR 4 Reference* (Pragmatic Bookshelf, 2013) — practical guide to parser generation with ANTLR.
+- Martin Fowler, *Domain-Specific Languages* (Addison-Wesley, 2010) — comprehensive guide to internal and external DSL design patterns.

source/60-concurrency.rst

@@ -461,8 +461,14 @@ Several specific concurrency mechanisms can come as language constructs, pattern
 - `software transactional memory <https://en.wikipedia.org/wiki/Software_transactional_memory>`_
 
 
-References: concurrent and asynchronous computing
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Summary and further reading
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The concurrent programming paradigm addresses the coordination of multiple simultaneous activities. Key challenges — shared state, race conditions, deadlock, and the tension between safety and liveness — arise regardless of the specific mechanism used: threads and locks, futures and promises, actors, reactive streams, or software transactional memory. The distinction between concurrency (managing multiple interleaved activities) and parallelism (executing them simultaneously for performance) is an important organizing principle.
+
+Modern Scala ecosystems have largely shifted toward purely functional, composable concurrency abstractions via `Cats Effect <https://typelevel.org/cats-effect/>`_ and `ZIO <https://zio.dev/>`_, which provide structured concurrency and resource safety by construction, and avoid the subtle bugs that accompany unstructured thread and lock programming. These abstractions build on the functional paradigm (:doc:`/40-functional`) and are well suited to the reactive and event-driven styles discussed in the other paradigms chapter (:doc:`/75-otherparadigms`).
+
+Further reading:
 
 - Läufer and Thiruvathukal, `CDER book chapter <https://arxiv.org/abs/1705.02899>`_
 - Goetz et al., `JCIP <http://jcip.net.s3-website-us-east-1.amazonaws.com>`_

source/75-otherparadigms.rst

@@ -201,3 +201,19 @@ Constraint programming extends logic programming by allowing variables to be con
   % X = 1, Y = 9 ; X = 2, Y = 8 ; ...
 
 See also the discussion of Prolog and backtracking in :doc:`/70-logic`.
+
+
+Summary and further reading
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Beyond the core paradigms covered in earlier chapters, declarative, reactive, aspect-oriented, dataflow, event-driven, and constraint programming offer specialized models well suited to particular problem domains. Declarative programming — exemplified by SQL, XSLT, and HTML — describes *what* is desired rather than *how* to achieve it, a theme shared with the functional (:doc:`/40-functional`) and logic (:doc:`/70-logic`) paradigms. Reactive programming brings composable stream operators to continuous event processing. Aspect-oriented programming addresses cross-cutting concerns — logging, security, transactions — that resist modular encapsulation in purely OO or functional designs. Dataflow and event-driven models reflect the structure of many real-world systems, from signal processing pipelines to graphical user interfaces and web servers. Constraint programming extends logic programming with domain-specific solvers for combinatorial search problems.
+
+In practice, modern languages and frameworks borrow freely from multiple paradigms simultaneously. A Scala web service, for instance, may combine OO domain modelling, functional data transformation, reactive stream processing, and actor-based concurrency — making paradigm literacy essential for any serious practitioner.
+
+Further reading:
+
+- Martin Fowler, *Domain-Specific Languages* (Addison-Wesley, 2010) — comprehensive guide to internal and external DSL design and implementation.
+- Stephen Blackheath and Anthony Jones, *Functional Reactive Programming* (Manning, 2016) — approachable introduction to FRP concepts and their application.
+- `ReactiveX documentation <https://reactivex.io/>`_ — reference for the Rx family of reactive programming libraries (RxJava, RxScala, RxJS, and others).
+- `SWI-Prolog CLP(FD) documentation <https://www.swi-prolog.org/man/clpfd.html>`_ — constraint logic programming over finite domains.
+- `Cats Effect documentation <https://typelevel.org/cats-effect/>`_ and `ZIO documentation <https://zio.dev/>`_ — structured, functional concurrency and effectful reactive programming in Scala.