In parts 1 and 2 we defined our core query types and figured out how to insert into the database. Here, we'll actually write some queries. We're going to port the professional hitmen example from William Yao's which type-safe database library should you use blog post to Databass and see how it stacks up.
Welcome to Databass, Part 2, even more bass. In part 1, we defined a query GADT and runQuery function. Here, we'll figure out how to materialize relations and tuples in memory. As before, full source is on github. First, though, I had a question about implementing Group and Ungroup, which we skipped in part 1.
It's been a while since my last language series on this blog, but I figured I shouldn't let an entire calendar year go by without doing some technical writing here. This time we'll be working on creating a toy relational database in the vein of Tutorial D, as described in Databases, Types, and The Relational Model: The Third Manifesto by C.
It's been over a year since my last post here. Since the end of the MicroC series, I've been hard at work on my thesis, Open Strings, a platform for string players to share fingerings for complex passages. In addition to allowing musicians to share fingerings, the Open Strings website includes an inference engine which, given a passage, will automatically come up with decent fingerings for it (currently violin only).
In our last post, we completed the backend stage of the compiler by emitting llvm assembly using llvm-hs-pure and llvm-hs-pretty and then calling clang on the file output. Here, we'll get a taste of how to use the ffi bindings in llvm-hs to do the same thing and also to perform stricter checks on our generated llvm code.
In part 2, we completed the user facing part of the compiler with semantic analysis. Now we're free to focus on the backend, generating LLVM. To do so, we'll use the llvm-hs-pure library, which embeds LLVM into a Haskell ADT, allowing us to manipulate it without having to set up any FFI.
Having written the parser for our C dialiect in part 1, we now proceed to the semantic analysis pass. Here, our goal is to catch as many errors as possible before going on to code generation. In particular, we will be somewhat stricter than real C compilers and disallow implicit conversions because they are both annoying to implement and lead to subtle bugs.
Welcome to the beginning of the compiler proper! If you haven't yet, check out part 0 for a description of the project and help setting up the development environment. A note about the presentation structure: We will be going through each phase of the compiler mostly in its entirety before moving onto the next phase.