[web-devel] [Yesod] Creating a static link

[Michael Snoyman]

On Sun, Feb 13, 2011 at 5:26 PM, Rafael Cunha de Almeida
<rafael-lists at kontesti.me> wrote:
> Michael Snoyman <michael at snoyman.com> disse:
>> You could go either way on that one. The content of an interpolation
>> is specifically *not* a fully-powered Haskell expression.
>
> Why is that? I have a little experience with RoR, there I could do
> something like this:
>
>    - @people.each do |person|
>        = person.name
>
> I think you don't want to have a fully-powered Haskell expression to
> avoid people adding too much code to the view (thinking in MVC pattern).
> However, it's not like people can't do it just because it's a little
> harder. Meanwhile, there are a lot of useful things that could be done
> if all (or most) haskell syntax was allowed to be interpolated.
>
> Instead of having special syntax like $forall, wouldn't it be better to
> just provide monad tranformers to allow for those sort of loops?
> Something like Control.Monad.LoopWhile module provides. That way hamlet
> would need only to provide a ${} syntax that allow for adding haskell
> code which will be evaluated but won't print anything to the site. That
> way things could work a lot like in ruby, which I think makes things a
> lot simpler.
>
> Allowing for a new sort of interpolation and any sort of haskell
> expression to be interpolated, hamlet wouldn't need to create its own
> flow control statements. The user could write their views freely using
> only haskell syntax when code logic is required.

There's a few reasons for this:

1) I do *not* think it is a good thing for a template language to
expose the full power of the programming language. As it is, I think
Hamlet already stretches the bounds of what a designer would feel
comfortable with.

2) This needs to get coded at some point, and frankly I don't feel
like completely reinventing a full-blown Haskell parser. I'm aware of
packages like haskell-src-exts-qq, but they are very heavy-weight and
introduce a huge body of possible bugs/unanticipated behavior to
Hamlet.

3) I'm not quite certain how you would intend to completely replace
all of the control structures with some variable splicing, I think
that would require further elucidation. However, I *highly* doubt it
will come out as concise as a forall statement currently is. My goal
for Hamlet isn't to provide absolute power in templates: it's to
provide a user-friendly, terse syntax to achieve 95% of what people
want to do easily. And for that extra 5%, it's very easy to call out
to a helper Haskell function.

The list syntax itself does not really bother me, though it does just
beg the question of where we draw the line. For instance, I have *no*
intention of implementing do-notation inside an interpolation. To
bring up Dmitry's suggestion: operators introduce all kinds of
precedence issues, since we won't have access to the precedence levels
Haskell is aware of. I think barking up *that* tree is a recipe for
very unintuitive behavior.

Michael