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