On Fri, Mar 26, 2010 at 5:13 PM, Michael Snoyman <span dir="ltr">&lt;<a href="mailto:michael@snoyman.com">michael@snoyman.com</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>Can you give me any real-world examples where you would have URL routes built up like that? It seems like this is an optimization for the abnormal case.</blockquote><div><br></div><div>I am not sure I would consider it an &#39;optimization&#39; -- with out this change the desired  behavior can not be expressed as far as I can tell.</div>
<div><br></div><div>Off the top of my head, I have the following type in my image gallery library:</div><div><br></div><div><div>data GalleryCommon </div><div>    = ViewImage ImageId [Transform]</div><div>      deriving (Eq, Ord, Show, Read, Data, Typeable)</div>
<div><br></div><div>The ImageId and Transform properties are used in other url components (not shown here). They have PathInfo instances already.</div><div><br></div><div>The Template Haskell or Regular libraries would generate a parser that looks a bit like:</div>
<div><br></div><div>fromPathSegments = (string &quot;ViewImage&quot; *&gt; ViewImage) &lt;$&gt; fromPathSegments &lt;*&gt; fromPathSegments</div><div><br></div><div>Without the changes to the type, the TH code would not be able to reuse the existing PathInfo ImageId instance, but would instead be forced to handle the ImageId argument explicitly.. That is really unfortunate, because the path generated by the PathInfo ImageId instance is much cleaner than what TH would generate.</div>
<div><br></div><div>It seems to me that the primary purpose of the PathInfo class is to allow you to build composable parsers / generates for urls. It seems odd to limit the composableness to only the last argument of a constructor..</div>
<div><br></div><div>- jeremy</div></div></div>