Extremely cool. The one paper that the authors really ought to have reference is William Cooks (et al)'s recent ENSO paper - http://wcook.blogspot.ca/2012/06/enso-papers.html. But other than that, I sure hope this gets adopted. (I would have emailed the authors, but their emails are not in the paper itself, and I am feeling a little lazy right now).

I've thought about something like this when realizing I couldn't use "trhsx" for XML literals together with "she" for idiom brackets. At least not without a custom build system. Another issue with using preprocessors via ghc -F is that the preprocessor executable must be in $PATH which isn't guaranteed by cabal install and particularly troublesome with cabal-dev. If SugarHaskell works via Haskell packages and modules, that issue would be no more.

Yet another issue is that things like HSX don't work from ghci. I've sometimes thought that HSX might do better as a GHC extension, for this reason and the ones above, but perhaps the better solution is to make SugarHaskell a GHC extension? In the paper they mention that "SugarHaskell is not integrated in the Cabal build system or the ghci interactive Haskell interpreter." I think it could make sense as a GHC extension, to complement TemplateHaskell/QuasiQuotes.

Edit: the paper mentioned a HSX that is different from the one I'm talking about. I'm talking about the one from HSP for XML literals inside Haskell source files. I'll also add that some people might be opposed to coupling SugarHaskell to one compiler (in being a GHC extension), but it could additionally be provided as a decoupled preprocessor the same way there's one for the arrow syntax.

Edit: As a GHC extension, SugarHaskell might also be able to yield better error messages for incorrect syntax, or incorrect code involving correct syntax. For example with HSX, line numbers are often wrong and although work is being done to improve that case (by using the exact-printer of haskell-src-exts instead of the pretty-printer), there's still the issue that error messages from GHC will show the generated code rather than what you actually have in the source file.

Another issue with using preprocessors via ghc -F is that the preprocessor executable must be in $PATH which isn't guaranteed by cabal install and particularly troublesome with cabal-dev.

Another is if you get any kind of GHC error, you get a filename like /tmp/TEMP_FSDGS123.hs on line number 213 which is not the line number you were on. So without a wrapper that understands source mapping it's kind of horrid to use. But having a wrapper for GHC defeats the purpose of using -F which is that you and your users can use GHC/GHCi as normal, no special invocation necessary. So I kind of wanted GHC to call my preprocessor on the source and on error output. Stands to reason, I think.