Calling run() multiple times about ascent HOT 6 OPEN

Great observations.

• add some support for incrmentalized computation, so that you could indicate 'I've added facts to this relation' and 'I've removed facts from this relation', causing some of the indices to be recomputed?

This is what is done now. Ascent conservatively assumes that all relations may have changed, and recomputes all indices for the program. Here, it seems that this recomputing of indices is very expensive for some reason. This is something that can potentially be addressed. Although I'd have to think about its ramifications for BYODS.

• prevent the user from calling .run() multiple times, by making run take ownership of the program instead of taking it by mutable reference.

This is also a possibility. But I prefer the other option.

from ascent.

@s-arash thanks.
But there isn't only a performance issue.
At least in my last example, where input facts are removed, the result isn't consistent after calling run at the second time.

from ascent.

I have yet to run into a case where calling run() multiple times does not cause a subsequent geometric increase in eval time, even when the row counts don't actually change.

My programs are large but not super complex, and I don't think I'm doing anything too off the beaten path (using enum instances for values).

My solution for now is to manage caches myself and break things down into multiple one-off ascent_run! calls.

from ascent.

At least in my last example, where input facts are removed, the result isn't consistent after calling run at the second time.

Right, I can't think of a good way to prevent removing facts from relations. Even replacing the Vec<T> type for relations with an append-only vec type will not prevent removing facts.

I have yet to run into a case where calling run() multiple times does not cause a subsequent geometric increase in eval time.

Ascent wasn't really designed for incremental processing of data.

I can just disallow calling run() multiple times. But I feel like it may prevent a few legitimate use cases.

I have purposefully not hidden the internals of Ascent's relations and indices so they can be tinkered with by those who know what they are doing.

from ascent.

@s-arash
I think if there is one way (calling once) that is the normal and designed for use of the API, and one that is more for power users who really know what they are doing, it may make sense to separate them, like:

fn run(self) -> ResultSet 

(where ResultSet provides the contents of the relations after run, and the indices, but can't be used to run again)

and

/// Runs the program and allows it to be run later. Runs in general are not incremental, and may take longer time than rerunning from scratch, or may fail to account for facts manually removed from the input relation after the first run.
fn run_and_keep(&mut self)

Alternatively, there could be some switch attribute on the macro itself, which would generate the fields by default as private, with appropriate getters (handing out shared references), but would allow advanced users to request an 'exposed internals' ascent program.

from ascent.

I think mod/rerun will require add provenance (like add fact/remove fact) semantic.
for example in query

edge(1,2).
path(a, b) :- edge(a, b).

changing edge (like remove edge(1,2)) will cause datalog rule not holds logically (some path(1,2), can't be inferred).
with some semantic support like semi-ring should help with incremental computation.

from ascent.