Re: [web-devel] Hamlet and functions that take multiple arguments

It's true that it won't be a runtime hit at all, so the parsing complexity isn't a concern from that perspective. I *am* worried about making Hamlet too complicated however. Does anyone else out there have an opinion on this topic? Actually, using the new period-not-required syntax, your example could be rewritten: [$hamlet|^(template f) x^|] which is definitely easier on my eyes. However, that syntax would not be available in $forall, $maybe et al. Michael PS: I like your e-mail address. On Thu, Jul 22, 2010 at 1:49 PM, Mark Bradley wrote:

looking at the code it does appear that your grammar for ContentEmbed objects could be extended to include lparen and rparen's. I'm not sure exactly how this would translate with the deref function in Text.Hamlet.Quasi (i havent used template haskell before) but it looks like it is entirely possible, meaning my example would become:

fun f x = [$hamlet| ^(template.f).x^ |]

and all is well. you could add an encoding for this such as:

template.f,x

this would have the same effect as the $ function from regular haskell.

the problem with that encoding is that is it less general than just allowing parens and probably more error prone.

the good thing about this is that it doesn't really matter how complicated you make the encoding and parsing and haskell code generation because it happens once at compile time.

On Wed, Jul 21, 2010 at 2:41 PM, Michael Snoyman wrote:

...

On Wed, Jul 21, 2010 at 4:17 AM, Mark Bradley

...

...

hamlet doesn't appear to support functions that take more than one argument.

i.e.

fun f x = [$hamlet| ^template.f.x^ |]

produces the call template (f x)

is there some way to make hamlet produce (template f) x?

Unfortunately not. It's not any *technical* limitation in Hamlet, just

wrote: that

...

I can't think of a good, intuitive syntax for it. The way that I work around this is by defining variables in a where clause, eg fun f x = [$hamlet|^templateTmp^|] where templateTmp = template f x If you have better ideas, I'm open to hearing them ;). Michael