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

Dmitry Kurochkin dmitry.kurochkin at gmail.com
Sun Feb 13 18:25:29 CET 2011


On Sun, 13 Feb 2011 19:07:11 +0200, Michael Snoyman <michael at snoyman.com> wrote:
> On Sun, Feb 13, 2011 at 6:56 PM, Dmitry Kurochkin
> <dmitry.kurochkin at gmail.com> wrote:
> > 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"?
> 
> That seems pretty safe.
> 

Cool!

> > 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.
> 
> There's a very good reason ToCss is not exported: I messed up ;). I'll
> address that soon.
> 
> > What do you think about adding more types and functions for CSS? Similar
> > to SCSS. E.g. functions to manipulate Color.
> 
> I think it's a good idea. It could be done as either an add-on package
> (once ToCss is exported) or as patches to hamlet. You interested in
> undertaking this?
> 

I like having it as a part of Cassius. I am interested in this, as well
as in other parts of Yesod :) Though, I have limited time I can devote
to Yesod. So I am not going to promise anything.

I think the first thing I would like to implement is a pixel size type
and related functions.

Regards,
  Dmitry

> Michael



More information about the web-devel mailing list