Opps, errors, it should be more like:<br><br>moveBall (Vector2 x y) (Ball ...) = ...<br>
movePaddle (Vector2 x y) (Paddle ...) = ...<br><br>-- selection actions for Ball<br>instance Actor Ball where<br>  mkActor this = let<br>    pos&#39; = getBallPosition this <br>    move&#39; v = mkActor $ moveBall v this <br>

    in Actor pos&#39; move&#39;<br>
<br>-- selection actions for Paddle     <br>instance Actor Paddle where<br>  mkActor this = let<br>    pos&#39; = getPaddlePosition this <br>    move&#39; v = mkActor $ movePaddle v this <br>    in Actor pos&#39; move&#39;<br>

<br><br>Hmm, I bet some generics, or template haskell could clean up the extra boilerplate associated with this technique.<br><br>- Job<br><br><br><div class="gmail_quote">On Thu, Oct 1, 2009 at 11:35 AM, Job Vranish <span dir="ltr">&lt;<a href="mailto:jvranish@gmail.com" target="_blank">jvranish@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Along the projection/co-algebra lines (I actually didn&#39;t know that&#39;s what they were called until today :)  yay for learning new things!)<br><br>How about something like this:<br><br>-- Define &quot;prototypes&quot; for your class of actions here<br>


data Actor = Actor {pos::Vector2 Float, move::Vector2 Float -&gt; Actor}<br><br>-- simple class that selects your actions based on type<br>class ActorClass a where<br>  mkActor :: a -&gt; Actor<br><br>-- object types<br>

data Ball = Ball ...  -- stuff<br>
data Paddle = Paddle ... -- stuff<br>data Wall = Wall ... -- suff<br><br>-- Functions for working with objects<br>getBallPosition (Ball ...) = ...<br>getPaddlePosition (Paddle ...) = ...<br><br>moveBall (Ball ...) = ...<br>


movePaddle (Ball ...) = ...<br><br>-- selection actions for Ball<br>instance Actor Ball where<br>  mkActor this = let<br>    pos&#39; = getBallPosition this <br>    move&#39; v = moveBall this <br>    in Actor pos&#39; move&#39;<br>


<br>-- selection actions for Paddle     <br>instance Actor Paddle where<br>  mkActor this = let<br>    pos&#39; = getPaddlePosition this <br>    move&#39; v = movePaddle this <br>    in Actor pos&#39; move&#39;<br><br><br>


Base off a technique I ran across here:<br><a href="http://www.mail-archive.com/haskell@haskell.org/msg04513.html" target="_blank">http://www.mail-archive.com/haskell@haskell.org/msg04513.html</a><br><br>Also, a useful wikipage for doing OO things in haskell:<br>


<a href="http://www.haskell.org/haskellwiki/OOP_vs_type_classes" target="_blank">http://www.haskell.org/haskellwiki/OOP_vs_type_classes</a><br><font color="#888888"><br>- Job<br><br><br></font><div class="gmail_quote"><div>

<div></div><div>On Thu, Oct 1, 2009 at 4:45 AM, Peter Verswyvelen <span dir="ltr">&lt;<a href="mailto:bugfact@gmail.com" target="_blank">bugfact@gmail.com</a>&gt;</span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div>I&#39;m not sure if I understand what you mean with this co-algebraic approach, but I guess you mean that functions - like move - don&#39;t work directly on any datatype; you need to provide other functions that give access to the data. But that&#39;s basically what type classes do no? And that&#39;s also related to my earlier post of &quot;strong duck typing&quot; in Haskell. <div>



<div><br></div><div>At least also in C#, that&#39;s the way I usually write code that works on any type, just make an interface or pass in a delegate.  I also know that my OO background keeps pushing me in the wrong direction when it comes to Haskell ;-) </div>



<div><br></div><div><div><div><div>The collision handling approach is always interesting :)  In OO this is usually solved using multi-methods or visitors: <a href="http://en.wikipedia.org/wiki/Multiple_dispatch" target="_blank">http://en.wikipedia.org/wiki/Multiple_dispatch</a>. What I usually did in old games of mine to handle collisions is not look at the type, but at the &quot;collision specific features&quot; of a type (which are again functions that extract information from the object), and that is most likely again the co-algebraic approach?</div>


<div><div></div><div>
<div><br></div><div><div><div class="gmail_quote">On Wed, Sep 30, 2009 at 9:15 PM, Luke Palmer <span dir="ltr">&lt;<a href="mailto:lrpalmer@gmail.com" target="_blank">lrpalmer@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">



<div>On Wed, Sep 30, 2009 at 9:54 AM, Peter Verswyvelen &lt;<a href="mailto:bugfact@gmail.com" target="_blank">bugfact@gmail.com</a>&gt; wrote:<br>
</div><div>&gt; I guess this is related to the expression problem.<br>
&gt; Suppose I have a datatype<br>
&gt; data Actor = Ball ... | Paddle ... | Wall ...<br>
&gt; and a function<br>
&gt; move (Ball ...) =<br>
&gt; move (Paddle ...) =<br>
&gt; move (Wall ...) =<br>
&gt; in Haskell one must put Actor and move into a single file.<br>
&gt; This is rather cumbersome if you work with multiple people or want to keep<br>
&gt; the files small and readable.<br>
&gt; Surely it is possible to use type classes, existentials, etc to split the<br>
&gt; data type into multiple ones, but that&#39;s already advanced stuff in a sense.<br>
<br>
</div>You can do it without type classes and existentials.  The<br>
functionality you want is already supported by Haskell, you just have<br>
to let go of your syntactical expectations.  The trick is that you<br>
should rewrite your data type not as an algebra (a set of<br>
constructors), but as a coalgebra (a set of projections).<br>
<br>
Let&#39;s say your two open functions are:<br>
<br>
move :: Actor -&gt; Actor<br>
isAlive :: Actor -&gt; Bool<br>
<br>
This gives rise to the definition of an Actor type:<br>
<br>
data Actor = Actor { move :: Actor, isAlive :: Bool }<br>
<br>
And then the alternatives of your open data type are just values of type Actor:<br>
<br>
ball :: Vector -&gt; Vector -&gt; Actor<br>
ball pos vel = Actor {<br>
    move = ball (pos + vel) vel,<br>
    isAlive = True<br>
  }<br>
<br>
etc.<br>
<br>
This trick works well until you get to the encoding of functions that<br>
pattern match on multiple Actors at the same time.  As far as I can<br>
tell, that cannot be encoded in this style in any reasonable way.<br>
Such functions must be rephrased in a coalgebraic style; i.e. instead<br>
of asking about constructors, using projection functions it knows are<br>
available.<br>
<br>
So for example instead of implementing &quot;collide&quot; by asking about<br>
pairs, add functions which report a shape function and a normal, or<br>
whatever your collide algorithm needs from shapes.<br>
<br>
You would probably end up having to do this anyway even with your<br>
proposed extension, because watch:<br>
<br>
partial data Actor = Ball ...<br>
<br>
collide (Ball ...) (Ball ...) = ...<br>
collide (Ball ...) x = ...<br>
<br>
We don&#39;t know about any other constructors, so the second line has to<br>
contain a pattern-free x.  So you would have to use projection<br>
functions to get any information about it, exactly as you would when<br>
you&#39;re writing in the coalgebraic style.<br>
<br>
So, Yes!  Haskell can do that!<br>
<font color="#888888"><br>
Luke<br>
</font></blockquote></div><br></div></div></div></div></div></div></div></div>
<br></div></div><div>_______________________________________________<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>
<br></div></blockquote></div><br>
</blockquote></div><br>