Merge in work on typed fns

.gitignore

@@ -40,3 +40,6 @@ pom.xml.asc
 .lein-repl-history
 
 *.class
+*.extract-native-dependencies
+*.swp
+*.swo

circle.yml

@@ -16,8 +16,8 @@ dependencies:
     - sudo apt-get update
     # Shouldn't use `ppa:ubuntu-toolchain-r/test` : http://askubuntu.com/questions/777803/apt-relocation-error-version-glibcxx-3-4-21-not-defined-in-file-libstdc-so-6
     # install the g++ version OpenCL needs
-    - wget -c http://security.ubuntu.com/ubuntu/pool/main/g/gcc-5/gcc-5-base_5.4.0-6ubuntu1~16.04.4_amd64.deb && sudo dpkg -i gcc-5-base_5.4.0-6ubuntu1~16.04.4_amd64.deb && rm gcc-5-base_5.4.0-6ubuntu1~16.04.4_amd64.deb
-    - wget -c http://security.ubuntu.com/ubuntu/pool/main/g/gcc-5/libstdc++6_5.4.0-6ubuntu1~16.04.4_amd64.deb && sudo dpkg -i libstdc++6_5.4.0-6ubuntu1~16.04.4_amd64.deb && rm libstdc++6_5.4.0-6ubuntu1~16.04.4_amd64.deb
+    - wget -c http://security.ubuntu.com/ubuntu/pool/main/g/gcc-5/gcc-5-base_5.4.0-6ubuntu1~16.04.9_amd64.deb && sudo dpkg -i gcc-5-base_5.4.0-6ubuntu1~16.04.9_amd64.deb && rm gcc-5-base_5.4.0-6ubuntu1~16.04.9_amd64.deb
+    - wget -c http://security.ubuntu.com/ubuntu/pool/main/g/gcc-5/libstdc++6_5.4.0-6ubuntu1~16.04.9_amd64.deb && sudo dpkg -i libstdc++6_5.4.0-6ubuntu1~16.04.9_amd64.deb && rm libstdc++6_5.4.0-6ubuntu1~16.04.9_amd64.deb
     - sudo printf '\nLD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/:$LD_LIBRARY_PATH\n' >> /home/ubuntu/.bashrc
     - strings /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep CXXABI_1.3.8 # version required by OpenCL; fail-fast
     # various necessary utils

doc/cljc/quantum/_performance.md

@@ -2,6 +2,7 @@
 
 https://github.com/druid-io/druid/issues/3892 (Move from `ByteBuffer` to `Memory`)
 - Yahoo's `Memory` submodule of `DataSketches` is faster than `ByteBuffer` (!)
+  - https://github.com/DataSketches/memory/tree/master/src/main/java/com/yahoo/memory
 
 ## quantum.net.http
 

doc/cljc/quantum/core/defnt.md

