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

Michael Snoyman michael at snoyman.com
Sat Jul 24 13:40:26 EDT 2010


Implementing that feature was amazingly simple. I'm still not 100% sold on
the syntax, as I'm worried it's complicated Hamlet too much. But having the
feature available probably isn't too dangerous. It also doesn't cause any
problems with existing code as far as my tests go.

As a bonus, the $forall/$maybe issue was very easy to solve: just surround
it with parentheses.

[$hamlet|
$forall ((foo bar) baz) bin
   $bin$
|]

Code's up on github, let me know what you think.

Michael

On Fri, Jul 23, 2010 at 4:22 PM, Mark Bradley <barkmadley at gmail.com> wrote:

> On Fri, Jul 23, 2010 at 7:31 PM, Michael Snoyman <michael at snoyman.com>
> wrote:
> > 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^|]
>
> i like that
>
> > which is definitely easier on my eyes. However, that syntax would not be
> > available in $forall, $maybe et al.
>
> an interesting perspective of this would be to use syntax in the
> forall to show that you are working with a list (not sure how this
> could be extended for maybe et al.)
> $forall [(map snd) tupleList] val
>
> > Michael
> > PS: I like your e-mail address.
>
> Cheers,
> Mark
>
> >
> > On Thu, Jul 22, 2010 at 1:49 PM, Mark Bradley <barkmadley at gmail.com>
> 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 <michael at snoyman.com>
> >> wrote:
> >> >
> >> >
> >> > On Wed, Jul 21, 2010 at 4:17 AM, Mark Bradley <barkmadley at gmail.com>
> >> > wrote:
> >> >>
> >> >> 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
> >> > 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
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/web-devel/attachments/20100724/f051150a/attachment.html


More information about the web-devel mailing list