#+ARCHIVE: ::* Archived
* Backlog
** Static HTML5 constructors :el:
<2021-06-14 Mon>
Currently, the =h= Proxy object dynamically generates elements via expressions like =h.div=. It was previously the even noisier =$el=.
Instead, we should populate an =html5.mjs= or similar with =DIV=, =P=, etc. These could be imported via =import * from ...=. Since they're capitalized, they're unlikely to conflict with identifiers in client code. A prefix could still be employed by importing with =import * as H...= or similar.
** Aggregation :datalog:
<2021-06-14 Mon>
We should support at least =min=, =max=, and =count= aggregates [[https://docs.datomic.com/cloud/query/query-data-reference.html#aggregates][a la Datomic]].
** Specify ANY.VALUE semantics :datalog:
<2021-06-14 Mon>
=ANY.VALUE= is a valid query parameter value that allows disjunction to be performed without modification of the query "template" (={find: ...}=). Our hope is that dynamic parameters are sufficient, because allowing query templates to participate in =input= and =formula= would require value semantics to be imposed on templates. This is at odds with the overall goal of avoiding imposing value semantics on JS structures other than sets of tuples. Static queries also means that views will always get the same length tuples from view sources.
*** Simple Tuple Pattern
When a logic variable from the =use:= clause is bound to =ANY.VALUE= and appears in a =where:= clause such as =[1,2,_.x]= and the tuple =[1,2,3]= exists in the set, the tuple =[1,2,3]= will appear in the result set as if =_.x= was =_._=.
However, =_.x= is never bound to a value from the result set, and so when =ANY.VALUE= is used, parameter variables may not appear in the =find:= clause. Because consumers of the query presumably already have access to the variables they populated, it's not clear it makes sense for this to work. On the other hand, the fewer special cases around =ANY.VALUE=, the better?
*** Predicates
If a variable bound to =ANY.VALUE= appears in a predicate, the logic variable is stripped from the predicate tuple before the predicate is applied. For example, the predicate =['<',_.a,_.b]= is effectively =['<',_.a]= when =_.b= is bound to =ANY.VALUE=.
** elem constructor :el:
<2021-06-14 Mon>
While =h= parses argument lists as attributes and children, user-defined elements are created with functions, and parsing support is not provided.
Instead of defining an element like this:
#+BEGIN_SRC javascript
function myCustom(x, y) {
}
#+END_SRC
Elements could be defined like this:
#+BEGIN_SRC javascript
let myCustom = elem((attrs, kids) => {
});
#+END_SRC
In this way, components could easily be written that support cell-valued attribute objects like native elements. This functionality mirrors [[https://hoplon.github.io/hoplon/hoplon.core.html#var-defelem][Hoplon's defelem]].
** Support user-defined predicate functions :datalog:
<2021-06-14 Mon>
** Support user-defined aggregation functions :datalog:
<2021-06-14 Mon>
** API documentation :docs:
<2021-06-14 Mon>
* Archived