NivaarExam PrepOfficial exam papers ↗

19-Soft-B17 Data Visualization · December 2014

Question 9 of 10

Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)

Notes on this paper

04-Soft-B17, Programming Language Paradigm — National Exams, December 2014 (3 hours, open book, 10 questions of equal value, essay-format answers).

Reference texts: Sebesta, Concepts of Programming Languages, 12th ed. (object-oriented language design, subtyping, functional programming, exception handling, lambda expressions); Sommerville, Software Engineering, 10th ed. (object-oriented design, modularity); Gamma et al. (GoF), Design Patterns, 1st ed. (composition-over-inheritance, Liskov Substitution Principle in practice).

Check: this paper's printed course title and all ten questions are exclusively about object-oriented and functional programming-language concepts (classes, subtyping, overriding/overloading, exceptions, functional vs. procedural style, actor model, lambda expressions, immutability) — there is no data-visualization content anywhere in the paper. This solution follows the exam as printed ("04-SOFT-B17: Programming Language Paradigm").

Question 9 (10%)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

A lambda expression is an anonymous function: a function definition — a parameter list together with a body that computes a result from those parameters — written directly as an expression, without being bound to a declared function name, and typically usable as a value in its own right (it can be assigned to a variable, stored in a data structure, or, most commonly, passed directly as an argument to another function). The name comes from Alonzo Church's lambda calculus, a formal mathematical model of computation in which every function is written as an unnamed expression of the form λx.body, meaning "the function that takes a parameter x and returns the value of body." Modern languages adopt the same idea under different concrete syntax: a Java lambda (x, y) -> x + y, a Python lambda lambda x: x * x, and a JavaScript arrow function x => x * x are all lambda expressions in this sense — each defines a function inline, with no separate named declaration, that can be handed to something else expecting a function value.

Lambda expressions matter primarily because they enable and simplify higher-order functions — functions that take other functions as arguments or return them as results. Rather than defining a small, single-use, named helper method purely so it can be passed to, say, a sorting routine's comparator parameter or a collection's map/filter operation, a programmer can write the desired behaviour inline exactly where it is needed, as a lambda expression, keeping the intent of a short piece of logic visible right at its point of use instead of scattered into a separately-named method elsewhere in the file. In languages with first-class functions, a lambda expression is simply a compact, unnamed way of producing a function value, exactly as a numeric literal like 5 is a compact, unnamed way of producing an integer value — both can be used anywhere a value of the corresponding type is expected, without ever needing a name of their own.