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

[Dmitry Kurochkin]

On Sun, 13 Feb 2011 18:09:08 +0200, Michael Snoyman <michael at snoyman.com> wrote:
> 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.
> 

How about allowing "(+) a b"?

Somewhat unrelated question: Why ToCss class is not exported? I wanted
to add a pixel size type that would allow +, -, *, / and append "px"
suffix. I ended up with explicit toPixel function for that.

What do you think about adding more types and functions for CSS? Similar
to SCSS. E.g. functions to manipulate Color.

Regards,
  Dmitry

> Michael
> 
> _______________________________________________
> web-devel mailing list
> web-devel at haskell.org
> http://www.haskell.org/mailman/listinfo/web-devel