On targeting multiple language environments, and extracting maximum performance from each.
Bloom is a specification language, not meant for adhoc queries. Many of the techniques for datalog and db optimization do not apply to Bloom. We can go the distance in static analysis and type-driven optimization.
Tuples must be records with named fields, not arrays. In a static language with machine-primitive types, array-oriented tuples force primitive types to be boxed, which is horrible overhead. Also, tuples don't belong to a language for disorderly programming: array-oriented tuples are not self-explanatory, and make schema evolution painful. From now on, I'll use the term record instead of tuple, to avoid any expectation of positional indexing.
Specialized code and types preferred to a library-driven approach. In other words, instead of having generic Record, Table and Index types, there is merit in creating custom implementations for each, for a given Bloom program.
- Consider a collection with s