@scalexm I spent some time this morning organizing a dropbox paper with a kind of "brain dump" of all the things that I think chalk specifically needs. It's probably not complete and some items continue to need elaboration. Feel free to add more items or comments.

but trying to setup the crates from chalk#214, it seems like a number of those details become relevant precisely around this "give me the program clauses for the goal X" callback

and...that is probably a good thing?

that said, maybe we should talk through the doc a bit systematically? One of the things I was curious to start with was the set of goals I outlined. I am particularly interested in trying to get more specific about what it means to validate the chalk approach -- i.e., what things are we worried about?

I should push it somewhere but the tl;dr was that I was messed about with lambda prolog

there are really just a few rules, basically

I think I had a relation like lower(HHRC, RC) where the input was the hereditary harrop region constraint (HHRC) and the output was a list of flat constraints RC; this would of course have multiple solutions sometimes

but that's another story

I feel like that would have to be a data-driven effort

once we have the smart predicate order selection, we may be able to replace the artificial ambiguity hack in program_clauses_for for ?T: Sized goals with just a CannotProve result, right? Because these goals will actually never be hit with ?T unresolved, unless the goal is indeed totally unconstrained

that then infects R

but if we had started first with R, it would be ok

the goal of the "bubble up" option I was proposing was that we wouldn't propagate a do-not-prove result, but more like a conditional answer (which is what a "delayed goal" is, really, but also a region constraint)