Am Mittwoch 16 Dezember 2009 15:12:31 schrieb Colin Paul Adams:
I tried it. I'm not all that happy with the resulting uncameling.
For instance,
Database.HaskellDB.Sql.PostgreSQL
goes to
Database.Haskell_dB.Sql.Postgre_sQL
which is uglier than before.
Oy. Didn't think of that. If you can live with Database.Haskell_DB.Sql.Postgre_SQL the fix is easy: unCamel :: String -> String unCamel ('<':cs) = '<' : inTag cs unCamel (a:b:c:cs) | isLower a && isUpper b && isUpper c = a : '_' : b : c : unCamel cs unCamel (a:bs@(b:cs)) | isLower a && isUpper b = a : '_' : toLower b : unCamel cs | otherwise = a : unCamel bs unCamel cs = cs Another point is, what about things like Data.Bits.shiftL would that be preferred as shiftL shift_L shift_l ? Generally, when shall we flatten the hump, 1) always -- not 2) unless followed by an uppercase letter 3) when followed by a lowercase letter I think, 3) is better than 2), things like for_m_ or map_m_ don't look right to me. All of them are easy to implement, the question is what to implement. What about feedO'Houlihan? IMO, it should clearly go to feed_O'Houlihan So, perhaps unCamel :: String -> String unCamel ('<':cs) = '<' : inTag cs unCamel (a:b:c:cs) | isLower a && isUpper b && isLower c = a : '_' : toLower b : c : unCamel cs unCamel (a:bs@(b:cs)) | isLower a && isUpper b = a : '_' : b : unCamel cs | otherwise = a : unCamel bs unCamel cs = cs (gives Database.Haskell_DB.Sql.Postgre_SQL, shift_L, for_M_ [that's not optimal, any ideas what to make of that?], feed_O'Houlihan). Please test, report shortcomings.
I.m not sure how I would write this going the other way, using Richard's hspp pre-processor.
I'd want to write Database.Haskell_DB.Sql.Postgresql, but I'd guess
That would become really complicated. I'm afraid if you want that, you'll have to do it yourself.
I'd have to write it as Database.Haskell_DB.Sql.Postgre_s_q_l or just Database.Haskell_DB.Sql.PostgreSQL :-(
Anyway, I'm having trouble with using Richard hspp. It changes ok_url to okUrl, but in fact the function concerned is named ok_url in Network.URL, so the pre-processor would have to be applied as part of cabal install for all packages.
Oh, great. There we have a preprocessor's nightmare, a package using both styles. Let us think what to do with such things.
I don't think it's practical to edit all the .cabal packages as they come in to say:
ghc-options: -F -pgmF hspp
and cabal install does not recognize this line if I add to to my ~/.cabal/config file.
Duncan, is there a way this can be done?