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">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><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">lrpalmer@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Wed, Sep 30, 2009 at 9:54 AM, Peter Verswyvelen &lt;<a href="mailto:bugfact@gmail.com">bugfact@gmail.com</a>&gt; wrote:<br>
</div><div class="im">&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>