On Thu, Mar 18, 2010 at 5:17 PM, Michael Snoyman
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:
newtype AbsPath = AbsPath { unAbsPath :: String } newtype PathInfo = PathInfo { unPathInfo :: String }
Can you provide some simples examples of the types of mistakes we might make if we didn't use newtypes here? 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 a ! [href (showURL Foo)] Which is kind of nice. But I also like using newtypes when it helps avoid problems. handleWai :: (PathInfo -> Failing url)
-> (url -> PathInfo) -> (PathInfo -> AbsPath) -> (url -> (url -> AbsPath) -> Application) -> Application handleWai parsePI buildPI buildAbsPath dispatch req = do let pi = PathInfo $ S.unpack $ pathInfo req case parsePI pi of Success url -> dispatch url (buildAbsPath . buildPI) req Failure errors -> return $ Response Status404 [] $ Right $ fromLBS $ L.pack $ unlines errors
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: handleHappstack.. or some variant. And I can imagine other non-Wai people want to use urlt as well. So I imagine we will have: urlt-wai urlt-happstack etc 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 - jeremy