How the LINQ framework for Language-Integrated Query aims to reduce the impedance mismatch between programming languages and query languages.
General background on Microsoft’s .NET Framework: it’s a large platform for program development; as part of this, it has some interesting programming language features. In particular its support for working in multiple languages, exchanging strongly-typed data and code at a high level.
Review of standard SQL-query-as-a-string technique in Java and (almost identically) in C#. Advantages, limitations. What LINQ does to lift some of the limitations. There is convenient SQL-style syntax; but that’s a distraction, the key advance is to connect the semantics of the two language domains. This then brings in type checking, smart IDEs, compiler optimisations, automatic query bundling, abstraction of query constructors, query constructor constructors, user-extensible query libraries, etc. etc.
How this requires (and contributes) a sackful of additional language features, most taken from existing research languages, which themselves have wider application; LINQ as a Trojan horse.
The end result is that a LINQ programmer can write a simple boolean test in C#, or any .NET language, and use it to filter all kinds of data: an array in C#, a table in SQL, or a tree in XML. All being well, LINQ will inspect the semantics of the underlying expression and convert it to the right domain.
Next week: what else it can do, when it doesn’t work, and how that might be fixed.
What’s in a Name?
During the lecture I referred to the work of Mike Just and others on knowledge-based authentication. There is a discussion of this on the Light Blue Touchpaper security blog, and you can also read the recent published paper and some slides from a recent presentation.