Posts

Test-driven grammar-class understanding with ANTLR

Suppose you would like to understand some grammar classes such as LL(1) and LL(*). Then you might appreciate a test suite like the following, or you would actually try to discover such a test suite yourself. I used the following suite in a lab of my " Software Language Processing " class. It is very convenient means of illustrating things. Students can copy and paste these codes now and further investigate. It helps understanding formal notions and actual, operational parser behaviors. The first ANTLR input specifies a trivial grammar with a fixed lookahead of 1. grammar LL1; options { k = 1; } s : 'a' 'x' | 'b' 'x' ; Let's apply ANTLR: java -classpath ".:antlr-3.2.jar" org.antlr.Tool LL1.g ANTLR likes that grammar just fine. (There are no complains.) We are allowed to infer hence that the grammar is indeed LL(1). The next ANTLR input combines two alternatives that are clearly not LL(1). However, we still use a lookahead of 1. gra...

A tiny bit of denotational semantics

All languages and assignments in this blog post are (C) 2011 Ralf Lämmel. This is actually an assignment for my paradigms/semantics class . Consider the following super-trivial interpreter written in Haskell and in the direct style of denotational semantics: data Exp = Const Int | Add Exp Exp eval :: Exp -> Int eval (Const i) = i eval (Add x y) = eval x + eval y It's time to test: > eval (Add (Const 20) (Const 22)) 42 This incredible language handles integer constants and addition. Now assume that we are adding an "exit" form of expression. The intended semantics of a term "Exit e " is to define the final result of expression evaluation as the value of e . Hence, if an exit expression occurs inside an addition, then the addition is effectively cancelled. Thus: data Exp = Const Int | Add Exp Exp | Exit Exp For instance: Add (Const 20) (Const 22) should evaluate to 42. Add (Exit (Const 88)) (Const 42) should evaluate to 88. A particularly clumsy ...

The underappreciated banana and its buddy monoid

Note : This is the blog post that goes with the Channel9 lecture "Going Bananas". You find all material (slides, code) linked up on the web site for my Channel9 series ; see the section on "Going Bananas". I will add a link to the C9 website with the video as soon as it gets available. I am really Ok. Well, but I do see bananas (folds) everywhere. This tells me that data processing is quite regular. For instance, MapReduce computations for parallel data processing are essentially folds that extract some intermediate data from the records of a voluminous input---subject to subsequent, possibly distributed and staged reduction. Also, in program transformation and analysis, many data processing steps are compositional, and thereby suggest themselves as being implemented through "large" bananas. Further, in XML processing, many operations are busy with folding over XML trees. There are bananas for everyone ---not just for lists. If we were just acknowledging s...

A brutalized Haskell programmer

In working on a special Xmas lecture for my 1st semester course, I was going through Fritz Ruehr's " The Evolution of a Haskell Programmer " only to notice that there is no imperatively faked version that uses references. This omission could be resolved with the following code: module Control.Pascal where import Data.IORef while :: IORef a -> (a -> Bool) -> IO () -> IO () while ref pred body = while' where while' = do v if (pred v) then body >> while' else return () {- ******************************* -} import Data.IORef import Control.Pascal factorial n = do r i while i (>0) ( readIORef i >>= modifyIORef r . (*) >> modifyIORef i ((+) (-1)) ) readIORef r For instance: Prelude> factorial 5 120

Going bananas

This week I will be visiting Klaus Ostermann and his team. I am going to be a guest lecturer in Klaus' programming languages lecture. I am going to misuse this opportunity for a rehearsal of my upcoming Channel9 lecture on bananas. I eat 2 bananas over the last 42 hours in order to get into the right mood. The talk announcement follows. Speaker : Ralf Lämmel , Software Languages Team, Universität Koblenz-Landau Title : Going bananas Slides: [ .pdf ] Abstract : Banana is functional programming slang for "fold", say an application of the catamorphic recursion scheme---most widely known in higher-order list processing in the tradition of the Bird-Meertens Formalism and the Squiggol community. In this talk, I will present various kinds of folds, and thereby show the omnipresence, versatility, and expressive power of folds in different areas of programming. This presentation will integrate work by others and my own in a balanced manner, while aiming at broad coverage of banan...

Grammar-based Testing Revisited

I am about to leave for Southampton ( this is from where the Titanic started ) for a few days to visit Dr. Bernd Fischer , who also calls himself Fish. (Another fish that is!) The idea is to give a talk and have interaction on the topic of grammar-based testing. In fact, I don't tell you any secret, if I say that Bernd is the expert on code generation, and so I am keen to intensify collaboration on that topic as well. The talk announcement follows. Speaker : Ralf Lämmel , Software Languages Team, Universität Koblenz-Landau Title : Grammar-based Testing Revisited Slides : [.pdf] Abstract : Testing grammar-based artifacts has been researched for decades. A classical and enduring motivation for such testing is that grammar-based functionality (such as an interpreter or a compiler) may be formally specified (e.g., by means of an attribute grammar) so that the specification lends itself to test-data generation. The test data, in turn, can be used to test a proper implementation for com...

Statistische Analyse der Parkplatz-Situation auf einem Universitätscampus

Wenn sich ein Kandidat und ein Mitbetreuer etwa aus dem Inst. CV des FB4 (Informatik) findet, dann soll ich dieses ansonsten für illustrative oder Frustrations-lösende Zwecke erfundene Bachelor-Thema am Ende wirklich gern betreuen. Bachelorarbeitsthema Thema : Statistische Analyse der Parkplatz-Situation auf einem Universitätscampus Motivation : Auf dem einen oder anderen solchen Parkplatz bzw. Campus gibt es empirische Hinweise, dass es einerseits zu wenig Parkplätze oder anderseits zu wenig verantwortliches Verhalten der Parkplatznutzer gibt. In Vorbereitung dieser Themenstellung hat der Themenstellende beispielsweise am 3.11.2010 um 8.45 eine Zählung auf dem Mitarbeiterteil des Parkplatzes am Campus Koblenz der Universität Koblenz-Landau vorgenommen. Um diese Zeit waren alle bis auf 3 Parkplätze belegt und diese verbleibenden Plätze waren nicht mit handelsüblichen Fahrzeugen einnehmbar wegen der durch das Falschparken Anderer verursachten Verringerung des Platzes. Knapp 1/3 aller Fa...