On 27 December 2010 07:35, Jonathan Geddes wrote:

#1 Parse a string at compile-time so that a custom syntax for representing data can be used. At the extreme, this "data" might even be an EDSL.

Hello Jonathan By this are you meaning to add quasiquoting to the language "Haskell" or the "Glasgow Haskell", taking it out of the domain of Template Haskell? How would the first example look like with Template Haskell and is current quasiquoting syntax? I'm suspecting the differences are pretty small.

Hi,

But TH gives me the same feeling as other language features that have been described as "bolted on." Also, TH is both library and built-in syntax (via an extension) which feels strange to me.

I don't understand why the library/extension duality is a problem. I would say that the best approach is to have language support (through extensions) for primitive operations like splicing, and to have libraries that combine these operations into more complex systems (like automatic derivation of type classes).

Again, TH is very powerful, and fills in a number of holes in Haskell's feature set. But it leaves me wondering if these holes should not be filled in by other, more specialized features, leaving TH to continue to find other holes to fill.

Shouldn't specialized features be defined in terms of general features?

...

json :: String -> JsonObject json = ...

data = [ json | { "name" : "Jonathan" , "favorite language": "Haskell" } |]

How does this differ from the current QuasiQuotes extension? From what I can tell, all you need to achieve this with TH is to automatically derive a Language.Haskell.TH.Lift instance for JsonObject, i.e. a function lift :: JsonObject -> Q Exp such that the expression will evaluate to the original JsonObject. A QuasiQuoter like the one you describe can then be created by QuasiQuoter { parseExp = lift . json }. Should both approaches be supported directly, or should we sacrifice the generality of the current quoters for the simplicity of the ones you suggest? The second part (deriving instances for general type classes) is a lot more complicated. I would say that the most general way of showing that a class can be derived is to provide a function that produces a set of declarations given the name of the datatype. Here's a very simple suggestion for incorporating this into the Haskell deriving syntax. Suppose we have these two classes and TH functions for deriving them: class Class1 ... class Class2 ... class1 :: Name -> Q [Dec] class2 :: Name -> Q [Dec] data D = D deriving (Show,class1,class2) The last declaration could expand to: data D = D deriving Show class1 'D class2 'D If you don't want to write class1 and class2 by operating directly on Haskell declarations, but rather use some DSL for specifying instances, then all you need is a function deriv :: DerivationDSL -> (Name -> Q [Dec]). /J On 27 December 2010 08:35, Jonathan Geddes wrote:

Cafe,

First let me say that Template Haskell is very powerful and a lot of great work has been done in this area. It fills in a number of holes in Haskell's feature set.

But TH gives me the same feeling as other language features that have been described as "bolted on." Also, TH is both library and built-in syntax (via an extension) which feels strange to me. Finally, It's very complicated to do some simple things.

I see TH used most for the following tasks:

#1 Parse a string at compile-time so that a custom syntax for representing data can be used. At the extreme, this "data" might even be an EDSL. #2 Provide instances automatically.

I would propose that more specialized features be implemented to accomplish these tasks. To start, I'll throw out some ideas that provide these capabilities.

For TH use #1, compile-time parsing of arbitrary strings, I think it would be nice for quasiquote semantics to be modified so that code like

...

json :: String -> JsonObject json = ...

data = [ json | { "name" : "Jonathan" , "favorite language": "Haskell" } |]

causes the function json to be called at compile time with a string argument of " {\"name\" : \"Jonathan\"\n , \"favorite language\": \"Haskell\"\n }". The whole expression being then replaced with the result of the function application. What I like about this is that defining "quasiquoters" is trivial. They're just functions of the form String -> a. Many such quasiquoters already exist and would be ready for use! I imagine certain rules would apply, ie a quasiquoter must be defined prior to use and in a separate module, etc.

For TH use #2, automatic instances, I would propose a way of declaring that a class can be automatically derived, and therefore added to the set [Eq, Ord, Show, Read, ... , etc]. This is the set of classes that can be put in the "deriving" clause of a type declaration. I don't know exactly what the syntax for this would look like, but I imagine it would look a bit like the various current implementations of automatic instances in TH.

Again, TH is very powerful, and fills in a number of holes in Haskell's feature set. But it leaves me wondering if these holes should not be filled in by other, more specialized features, leaving TH to continue to find other holes to fill.

I'm wondering if others see TH as a permanent solution, or if you agree with me that some of TH's most common usages should have more specialized features dedicated to them. It may very well be that I am simply not experienced enough with TH to fully appreciate and embrace it.

By the way, did I miss any uses of TH as common as the ones I mentioned?

--Jonathan

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Hi, Jonathan Geddes wrote:

For TH use #1, compile-time parsing of arbitrary strings, I think it would be nice for quasiquote semantics to be modified so that code like

...

json :: String -> JsonObject json = ...

data = [ json | { "name" : "Jonathan" , "favorite language": "Haskell" } |]

causes the function json to be called at compile time with a string argument of " {\"name\" : \"Jonathan\"\n , \"favorite language\": \"Haskell\"\n }". The whole expression being then replaced with the result of the function application. What I like about this is that defining "quasiquoters" is trivial. They're just functions of the form String -> a. Many such quasiquoters already exist and would be ready for use! I imagine certain rules would apply, ie a quasiquoter must be defined prior to use and in a separate module, etc.

First note that this is just quotation, not yet quasiquotation. For quasiquotation, you would also need to support antiquotation (i.e., the use of Haskell identifiers or even expressions in the middle of quoted syntax). And to reach something similar to the current support for quasiquotation, you would need to support patterns etc., too. Secondly, I was going to propose to use generic programming to convert from a parser like (String -> JsonObject) to a quasiquoter for Json. But after half a day of experiments, I figured out that this idea is already developed in Geoffrey B. Mainland. Why It's Nice to be Quoted: Quasiquoting for Haskell. Haskell Workshop 2007 Available at: http://www.eecs.harvard.edu/~mainland/publications/mainland07quasiquoting.pd... In that paper, Geoffrey Mainland explains how a parser can be generically upgraded to a quoter, reaching an intermediate conclusion on page 6:

By using generic programming, we can take a parser and create expression and pattern quasiquoters for the language it parses with only four lines of code, including type signatures! This holds not just for our simple object language, but for any object language.

He goes on to explain how to add "support for antiquotation [...] with only slightly more than four lines of code". The functions dataToExpQ and dataToPatQ from that paper are available in the TH library in Language.Haskell.TH.Quote. A simple helper function quasiQuoter :: Data a => (String -> Either String a) -> QuasiQuoter quasiQuoter parser = QuasiQuoter { quoteExp = either fail (dataToExpQ (const Nothing)) . parse , quotePat = either fail (dataToPatQ (const Nothing)) . parse } should allow you to write your JSON example as follows: parse :: String -> Either String JsonObject parse = ... json = quasiQuoter parse This seems simple enough to me, so it looks as if your use case is already supported as a library on top of the more general API. Tillmann

All, 2010/12/27 Jonathan Geddes :

I see TH used most for the following tasks:

#1 Parse a string at compile-time so that a custom syntax for representing data can be used. At the extreme, this "data" might even be an EDSL. #2 Provide instances automatically.

Just a note that TH is also sometimes used in its generality: as a general compile time meta-programming facility. For example, in my experimental grammar-combinators parsing library [1], I am using it to perform grammar transformations at compile time by simply generating the definition for the transformed grammar using TH. This could be extended in the future to provide a low-cost parser generator that works from within TH, which can reuse the library's infrastructure. Dominique [1] http://projects.haskell.org/grammar-combinators/