Post #2280788

@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.