Passing DBs through continuations
remy.wang
remy.wang
Not sure what the AI one gives you at a personal level.
As far as I'm concerned, it's all just Luddites v2.0.
> "Suppose you want to write a database. You'd probably start by implementing relational algebra operators — projection, filter, join, etc. The easy way is to implement them as functions that take in tables and return tables, and assemble them into a larger expression. That was how Prela worked in its first incarnation. The code was clean, but it was hella slow! Which was not surprising, because every operator materialized every intermediate result. "
DB development starts with the storage engine, file manager, buffer pool (page cache), and page access methods (heaps/indices) which are binary buffer views. Then, you add the transaction manager, the WAL/recovery bits.
The actual implementation of relational algebra and a SQL language + parsing are little icing layers on top of a transactional storage engine.
Transducers are specialized to data transformation pipelines, continuations are a form of control flow from which you can derive a lot of cool things (exceptions, time travel debugging etc).
Transducers are just the morphisms in the category of the reducing-functions. No problem!
A better analogy is that continuations are reified function call return addresses, since return addresses come with a frame pointer (explicit or implicit), and therefore are closure-like.
A continuation is a value that's passed to a function to tell it where to send its result when it's complete.
In imperative programming languages which invariably have restricted function calls, the continuation that every function receives is the address following the function call. This was just a mistake which the earliest programming languages committed, which has been perpetuated ever since, except in functional languages.