The integration of database and programming languages is difficult due to the different data models and type systems prevalent in each field. We present a solution where the developer may express queries encompassing program and database data. The notation used for queries is based on comprehensions, a declarative style that does not impose any specific execution strategy. In our approach, the type safety of language-integrated queries is analyzed at compile-time, followed by a translation that optimizes for database evaluation. We show the translation total and semantics preserving, and introduce a language-independent classification. According to this classification, our approach compares favorably with Microsoft's LINQ, today's best known representative. We provide an implementation in terms of a Scala compiler plugin, accepting two notations for queries: LINQ and the native Scala syntax for comprehensions. The prototype relies on Ferry, a query language that already supports comprehensions yet targets SQL:1999. The reported techniques pave the way for further progress in bridging the programming and the database worlds.

Figure 3: Integration of the ScalaQL compiler plugins and other compilation phases

• sts.ferry: contains the source for our Scala-based type and well-formedness checker of Ferry queries (Full Ferry including Ferry Core);
• sts.compilerPlugin: contains the source of the compiler plugin proper, which extends scalac with two custom phases, LINQToScala and ScalaToFerry. These phases are executed after the scalac 'parser' phase.
• sts.linq: contains the source of LINQToScala, a parser of LINQ queries that translates them to Scala comprehensions. In more detail, the parser takes as input a string representing a LINQ query and returns another string containing the corresponding Scala comprehension.
• sts.compilerPlugin.annotations: contains the annotation types (@LINQAnn and @Persistent) used to tag the inputs to the LINQToScala and ScalaToFerry phases.

The ScalaQLproject can be built following these steps:

1. Download the zip file containg sources (see below)
2. Import the existing ScalaQL project from the downloaded archive to your Eclipse workspace (the Scala IDE for Eclipse has to be pre-installed, detailed instructions can be found here)
3. Add the following jars to the 'lib' folder, make them part of the buildpath:
   • scala-library.jar (scala distribution)
   • scala-compiler.jar (scala distribution)
   • kiama-0.5dev.jar (kiama project)
4. Run the provided build.xml. This requires one slight change: the property scala.home should be set to reflect the location of your Scala installation (i.e., where scala-library.jar and scala-compiler.jar are located, and by the way, we have used Scala 2.7.4-final). That distribution is available at http://www.scala-lang.org/downloads). Running build.xml will delete the 'bin' directory (the output folder for class files), compile the source code from the 'src' folder to a new 'bin' folder, and prepare two jar files, ScalaQL-1.0(beta)dev.jar and ScalaQL-1.0(beta)dev-src.jar, placed to 'dist' child directory. The first file, ScalaQL-1.0(beta)dev.jar, includes all the required class files along with plugin.properties and the all-important scalac-plugin.xml.
5. Development has relied on Kiama 0.5 for parsing, which can be found at http://code.google.com/p/kiama/
6. Create a new run/debug configuration (as shown in Figure 4 below) with the main class scala.tools.nsc.Main. The file ScalaQL-1.0(beta)dev.jar should be passed to scalac as -Xplugin option argument (i.e. ${workspace_loc}\ScalaQL\dist\ScalaQL-1.0(beta)dev.jar) along with the target .scala source file to be compiled (for example, ${workspace_loc}\ScalaQLTest\test\MyQLAppl.scala).
   For additional details see [scala-tools] running/debuging compiler plugin from Eclipse

Figure 4: Run configuration to debug the compiler plugin

• Microsoft C# Language Specification 3.0
• Ferry
• Pathfinder (in particular, its query optimizer)
• Ezra Cooper: The script-writer's dream: How to write great SQL in your own language, and be sure it will succeed (Tech report)
• Several internal DSLs have been developed to express queries in Scala, as reviewed in a paper by Spiewak and Zhao. In particular, the ScalaQL prototype described in that paper is not to be confused with ours.