#GIT ANNEX HACKAGE MANUAL#
Quoting works sometimes, but a lot of the time you have to do manual AST grafting and plumbing. $(fooBar ''Asdf) just does not look nice.
This slows down compile time considerably.
#GIT ANNEX HACKAGE CODE#
The code is interpreted anew every time a file is compiled, and often, a ton of packages are required by the running TH code, that have to be loaded. TH code takes a relatively long time to run. You can't control how much a TH function generates unless the developer allows it if you find a function that generates a database interface and a JSON serialization interface, you can't say "No, I only want the database interface, thanks I'll roll my own JSON interface" When a TH function has type Q Dec, it can generate absolutely anything at the top-level of a module, and you have absolutely no control over what will be generated. Also, most people write their generators in the Q monad even when they don't have to, which is like writing bla :: IO Int bla = return 3 you are giving a function more "environment" than it needs, and clients of the function are required to provide that environment as an effect of that.įinally, there are some things that make TH functions less fun to use as an end-user: Some people don't know this, and because of that, they create multiple overloaded versions of essentially the same functions with the same functionality, and these functions lead to a certain bloat effect. Did you know that you can write forM_ generateLens? Q is just a monad, so you can use all of the usual functions on it.
#GIT ANNEX HACKAGE GENERATOR#
Let's say someone makes a generator for lenses, and more often than not, that generator will be structured in such a way that it can only be called directly by the "end-user," and not by other TH code, by for example taking a list of type constructors to generate lenses for as the parameter. Then there are some problems that make TH functions less fun to use as a library developer: TH can access "module-private" functions and definitions, completely breaking encapsulation in some cases.You don't want to have to look through every cabal package you ever download in search for TH exploits. Code that runs at compile-time can do arbitrary IO, including launching missiles or stealing your credit card.You generated an expression that references a free variable foo that doesn't exist? Tough luck, you'll only see that when actually using your code generator, and only under the circumstances that trigger the generation of that particular code. You can generate expressions that don't compile.TH would be more reliable if one could express that a function may only generate expressions of a certain type, or only function declarations, or only data-constructor-matching patterns, etc.
You have no control over what kind of Haskell AST a piece of TH code will generate, beyond where it will appear you can have a value of type Exp, but you don't know if it is an expression that represents a or a (a -> (forall b.One reason for avoiding Template Haskell is that it as a whole isn't type-safe, at all, thus going against much of "the spirit of Haskell." Here are some examples of this:
0 kommentar(er)
