Software Language Engineering (SLE) has emerged as a field in computer science research and software engineering, but it has yet to become entrenched as part of the standard curriculum at universities. Many places have a compiler construction (CC) course and a programming languages (PL) course, but these are not aimed at training students in typical SLE matters such as DSL design and implementation, language workbenches, generalized parsers, and meta-tools. We describe our experiences with developing and teaching software language engineering courses at the Universities of Bergen and KoblenzLandau. We reflect on lecture topics, assignments, development of course material, and other aspects and variation points in course design.
Software Language Engineering (SLE) is concerned with design, implementation, composition, evolution, and other aspects of software languages and languageaware software components. SLE uses language models which break down into definitions of syntax, well-formedness, semantics, etc. Language implementation is concerned with parsing, semantic analysis, translation, IDE support, etc.
SLE is yet to become entrenched as part of the standard curriculum at universities. Many places have a compiler construction (CC) course and a programming languages theory (PLT) course, but these are not aimed at training students in typical SLE matters such as DSL design and implementation, language workbenches, generalized parsers, and meta-tools. In this paper, we describe our experiences with developing and teaching software language engineering courses at our universities, reflect on course material, and discuss variations on course design.
Here is a summary of lessons learned: SLE scenarios involve various artifacts (grammars, programs, rewrite systems) and data flows (parser generation, parser compilation, parser application), which needs comprehension support. We found megamodeling to be effective in this context. SLE shares much of its foundations with model-driven engineering (MDE) and CC. Further, SLE depends on foundations from PLT. Of course, SLE also assumes foundations from general software engineering (SE). Managing these dependencies in actual course designs may require substantial efforts.
Introduction List principles of SLE; summarize features of a language Syntax, grammars, parsing Understand syntax; engineer grammars; (re)use parsers Domain-specific languages Recognize a DSL in a realistic setting; recognize its domain Scannerless parsing, layout Understand tradeoffs between different technologies Evaluator-based semantics Apply language engineering; recognize language semantics Scoping and environments Understand scoping; implement it Type checking Understand and implement semantic analysis Tree traversal and rewriting List different approaches to language processing Term project introduction Design and plan an SLE experiment Formal semantics Recall basics of formal semantics Term project presentations Present, discuss and analyse projects
SLE, as a teaching area, is more obviously addressed by ‘presence courses’; it is less obvious how to apply eLearning or MOOC in this context because the engineering aspect of SLE and richness of related technologies and methods calls for project work including student presentations and discussion.
Roadmap. The rest of the paper provides details on our SLE course experiences. §2 contains facts about two SLE courses in which the authors were involved as teachers. §3 discusses the use of megamodels in SLE courses. §4 makes explicit a number of variation points for SLE course designs. §5 synthesizes guidelines from our experiences. §6 discusses related work in the context of CS education. 2 2.1
SLE in Bergen Position in curriculum. The course fills the slot of the old traditionalistic CC course in Bergen, keeping the same title (Introduction to Program Translation ), but being more of an introduction to software languages and software language engineering. The course is 10 ECTS credits, being optional but available to students at all levels. In terms of dependencies, we recommend that the students have a basic computer science background, including a course on programming paradigms. Unfortunately, there is currently no course offered on PLT or semantics, which could given the students useful background for the SLE course. The course runs every second year (two actual runs so far: 2011 and 2013).
Overall format. The course is centered around lectures and lab exercises,
per week we have two 90 minute lectures and one 90 minute lab; the rest is
selfstudy. Rascal [
The course plan is loosely structured, and is adapted to the needs and interests of the students. Given the students’ weak background in programming languages, we usually spend a fair amount of time filling this gap.
Small imperative/OO language with interpreter Handwritten Visual C++
C with ARM backend Handwritten C
Language operational semantics and prototyping Prolog
Language implementation for LLVM OCaml
Forth-like language Haskell
Code formatting Java and PGF [
Lectures. The lectures contain a mix of theory and practice, with theory explained on the blackboard and in discussions, and then illustrated by example in live coding sessions. The code is then made available to the students, as a basis for or complement to exercises.
The 2013 lecture plan (sketched in Table 1) includes 22 lectures, of which six are dedicated to recap and term project presentations and discussions. In addition to covering fundamental topics, the first few lectures also showcase language-based modeling and engineering using invited speakers.
The blackboard is used for theory and smaller examples, and for giving big picture overviews of concepts and relationships (megamodels). Live coding is semi-interactive, with feedback and suggestions from the students. Seeing a theoretic concept immediately implemented in practice seems helpful to students’ understanding — though perhaps an even better approach would be to do this in a lab setting where the students could experiment on their own rather than watching the lecturer.
Assignments. Lab work consists of a mix of non-compulsory weekly exercises, designed to help understand and retain the topics discussed in the lectures, and a compulsory term project towards the end of the semester, where the students typically end up with a full small-scale software language implementation.
The weekly exercises include topics such as regular expressions, grammars and parsing, and language implementation — usually fitting together with whatever is covered in the lectures.
The term project is completely open-ended (in the 2013 edition), with a free choice of topic and technology. Table 2 sketches some of the projects the 2013 students chose. Roughly a third of the course was spent on the project.
Grading. We have a 45–60 minute oral exam, beginning with a presentation and discussion of the term project, and concluding with theoretical questions. With the open-ended term project, assessing and comparing the students’ work proved quite difficult, so rather than grading the end result, we focused more on the students’ insight into their language engineering efforts and their ability to reflect on design choices.
Material. For the 2011 edition of the course, we used Scott’s Programming
Language Pragmatics [
Introduction Recognize SLE in the computer science context An SLE bibliography Summarize landmark SLE literature A DSL primer Carry out modeling of DSLs Grammars and parsing Implement parsers / frontends of language processors Megamodeling Recognize and navigate the linguistic view on technologies Attribute grammars Implement semantic analysis for languages Rewriting & strategies Implement software transformations in language processors Automated refactoring Recall challenges of refactoring across languages Grammar-based testing Understand grammar-aware testing of language processors Code generation Summarize an architecture of a compiler backend edition was based entirely on the lectures and associated notes. Additionally, we have developed a glossary of SLE terms, which was also made into flash cards for exam preparation. All course resources are available online: http: //bitbucket.org/anyahelene/inf225public/wiki. 2.2
SLE at Koblenz The course — http://softlang.wikidot.com/course:sle — has been held 4 times by now, but in its current, now stabilized form it has been held only twice.
Position in curriculum. The SLE course is a 6 ECTS optional module for CS students. In Koblenz, optional modules are open to BSc and MSc students, but MSc students are better prepared for this course, as they would have completed a compulsory BSc module on PLT, which is typically taken only towards the end of the BSc. The SLE course was designed to replace a conservative CC course. A modern CC course would still be a good complement, but there are currently no additional resources available for it.
Overall format. The 6 ECTS of the course are evenly distributed over lectures and labs. Thus, there is one lecture and one lab per week over the duration of a semester with 60–90 minutes for each meeting. There are three to four assignments over the duration of the course; two involve software development, one or two are reading assignments. The results of all assignments are presented by the students and discussed in depth at the lab meetings. The development-oriented assignments use a Scrum-like format (again scheduled for the lab meetings) to discuss plans, intermediate results, and open issues. There is no exam; instead the assignment results are used for grading. The interactive format works best for smaller numbers of students: 10-15. If we were taking more students, the amount of student presentations would be hard to handle and the necessary number of variations on a given assignment would be hard to design.
Lectures. In Table 3, the topics of the lectures and a short indication of the associated learning objectives are shown for the most recent edition of the course. A few things are worth pointing out. The lecture titled An SLE bibliography surveys SLE literature briefly to introduce the students to the SLE area in a literature-based manner. The lecture is based on annotated SLE bibliogra
Reading Seminal literature on SLE 2 week Development DSL implementation 3 weeks Reading Grammar-based testing 1 week
Development Grammar-based testing 3 weeks
phy [
Assignments. In Table 4, the assignments are briefly characterized for the
most recent edition of the course. Students work individually or they team up
with one partner. The idea is that the assignments do not just help with technical
skills in SLE, but they also contribute to soft and research skills more generally.
Thus, reading, presentation, and discussion are important elements of the course.
The feedback by the students regarding this format has been consistently
positive. An assignment solution for a test generator of the recent course edition was
eventually refined and could be published at the SLE 2014 conference [
Grading. As mentioned before, there is no exam. The assignment results are used for grading. In our experience, the students highly appreciate this form of course completion because it motivates them to invest into the assignments and they do not face another exam at the end of semester. Given the breadth of topics in the course, a conservative exam would be a design challenge anyhow.
Material. The course does not leverage any specific textbook or small set
thereof. Instead, the course leverages a small annotated bibliography [
We have found that the architecture of language processors and the
underlying technologies as well as some SLE processes can be described at a high level
of abstraction by means of megamodels [
In Figure 1 and Figure 2, we show two megamodels as they play a role in the SLE courses. The model at the top appears in the parsing lecture of the Koblenz course. It is used to explain the basic data flow around parser generation and aSource
L(G) inputOf
Type-2 G
implements Parser hasOutput
Parse forest invocation. It also adds a few conceptual characteristics such as the expectations that we start from a context-free (type 2) grammar. We also expresss that the input does at least agree with the terminal set of the grammar. Practically, this assumption may not hold, but the megamodel provides a good abstraction for discussing such issues. Likewise, the indication of a parse forest is merely meant to allow for the discussion of ambigious grammars and the different possible strategies of parsing technologies.
The megamodel at the bottom provides a highly conceptualized view on parsing, unparsing, and related operations or parts thereof. Various representation levels (such as strings, tokens, ASTs) and various phases of parsing are called out. In a given language implementations, several nodes and edges in the model are irrelevant, but the megamodel allows for a systematic discussion of options in language implementation and associated properties such as bidirectionality. 4
Over the timeline and over the different courses, we experienced some variation points for SLE courses that we discuss here.
Overlapping with MDE and CC. Conceptually, SLE is close to CC and MDE. For instance, the concepts of parsing, semantic analysis, intermediate representations, and code generation are integral parts of a typical CC course, which should also play a role in an SLE course. Likewise, the concepts of metamodeling, model transformation, and traceability are integral parts of the MDE body of knowledge, which should also be covered in an SLE course.
However, it is practically impossible that an SLE course would cover both CC and MDE. Historically, CC courses cover grammar classes and associated parsing algorithms in much detail. They also cover non-trivial foundations of optimization (e.g., flow analysis) and code generation (e.g., BURS). In contrast, an SLE course should favor one or two state-of-the-art practical parsing approaches (such as LL(*) and generalized LL/LR parsing) without in-depth coverage of the involved algorithms. Likewise, an SLE course should only have cursory coverage, if any, of compiler optimization and code generation. Also, an SLE course cant bstrac (lexiLcaelmxodel) A xtract atten
e fl m2mtransformation not include4an introduction MtoaMppDinEg,sbut MDE technologies could be leveraged
Artefacts and in an SLE course, if students have some prior understanding of metamodeling. For instanceL,etMusDfirEst-binatrsoedducetethcehkninodlsoogfiaersteffaocrtslwaenwgiullaugseefoirmthpeleremmaeinndteartoifotnh,e e.g., Xtext, paper: could be used• Sitnr —adadsittriinogn. to technologies from the CC and PLT communities.
Less ver•suTosk —maofirneitetseeqcuhennceoolfostgriinegss(.callTedhteokeKnso)bwlheicnhz,wchoenucrosnecahteansateuds,ed multiple technologies. Inyields Str. Includes spaces, line breaks, mcomenmtents, etc — collectively, ldayeonutt.s were given particular, for the develop assignments, stu • TTk — a finite sequence of typed tokens, with layout removed, some classified technology optaisonnusmbaenrsdoftshtreinygsc,oetuc.ld even suggest alternative routes. The Bergen course uses n•oLwexR—aascleaxilca[l1s1ou]racesmtohdeel [m28a,2i9n] thtaetcahdndeoslogrgoyupiinng tloectytpuinrge;sin. fact a possibly incomplete tree connecting most tokens together in one structure.
Staying w•itFhor a— sainfogrleest oofr paarssemtraeells, saetpaorsfe tgeracphhnoorlaongiaemsbihguaosusapanrusemtrbeeer of advantages: (1) the tweicthhsnhoarliongg;ieastraeer-elik(ehstorpucetfuurelltyha)twmeoldle-lksnStor wacncorbdyingthtoeatseyantcahctiincg staff, who can then guidedetfihnietiosnt.udents in their use; (2) the students have a chance to gain a deep enough understanding to actuall5y use the selected technologies properly; (3) lab setup and exercise design becomes somewhat easier.
Covering a wider range of technologies also has its appeal. Firstly, students become aware of the broad offering of SLE tools and technologies. Secondly, if the students use different tools, they can exchange experiences and insights — perhaps broadening the horizon of the lecturer as well.
Less versus more theory prerequisites. A typical Koblenz student has taken a course on PLT and is familiar with functional programming (FP). A typical Bergen student has taken a programming paradigms course which includes a brief introduction to functional and logic programming, but there is no counterpart for syntax, semantics, and type systems of programming languages.
SLE relies on concepts such as context-free grammars, scoping, types, stores, and interpreters. Thus, if students lack such background, then an SLE course must definitely spend some time on these concepts. However, an applied and selective approach is applicable here. For instance, a pragmatic approach to type checking and operational semantics-inspired interpretation is possibly sufficient.
Exercises versus projects. By exercises we mean weekly assignments complementing one another and expanding on the topics covered in the lectures. By projects we mean substantially bigger assignments that may run over several weeks and involve extra milestones such as intermediate and final presentation.
Both in Bergen and Koblenz, we mainly use projects. In fact, exercises are not used at all in Koblenz, but reading assignments provide another category. The reasoning is here that an SLE course is similar to a practical SE class, where actual designs and implementations must be developed, the underlying technologies selected, and students must familiarize themselves with the technologies. This scope typically implies projects, except for the more basic notions such as interpretation, which could be covered with the exercise format.
Less versus more constrained assignments. Should assignments
specify a specific SLE problem? An example of a more constrained situation is the
first development-oriented assignment of the Koblenz course (§2.2): students had
to implement a given DSL FSML—a language for finite state machines [
According to the evaluation, Bergen students were happy with the freedom
given, and felt that they learned a lot. In particular, several of the students
learned hard lessons about the value of using specialized tools and languages
rather than implementing things by hand. We know that open assignments are
harder to complete and to grade, since they pose greater strain on the
evaluative skills [
Less versus more conservative exams. We take a hands-on approach to SLE in our courses. The lectures do provide conceptual knowledge, but we consider it most important that students can design and implement language processors. Thus, a conservative exam which would be focusing on definitions, syntax, type systems, semantics, programming in the small, and engineering methods or process would be ill-suited for the hands-on orientation. Thus, project assignments are to be part of the grading scheme. In Koblenz, the course has evolved to the point that projects are the sole input for the final grade. To this end, we place high priority on the presentations per assignment, where students need to make an effort to connect to general concepts from the lecture and discuss their approach at a high level of abstraction.
The content of a modern SLE course spans over a range of technologies and approaches. This places higher demands on both teaching staff and students. We are beginning to cope with this complexity by leveraging students’ curiosity and letting them choose, prepare, and present study units. Special techniques are needed for explaining the state of the art in SLE, without overwhelming students with the complexity of modern technologies, languages, and frameworks. We found megamodeling and megamodel renarration to be useful tools for comprehension and comparison.
SLE is an advanced course, and thus its design should be context-aware. For example, in a curriculum which covers model-driven or model-based topics, a modelware-centric instantiation of SLE is appropriate. In another curriculum which covers compiler construction, a grammarware-centric instantiation is appropriate.
As typical for software engineering, certain SLE problems manifest easier on a large scale and may require significant investments by the students to master the involved methods and technologies. Hence, an SLE course should favor bigger and open-ended projects over strict-portioned exercises. Grading in an SLE course should not focus on the deliverables developed in project work, especially when the students may explore different tasks and technologies, as assessment would be hard and possibly unfair. Instead, the focus should be on assessing the gained insights and acquired skills. An SLE course should not be seen or designed as replacing or subsuming PLT, CC, and MDE courses. Instead, these different courses may complement each other, while the SLE course may even function as a meeting point where those domains can be connected in a broader sense.
The most basic SLE methods are parsing, analysis, interpretation, translation, and generation. Curricula are ideally tuned so that some elements of these methods can be effectively prepared by courses on formal languages and programming language theory or paradigms, if not introduction to computer science, so that an SLE course can focus on engineering aspects, e.g., conflict or ambiguity resolution in parsing. 6
Some modern CC courses successfully persist in following the “let’s make a
compiler” paradigm [
There are currently no textbooks that can form a sole basis for an SLE
course. We have made an attempt to systematically explore the methods and
technologies of SLE in order to create a designated SLE course that could replace
or complement courses for CC, PLT, and MDE in a CS/SE curriculum. Course
designs elsewhere show the blurring boundaries between the subjects [