@@ -40,7 +40,7 @@ public class NumberLessThan7 {
   public final Number x;
 
   public NumberLessThan7 (Number x_) {
-    if (lessThan(x_, 7)) {// imagine here a `lessThan` function that worked on any two numbers
+    if (lessThan(x_, 7)) {// imagine here a `lessThan` function that worked on any two `Number`s
       x = x_;
     } else {
       throw new Exception("Number must be less than 7");
@@ -228,3 +228,55 @@ Output constraints:
 
 Unlike most static languages, a `nil` value is not considered as having a type
 except that of nil.
+
+## Why type inference is not a great idea
+
+Take the below code:
+
+```clojure
+(defnt transduce
+  ([      f ?,         xs ?] (transduce identity f     xs))
+  ([xf ?, f ?,         xs ?] (transduce xf       f (f) xs))
+  ([xf ?, f ?, init ?, xs ?]
+    (let [f' (xf f)] (f' (reduce f' init xs)))))
+```
+
+- For the `f` in the 1-arity overload:
+  - Inferred from `(transduce identity f xs)`
+  - The `f` in the 3-arity overload is then inferred:
+    - We know that `xf` can be called on `f`, so `xf` must be at least a 1-arity `t/callable?` on `f`
+    - We know that `f'` can be called on `(reduce f' init xs)`, so `xf` must be at least a 1-arity `t/callable?` on `f`
+    - Other than that we don't really have any information about `f`
+- For the `f` in the 2-arity overload:
+  - We know that `f` can be called with no arguments, so it must be at least a 0-arity `t/callable?`
+  - We know that it can be passed to `(transduce xf f (f) xs)`
+  - We tried to infer the `f` in the 3-arity but it can't be known
+
+It is infeasible to do inferences in the general case for the following reasons:
+- The code will be complex and greatly increase time it takes to get any value out of `defnt`
+- The code will likely have high computational complexity even if some impressive algorithm comes out of it
+- **Even if the code could do it instantly, it would still be a maintenance issue to try to mentally work out for each inference what that ends up being. Labels help quite a lot.**
+
+I think the best approach is not inference, but rather being able to at least do:
+- Input/output specs that rely on the input/output specs of other spec'ed fns
+- Conditional specs
+
+Thus the code turns into:
+
+```clojure
+(def rf? "Reducing function"
+  (t/fn [      {:doc "seed arity"}]
+        [:_    {:doc "completing arity"}]
+        [:_ :_ {:doc "reducing arity"}]))
+
+(def xf? "Transforming function"
+  (t/fn [rf? :> rf?]))
+
+(defnt transduce
+  ([        f rf?,        xs t/reducible?] (transduce identity f     xs))
+  ([xf xf?, f rf?,        xs t/reducible?] (transduce xf       f (f) xs))
+  ([xf xf?, f rf?, init _ xs t/reducible?]
+    (let [f' (xf f)] (f' (reduce f' init xs)))))
+```
+
+which is much, much nicer because it's much better documented, much more clear what each input and output does, and just overall much easier to follow and reason about, without introducing a meaningful increase in code size, and certainly without adding unnecessary information.

doc/naming.md

@@ -3,13 +3,18 @@
 ## Symbols
 
 - `->`+         : constructor
-                : 'convert to'
-- +`->`         : 'convert from'
+                : 'convert to' ; TODO phase out
+; `>`+          : 'convert to'
+- +`->`         : 'convert from' ; TODO phase out
+- +`>`          : 'convert from'
+- <A>`=>`<B>    : map from <A> to <B> ; TODO phase out
+- <A>`->`<B>    : map from <A> to <B>
 - `<`+          : calculate/compute (of functions) — as if to "take off the chan" of computed vals
-- <A>`:`<B>     : specificity relationship; <A> of type <B>
+- <A>`:`<B>     : specificity relationship; <A> of type <B> ; TODO phase out
+- <A>`|`<B>     : specificity relationship; <A> of type <B>
 - +`?`          : predicate
 - `?`+          : 'maybe' — if null, return null, otherwise do something
-- +`*`          : 'variant' — as ambiguous as it sounds
+- +`*`          : 'variant' — as ambiguous as it sounds ; TODO phase out
                 : 'relaxed' — in the context of numerics
 - +`'`          : 'strict' — esp. if numeric
                 : 'prime'/'next'

doc/voltdb.sql

@@ -0,0 +1,87 @@
+-- ~/voltdb-community-8.3.3/bin/voltdb start --http=8081
+-- ./bin/voltdb/sqlcmd
+
+-- TODO performance-test this against Datomic! Generate a bunch of random data till it gets big
+
+drop table entities;
+
+-- TODO add a `tinyint` column for datatype for more efficient indexing
+create table entities (
+-- time (transaction ID/instant; must be increasing; can be in nanos)
+-- first for display purposes
+t bigint not null,
+-- entity ID
+e bigint not null,
+-- attribute
+a varchar(128) not null,
+-- value (serialized)
+-- TODO change back to varbinary; just varchar for interactive testing
+v varchar
+);
+
+-- technically true as you should never assert the same thing in the same transaction
+-- create unique index eavt on entities (e, a, v, t)
+
+-- Idea from https://docs.datomic.com/on-prem/indexes.html
+-- TODO only index non- byte arrays
+create index eavt on entities (e, a, v, t);
+create index aevt on entities (a, e, v, t);
+create index avet on entities (a, v, e, t);
+create index vaet on entities (v, a, e, t);
+
+-- This is in order to do time-based iteration
+create index t on entities (t);
+
+-- TODO is this wise? It seems the best partitioning but might not be
+partition table entities on column e;
+
+-- Multiple insert in one clause is not supported
+insert into entities (t, e, a, v) values (0, -9223372036854775807, 'db|attribute'        , 'db|attribute');
+insert into entities (t, e, a, v) values (0, -9223372036854775807, 'db|doc'              , 'Marker for an attribute name');
+insert into entities (t, e, a, v) values (0, -9223372036854775806, 'db|attribute'        , 'db|doc');
+insert into entities (t, e, a, v) values (0, -9223372036854775806, 'db|doc'              , 'Attribute whose value supplies documentation');
+insert into entities (t, e, a, v) values (0, -9223372036854775805, 'db|attribute'        , 'my|attribute');
+insert into entities (t, e, a, v) values (0, -9223372036854775805, 'db|doc'              , 'Documentation for my attribute');
+
+insert into entities (t, e, a, v) values (1, -9223372036854775804, 'my|attribute'        , 'A value for my attribute. Yay!');
+
+insert into entities (t, e, a, v) values (2, -9223372036854775803, 'db|attribute'        , 'my|indexed-attribute');
+
+-- Be careful to sanitize the names — shouldn't include `hash` in the name unless intentional
+create index my_BAR_indexed_attribute__evt on entities (e, v, t) where a = 'db|attribute';
+create index my_BAR_indexed_attribute__vet on entities (v, e, t) where a = 'db|attribute';
+
+insert into entities (t, e, a, v) values (3, -9223372036854775803, 'my|indexed-attribute', 'A value for my indexed attribute. Woohoo!');
+
+-- next entity ID
+select max(e) + 1 from entities;
+
+-- (BigInteger. (.getBytes "my-value!!")) -> "my-value!!"
+-- (String. (.toByteArray (BigInteger. "516973278578607596577057"))) -> "my-value!!"
+
+-- Having a view of the DB at a point in time really is as trivial as `where t <= my_timestamp`
+
+
+
+-- [:find (count ?customer) . :in $ ?organization :where
+--  [?concert :concert/organization ?organization]
+--  [?booking :booking/concert ?concert]
+--  [?booking :booking/customer ?customer]]--
+
+-- TODO make sure revisions (changes in value of an identity across time) are addressed here
+select customer.e
+  from s as concert,
+       entities as booking,
+       entities as customer
+  where (    concert.a = "concert/organization"
+         and concert.v = "the-organization")
+     or (    booking.a = "booking/concert"
+         and booking.v = concert.e)
+     or (    booking.a = "booking/customer"
+         and booking.v = customer.e);
+
+-- This is probably as much effort as the type system. I think we should do it only when we start to
+-- scale, and only if it proves to have performance gains that Datomic can't match. We should code
+-- to the Datomic interface though. Plus if we preserve all the data in datom format, it's about the
+-- easiest thing to migrate (in theory). Perhaps we should do it either way — having source code we
+-- can configure and edit will be really helpful.