Realtime loading and cabal #1

adzeitor opened this Issue Oct 9, 2012 · 17 comments

2 participants


Awesome library. I converted my code from slow hastache to it (benchmark results are impressive).

What you think about loading template in realtime (IO) then using (only add data) it as pure function? This could be a killer feature.

and this

$ cabal install mustache2hs
Resolving dependencies...
Configuring mustache2hs-0.1...
Building mustache2hs-0.1...
Preprocessing executable 'mustache2hs' for mustache2hs-0.1...

    Could not find module `ParseRecords'
    Use -v to see a list of the files searched for.
cabal: Error: some packages failed to install:
mustache2hs-0.1 failed during the building phase. The exception was:
ExitFailure 1



You mean doing the template compilation at runtime instead of compile time?

You would lose some compile-time-check features, and I'm not sure what sort of strategy I would use for implementing that. What is the big motivation for wanting this?

I have uploaded a 0.1.1 that should fix the build-from-cabal issue :)


I do not propose to remove - I propose to add ;) Both implementations would be the best solution.

This is pretty cool for me, but not for web designer. If template changes web designer need to recompile project =(


I guess if it's too hard for the designer to type make or use an autobuilder then you could use a load-templates-at-runtime solution. You could build stubs that take the same params as the mustache2hs-produced functions and use Hastache instead, for development mode.


As I understand it, hastache always use IO when render template. I want this (fast and easy):

main = do
  templ1 <- compile "templ1.mustache"
  print $ render templ1 data1
  print $ render temple2 data2

I was just thinking that your code can be converted to real time compile ;)


Oh, yeah, I guess unsafePerformIO wouldn't quite be magic in this case.

I'll think about it, but it's probably quit complex.

In the meantime, maybe your designers can use an autobuilder? It's really pretty easy :)


Actually, unsafePerformIO on hastache will work if you restart the app every time you change a file, which you would have to with your proposed solution as well :)


I also thought about it, but it can't increase performance :(


@adzeitor well, only use hastache in development. Use mustache2hs in production :)


Thanks. Anyway mustache2hs doing it right way.

Real time compilation is another project ;)


I'm not convinced there's a need for an in-between thing. mustache2hs solves compile-time, hastache solves runtime. You can use one in development and the other in production (using stubs, as I mentioned earlier) to get the best of both worlds.

@singpolyma singpolyma closed this Oct 9, 2012

If you think it would be useful, I might write a feature to automaticall generate hastache-wrapping stubs for use in development.


No. =)

Here's what I wrote (partly code sucks because it wrote as an example):

type Partials = [(Text,MuTree)]

data MuCompiled = MuCompiled { tree :: MuTree
                             , partials :: Partials}
                  deriving (Show, Eq)

-- stub
genPartials :: MuTree -> IO (Either ParseError Partials)
genPartials tree = do
  return $ Right []

compileStr :: Text -> IO (Either ParseError MuCompiled)
compileStr template = do
  let Right tree = parse parser "from string" template
  Right partials <- genPartials tree
  return $ Right (MuCompiled tree partials)

-- [(Text,Text)] must be replaced by a (Typeable)
render :: MuCompiled -> [(Text,Text)] -> Text
render comp@(MuCompiled tree partials) dat = mconcat $ map (muShow. snd) tree
  where muShow (MuText a) = a
        muShow (MuVar name _) = fromMaybe "undefined" (lookup name dat)
        muShow (MuSection a t) = render comp{tree=t} dat

full code:


@adzeitor since what you're writing / asking for seems to have a different API than what mustache2hs outputs, I'm not sure it could even be used easily in development mode (without writing wrapper stubs, anyway), since it would not be trivial to swap it out for mustache2hs in the real production code.


Yes. It has another API, but your parser maybe used in mustache2hs and in real time. I think it would be nice move parser to separated library.

By the way there are projects in which templates may be changed by the user (i mean binary distribution) and now the only way to use a slow hastache :(

My goal is fast templates (add handlebars support also cool) in real time (not API real time templates == API mustache2hs ).


... but why would you want fast and runtime? Just do runtime (and slow) for development and compiletime (and fast) for production...


Suppose I gave the client binaries with all templates and I do not need to worry about what will need to explain how to compile a project to change the background color, etc. Of course, they can break everything, but always can restore old templates. I think for many projects suitable compiletime, but there where no ;)

Speed ​​hastache visible to the eye on the average size of the template (on high system disk IO), because always reread templates. I try to implement what I want, but I'm not very good at typeable. I liked your code (parsec part), clean and easy to understand.


Seems like if a cient needs to modify templates to change colours there is too much in the templates ;) but I guess I can see this use case now.

If you get anywhere, I could be convinced to split the parser into a seperate project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment