Post #2280787

2025-10-29 21:39 UTC

@sminez@hachyderm.io @cliffordheath@mastodon.social @robpike@hachyderm.io And perhaps with some cleverness you could support multiple top-level chains if you had the ability to know when every top-level chain completed one or more matches up to a given position in the stream, then proceed with processing those matches. The no overlapping matches restriction though is something I need to understand more. Perhaps that would simplify things? Or it's a symptom of the fact that the problem is really more complicated than I think...

Replies (1)

@sminez@hachyderm.io 2025-10-29 22:03

@oac@fosstodon.org @cliffordheath@mastodon.social @robpike@hachyderm.io the no overlapping matches part is so you can determine an ordering that you can apply the match actions in where applying the action for each match at most results in applying a delta to subsequent ones. If you allow overlap then depending on the nature of a previous action you can end up invalidating the behaviour of subsequent ones. Currently in my new implementation I'm storing matches and actions in a btree map as they are found, and then iterating over that map once all matches are found to apply the actions. In the streaming case I think you'd still need to do this when you have a parallel group but could switch to eager evaluation outside of that. With some smarter analysis in the compilation phase it shouldn't be too hard to chunk the program up into regions that do / don't support eager evaluation and then provide feedback to the user as to where they'll end up buffering input to process things.

Open ##2280788