The world of legacy software exists [1{8]. Despite numerous prognoses about certain languages going out of fashion and disappearing, many languages resist this natural process: COBOL (1959), RPG (1959), VISION:BUILDER (1960 as MARK IV), PL/I (1964), RAMIS (1965), CLIST (1970), FOCUS (1970), PACBASE (1973), BIS (1975 as MAPPER), REXX (1979), TELON (1981), CA GEN (1987 as IEF), jBASIC (1991), etc. They continue to be used extensively across billions of lines of code, literally decades after going out of fashion [9{11]. The world of legacy software evolves and grows, absorbing new languages as years go by. Only a handful of legacy systems are suitable for complete redesign and rewrite, while the bulk of software systems in nance, banking, insurance, logistics, booking, as well as in a number of other domains, are too large, too complex and too expensive to be replaced in simplistic ways. Hence, we need to develop methods and tools to analyse such software to aid in this never-ending battle by providing compilers, analysers, transformers, refactorers, testers, linters, validators. During this keynote, participants were confronted with a carefully selected subset of features encountered by industrial compiler engineers in legacy code. Condensed by language design magic into one deliberately small language called BabyCOBOL [12], this collection is meant to represent the challenge of processing legacy code to the software evolution community, such as: • parsing indentation-driven notations, • dealing with line continuations, • identifying keywords which are not reserved,
• resolving symbols with case insensitivity, • syntax highlighting with insigni cant whitespace, • implementing the picture clause data type, • preprocessing lexical imports, • unpuzzling su ciently quali ed identi ers, • unfolding contracted conditions, • relying on name-based deep traversing assignments, • using context-dependent gurative constants, • altering unconditional branching addresses at runtime, • branching to sentence-based code locations, • executing paragraphs in a serial way, • having detachable clauses in structured loops, • combining exception handling with other features.
The participants have witnessed the rst public exposure of this meeting point between the industrial community that is creating tools for handling real legacy languages (each demanding several humanyears of professional investment and therefore completely unsuitable for research prototyping) and the academic community which consists of many comfort bubbles of idealised toy languages (with consistent design that rewards emergence of glori ed techniques that optimistically assume overly rational language features).
We hope that by designing university courses on compiler construction, software language engineering and software evolution around BabyCOBOL instead of MiniJava or While, will help preparing students for the future, arming them with the skill to build tools to deal with the software systems of the past. At the same time, trying out any new technique on BabyCOBOL seems feasible to quickly prototype and t within an academic paper, and ensures the technique's applicability to a range of legacy languages.