Yes, for my first example, the kind is wrong. I knew it, I just wrote it &quot;to show&quot;, not to be correct Haskell, sorry.<br><br>@Antoine: Well, yes, internally, I think this is how it will be implemented. What I wondered was if arrows would provide a nice interface to it.<br>

<br>@Stephen: Resumption monads? It looks interesting, but I fait to see which paper is about it...<br><br><br><div class="gmail_quote">2011/5/28 Chuzzle Guevero <span dir="ltr">&lt;<a href="mailto:headprogrammingczar@gmail.com">headprogrammingczar@gmail.com</a>&gt;</span><br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">For one, you have a kind error. You use Mission as a Monad when it only has kind *. I don&#39;t know much of arrows, but I suggest writing the combinators you want to have with specialized types, and see where that takes you. If it happens to lead to an implementation of Arrow, yay. If it doesn&#39;t, then you at least still have something that functions.<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Message: 13<br>
Date: Fri, 27 May 2011 21:06:10 +0200<br>
From: Yves Par?s&lt;<a href="mailto:limestrael@gmail.com" target="_blank">limestrael@gmail.com</a>&gt;<br>
Subject: [Haskell-cafe] State Machine and the Abstractions<br>
To: Haskell-Cafe&lt;<a href="mailto:haskell-cafe@haskell.org" target="_blank">haskell-cafe@haskell.org</a>&gt;<br>
Message-ID:&lt;BANLkTikVb-zhyTVR=<a href="mailto:jT03hFiBAKrERxsLQ@mail.gmail.com" target="_blank">jT03hFiBAKrERxsLQ@mail.gmail.com</a>&gt;<br>
Content-Type: text/plain; charset=&quot;iso-8859-1&quot;<div><div></div><div class="h5"><br>
<br>
Hello,<br>
<br>
For the purposes of a simple strategy game, I&#39;d like to build an EDSL that<br>
expresses missions. A mission could be represented as a state machine.<br>
With basic bricks such as actions (MoveTo, ShootAt...) or tests<br>
(EnemiesAround, LowHealth...), I could (ideally dynamically) build some<br>
strategic behaviors for the units.<br>
I will take the example of a patrol. Applied to a unit (or a group of<br>
units), it dictates : go from point 1 to point 2 and then go back and<br>
repeat. But when you detect an enemy near, leave the patrol path, destroy it<br>
and then resume your patrol where you left it.<br>
<br>
So if I consider my mission as a monad:<br>
data Mission = MoveTo Point | ShootAt Unit<br>
<br>
patrol = do<br>
     MoveTo point1<br>
     MoveTo point2<br>
     patrol<br>
<br>
So far so good, but there, the only advantage to use a monad instead of a<br>
list of MoveTo&#39;s is the do-notation.<br>
And I lack the expression of tests. Using a GADT it could be:<br>
<br>
data Mission a where<br>
     MoveTo :: Point -&gt;  Mission ()<br>
     ShootAt :: Unit -&gt;  Mission Bool  -- If we have destroyed it or not<br>
     EnemiesAround :: Mission [Unit]  -- The enemies that are maybe in sight<br>
     LowHealth :: Mission Bool -- If I should retreat<br>
     ...<br>
<br>
-- (Monad Mission could be nicely expressed using Heinrich Apfelmus&#39; *<br>
operational* package)<br>
<br>
patrol = do<br>
     MoveTo point1<br>
     MoveTo point2<br>
     enemies&lt;- EnemiesAround<br>
     mapM_ ShootAt enemies<br>
     patrol<br>
<br>
Aaaaaaaand... here comes the trouble: the actions are done *sequentially*.<br>
My units will move and then look at enemies, they will not monitor their<br>
environment while they move.<br>
So I need a way to say: A is your action of patrolling. B is your action of<br>
surveillance. Do both in parallel, but B is preponderant, as if it successes<br>
(if enemies are there) it takes over A. So, it is as if I was running two<br>
state machines in parallel.<br>
Moreover, the last line (the recursive call to patrol) is wrong, as it will<br>
restart the patrol from the beginning, and not from where it has been left.<br>
But this could be corrected by addind a test like &quot;which point is the<br>
closest&quot;.<br>
<br></div></div><div class="im">
So I thought about Arrows, as they can express sequential and parallel<br>
actions, but I don&#39;t know if it would be a right way to model the<br>
interruptions/recoveries.<br>
What do you think about it? Do you know of similar situations and of the way<br>
they&#39;ve been solved?<br>
</div></blockquote>
<br><div><div></div><div class="h5">
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br>