I like parentheses, since we'd be able to use the interpolation character (whatever it ends up being) within the interpolation. However, I'd prefer the template haskell style $(...). I wonder if hamlet could leverage haskell-src-exts-qq, which defines quasiquoters for haskell code. I've used it myself, and although it's been a while and I'm a bit hazy on the details, I remember that it worked rather well. One gotcha I remember is that it didn't usually know correct fixities for operators etc, which could lead to quite confusing errors. This may have improved since I last looked at it, though. -matt On Thu, Dec 30, 2010 at 11:31 PM, Aur Saraf wrote:

On Fri, Dec 31, 2010 at 8:57 AM, Michael Snoyman wrote:

...

I thought I would start this in a separate thread. Right now in Hamlet, $foo.bar.baz$ (or equivalently $foo bar baz$ gets converted to the Haskell code "foo (bar baz)". This makes a fair bit of sense for the period-delimited syntax, but feels very wrong for the space-delimited syntax. So the question is: should we change things around? That would mean we would need to modify our current templates to include extra parentheses, eg:

   $foo.bar.baz$ -> $foo (bar baz)$    $a.b.c.d$ -> $a (b (c d))$

I suppose that, in theory, if we actually change the variable interpolation character to a percent sign, we could take back the dollar sign to work like Haskell, eg:

   $a.b.c.d$ -> %a $ b $ c d%

And just since I brought *that* up: we could consider using a different symbol for variable interpolation than the percent sign, such as a hash or ampersand. However, both of those already have special meaning (hash == id, ampersand == HTML escape character), so I don't know how well that would work. There was talk once upon a time of merging the syntax for dollar-sign and caret interpolation, which now that we've added some more polymorphism it might be possible.

Caveat: I haven't actually written any code for this, so I don't know how feasible it is. I'm basically throwing out ideas as they come to me.

Michael

HAML uses #{some haskell here} for interpolation (which is ruby syntax). HAML implementations in other languages stayed with that. We could too.

Is it really impossible to just use the plaintext as code in Template Haskell? It would really be nice if you could use any bit of Haskell wherever you can use a variable (but it's just nice-to-have, not worth playing with GHC's code just to get it).

If it is impossible, I'm all for $ doing what it's supposed to... but that way lies reimplementing Haskell parsing, and I'm not sure you want to go there (we'll add more and more requests as we got more and more syntax...)

_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

On Fri, Dec 31, 2010 at 5:08 PM, Felipe Almeida Lessa wrote:

On Fri, Dec 31, 2010 at 6:51 AM, Matt Brown wrote:

...

I wonder if hamlet could leverage haskell-src-exts-qq, which defines quasiquoters for haskell code.  I've used it myself, and although it's been a while and I'm a bit hazy on the details, I remember that it worked rather well.  One gotcha I remember is that it didn't usually know correct fixities for operators etc, which could lead to quite confusing errors.  This may have improved since I last looked at it, though.

Of course he was aware, someone wrote a message six hours ago =).  I think it's doable, Matt.

Cheers,

-- Felipe.

_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

Contrary to popular belief, I don't read my email at every hour of the day ;). In fact, I can guarantee you that I won't see any email from sundown on Friday till sundown on Saturday[1]. Anyway, I have a few concerns regarding haskell-src-exts-qq: 1) It's a heavyweight dependency. 2) I assume the parsing time of this will be significantly larger than the current parse code. (This is the most minor of my issues.) 3) I don't know how well it will interact with the debug version of the templates. 4) It's not necessarily desirable to make the interpolation so complex. Compare for instance Haml versus Django templates: the latter purposely allows only a limited form of interpolation to keep templates simple. I'm not vetoing this, not by a long shot. I'm merely bringing up the issues I've been thinking about for the past 30 hours ;). Michael [1] http://en.wikipedia.org/wiki/Shabbat#Prohibited_activities PS: I'm on a quasi-vacation for the next week, so I don't know how regular my emailing will be.

On 2010-12-31 16:06, Felipe Almeida Lessa wrote:

On Fri, Dec 31, 2010 at 5:31 AM, Aur Saraf wrote:

...

Is it really impossible to just use the plaintext as code in Template Haskell? It would really be nice if you could use any bit of Haskell wherever you can use a variable (but it's just nice-to-have, not worth playing with GHC's code just to get it).

It was until someone else wrote a library for us =) [1]. We just need to unpack the QuasiQuoter data type and use it inside Hamlet's quasiquoter.

[1] http://hackage.haskell.org/package/haskell-src-exts-qq

Michael, were you aware of this library?

Cheers,

It should be noted that the hse-qq library doesn't handle infix operator precedence properly. There are proposals to remedy this; but it requires changes to GHC, see http://hackage.haskell.org/trac/ghc/ticket/4430 http://hackage.haskell.org/trac/ghc/blog/Template%20Haskell%20Proposal Cheers,