<br><br><div class="gmail_quote">On Fri, Mar 19, 2010 at 2:31 PM, Jeremy Shaw <span dir="ltr"><<a href="mailto:jeremy@n-heptane.com">jeremy@n-heptane.com</a>></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 Thu, Mar 18, 2010 at 5:17 PM, Michael Snoyman <span dir="ltr"><<a href="mailto:michael@snoyman.com" target="_blank">michael@snoyman.com</a>></span> wrote:<br></div><div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div>Based on everything you've said, and some thought I've had on my own, I agree that the base function should involve no typeclasses and not break up the path into pieces. Here's a proposal for the entire core:</div>
<div><br></div><div><div>newtype AbsPath = AbsPath { unAbsPath :: String }</div><div>newtype PathInfo = PathInfo { unPathInfo :: String }</div><div></div></div></div></blockquote><div><br></div></div><div>Can you provide some simples examples of the types of mistakes we might make if we didn't use newtypes here?</div>
<div><br></div><div>One potentially nice thing about having the function, showURL :: (url -> String) instead of (url -> AbsPath) is that it works with most of the html 'templating' solutions with out any extra fusing around. For example, with Text.Html</div>
<div><br></div><div> a ! [href (showURL Foo)] </div><div> </div><div>Which is kind of nice. </div><div><br></div><div>But I also like using newtypes when it helps avoid problems.</div><div class="im"><div><br></div><div>
<br></div></div></div></blockquote><div>I think I've said it before: I'm on the fence about this one. The newtypes are just doing what they usually do: prevent you from making silly mistakes and ensure more type safety. I have no incredibly persuasive examples.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div class="im"><div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div><div>handleWai :: (PathInfo -> Failing url)</div><div> -> (url -> PathInfo)</div>
<div> -> (PathInfo -> AbsPath)</div><div> -> (url -> (url -> AbsPath) -> Application)</div><div> -> Application</div><div>handleWai parsePI buildPI buildAbsPath dispatch req = do</div>
<div> let pi = PathInfo $ S.unpack $ pathInfo req</div><div> case parsePI pi of</div><div> Success url -> dispatch url (buildAbsPath . buildPI) req</div><div> Failure errors -> return $ Response Status404 [] $ Right $ fromLBS</div>
<div> $ L.pack $ unlines errors</div></div></div></blockquote><div><br></div></div><div>Depends on which 'core' we are talking about. I still intend to use urlt with happstack, which does not yet have fully integration with Wai. So I will need:</div>
<div><br></div><div>handleHappstack.. or some variant. And I can imagine other non-Wai people want to use urlt as well. So I imagine we will have:</div><div><br></div><div>urlt-wai</div><div>urlt-happstack</div><div>etc</div>
<div><br></div><div>so at the real core that would just leave, PathInfo and AbsPath ? Unless we get rid of them.. then there is nothing at the core, only optional things :p</div><div><br></div><font color="#888888"><div>
<font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#888888"><br></font></font></div></font></div></blockquote><div>If all we're aiming for here is a method for type-safe URLs, then this would work. I'm trying to broaden the scope to including pluggable web pieces; for this, a unified request/response type are a must.</div>
<div><br></div><div>That said, we *could* make the Application type be polymorphic and then provide handleWai, handleCgi, handleHappstack, etc, and then have plugins specific for each of those systems. But I'd rather see us standardize on WAI (that is the purpose of it) and provide compatibility wrappers.</div>
<div><br></div><div>Michael</div></div>