Haskell でツリーを実装するための戦略があると聞いたことがありますが、適切な動作ツリーの代替案に関する情報は見つかりませんでした。
私の目標: 状態を表すタプルが与えられた場合、タプルに基づいてそれぞれがビジー/エラー/完了/実行を返す動作ノードのツリーにそのタプルを供給するための最良のパターンは何ですか. 動作はタプルを変更することもあります (状態の変更を引き起こします)。
ネストされたノードは、親ノードの戦略に基づいて実行できます。たとえば、子ノードが「エラー」を返した場合、それ以上の子ノードは評価されません。もう 1 つの戦略は、エラー状態が返された場合でも、すべての子ノードを実行することです。
これが理にかなっていることを願っています！
Unfortunately you seem to be an expert in a niche that very few Haskell users know much about. All I know about these technologies is what I have overheard from non-technical people talking about different business rules engines, so I'm probably off-base but I think it's worth a shot since everyone else is stumped.
As far as forward-chaining reasoning systems and the Rete algorithm in particular, they're basically functional already. They iterate and add more knowledge to the database as they go until they run out of things to do. Provided you don't allow arbitrary effects, it would be a simple Control.Monad.State port; if you need arbitrary effects you can use a state monad transformer instead, and it's not something intermediate/advanced Haskellers would be all that intimidated by. You may find something you can use on the Haskell site but if you wind up doing this yourself the Monad Transformers chapter of Real World Haskell is indispensable.
I don't know anything about behavior trees, but at a glance on Wikipedia they look to me like the Rete algorithm plus concurrent processes in the background. If that's even close to correct, then you have to decide whether or not you need concurrency or parallelism. If you're content with pure values "magically" being computed faster (and, by extension, everything being written in Haskell) then you can get away with using the stuff in Control.Parallel for not much effort but you won't be able to (say) inquire which processes are running and which are not. If you genuinely need different observable behavior, then you'll need Control.Concurrent and it's less magical, so more book-keeping. Simon Marlow wrote a pretty nice tutorial about your options there. What you're describing sounds lower-level to me than most of the cool stuff Haskell can do for you; if you decide to accept a higher-level interface you may find it easier to implement. I'm far from an expert on this topic either.
私たちは皆、あなたの質問に少し混乱しています。あなたが「タプル」と言ったときにあなたが何を意味するのか理解できないかもしれませんが、暗闇で撃ちました:
アクター モデルの同時実行を目的とした simple-actors という小さなライブラリを作成しました。「アクター」が並行「チャネル」でリッスンし、互いに通信することによって達成する必要があることを想像できる場合は、見てみることに興味があるかもしれません。
ここのドキュメントの上部には、アクターの一種のバイナリ検索ツリーの例があります (あなたの質問はそれを思い起こさせました。これがすべて的外れである場合は申し訳ありません)。
編集：ビヘイビアツリーのウィキペディアのページが完全に不可解であることがわかったことに言及する必要があります。おそらく、企業の専門用語に詳しい人が助けてくれるでしょう。