<div dir="ltr"><div>Francesco, using existentials looks promising! I'll work on it.</div><div><br></div><div>Perhaps people owning hamsters is more easily represented with maps, at least in an economy in which every hamster has exactly one owner. Here is a nearly identical example that surely requires a graph:</div><div><br></div><div><font face="monospace, monospace"> data GraphNode = Person String | Hamster String</font></div><div><font face="monospace, monospace"> data GraphEdge = Owns -- people own hamsters</font></div><div><font face="monospace, monospace"> | Friend -- any two GraphNodes can be friends</font></div><div><br></div><div>If you used maps for this kind of information, you would have a lot of copies of the same thing. If you changed someone's name, you would have to search through each map to find every instance of it. In a graph, by contrast, you would just change it in the one place that it is represented. Moreover, with maps there's the risk of indicating someone owns a hamster that does not exist. You have to keep some kind of master record of which hamsters are available, and check each map against it. In a graph, a hamster that does not exist is not represented, and so cannot be linked to.</div><div><br></div><div>Bryan Richter wrote; </div><div><br></div><div>> Maybe this?</div><div>></div><div>> data GraphNode = NodePerson Person | NodeHamster Hamster</div><div><br></div><div>That's what I was already doing! I feel validated.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 19, 2016 at 6:18 AM, Tom Ellis <span dir="ltr"><<a href="mailto:tom-lists-haskell-cafe-2013@jaguarpaw.co.uk" target="_blank">tom-lists-haskell-cafe-2013@jaguarpaw.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Feb 19, 2016 at 05:06:57PM +0300, Kosyrev Serge wrote:<br>
> Tom Ellis <<a href="mailto:tom-lists-haskell-cafe-2013@jaguarpaw.co.uk">tom-lists-haskell-cafe-2013@jaguarpaw.co.uk</a>> writes:<br>
> > On Fri, Feb 19, 2016 at 03:07:59PM +0300, Kosyrev Serge wrote:<br>
> >> Tom Ellis <<a href="mailto:tom-lists-haskell-cafe-2013@jaguarpaw.co.uk">tom-lists-haskell-cafe-2013@jaguarpaw.co.uk</a>> writes:<br>
> >> > I agree. FGL seems inappropriate to model people owning hamsters because<br>
> >> > you genuinely want to reflect the difference between people and hamsters by<br>
> >> > having two different node types.<br>
> >><br>
> >> What would you propose instead?<br>
> ><br>
> > If I were utterly insane I would propose that FGL be extended with<br>
> > higher-typed indexes, so instead of<br>
> ><br>
> > Gr :: * -> * -> *<br>
> ><br>
> > we would have<br>
> ><br>
> > Gr :: (k -> *) -> (k -> k -> *) -> *<br>
> ><br>
> > Then Hamster and Person would be the only inhabitants of some kind k, and<br>
> > you can could choose two different types to represent them, and four<br>
> > different types to represent the (directed) edges between them.<br>
><br>
> Richard, is something like this possible with what is in GHC 8?<br>
><br>
> Or would DataKinds already be sufficient for this?<br>
<br>
</span>GADTs and DataKinds already suffice for this. Programming like this is<br>
possible but not especially syntactically convenient, and FGL would have to<br>
be changed throughout, of course.<br>
<br>
(Thanks to Andras Kovacs for introducing me to this lovely world of<br>
higher-kinded indexed types)<br>
<span class="HOEnZb"><font color="#888888"><br>
Tom<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Jeffrey Benjamin Brown</div></div>
</div>