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? _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe