[Haskell-cafe] Re: [web-devel] Google Summer of Code: BlazeHTML RFC
On Sat, May 29, 2010 at 7:34 PM, Matt Parker moonmaster9...@gmail.com wrote: Q3: Which HTML version would you preferably use? HTML 5. google summer of code should be about pushing the new and exciting. I can say that HTML 5 will definitely be supported. We use some sort of metacode to generate Haskell combinators from a simple, formal HTML specification. Thus, it should be possible to support HTML 5, HTML 4 Strict and HTML 4 Transitional easily. Kind regards, Jasper Van der Jeugt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [web-devel] Google Summer of Code: BlazeHTML RFC
A (hopefully) non-cropped version of the chart, http://tinyurl.com/2cl42js ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [web-devel] Google Summer of Code: BlazeHTML RFC
Hello,
HSP does not use xhtml or any other library internally.
The trhsx pre-processor turns this:
bigTable :: [[Int]] - String
bigTable t = renderAsHTML $ evalIdentity $
table
% mapM (\r - tr% mapM (\d - td% show d %/td) r %/tr) t %
/table
into:
bigTable :: [[Int]] - String
{-# LINE 38 hsp-blaze.hs #-}
bigTable t
= L.unpack $
B.renderHtml $
evalBlaze $
(genElement (Nothing, table) []
[asChild
((asChild
(mapM
(\ r -
(genElement (Nothing, tr) []
[asChild
((asChild
(mapM
(\ d -
(genElement (Nothing, td) []
[asChild ((asChild (show
d)))]))
r)))]))
t)))])
Basically, it just calls genElement to create the elements, and asChild is a
class to turn things into things that can be children on an element.
The question remains, though, what is the type that genElement is producing?
The type is monad specific. genElement comes from this class,
-- | Generate XML values in some XMLGenerator monad.
class Monad m = XMLGen m where
type XML m
data Child m
data Attribute m
genElement :: Name - [XMLGenT m [Attribute m]] - [XMLGenT m [Child m]]
- XMLGenT m (XML m)
genEElement :: Name - [XMLGenT m [Attribute m]]
- XMLGenT m (XML m)
genEElement n ats = genElement n ats []
xmlToChild :: XML m - Child m
pcdataToChild :: String - Child m
Most of the stuff in the HSX/HSP family now produces values of the type:
data XML = Element Name Attributes Children
| CDATA Bool String
and you can use renderXML or renderAsHTML to convert that to a String
depending on what rendering rules you want in effect.
Anyway, on to the exciting stuff! The benchmarks:
As I test I have implemented the big-table benchmark for four cases:
1. the existing html test in benchmarkes/bigtable
2. plain-old blaze
3. hsp using the identity monad, the XML type, and String
4. hsp using blaze
html: mean: 15.86650 ms, lb 15.68054 ms, ub 16.22545 ms, ci 0.950
blaze: mean: 28.86730 ms, lb 28.45495 ms, ub 29.63139 ms, ci 0.950
hsp+identity: mean: 50.05748 ms, lb 49.45395 ms, ub 50.97315 ms, ci 0.950
hsp+blaze: mean: 166.4717 ms, lb 161.7957 ms, ub 174.1437 ms, ci 0.950
As a chart:
http://chart.apis.google.com/chart?cht=bvgchs=200x250chd=t:29,50,166.5chds=0,180chdl=blaze|hsp+identity|hsp+blazechco=ff|00ff00|ffchxt=ychxr=0,0,180,25
I am not entirely sure I did these tests correctly. So, we should not really
trust these numbers at all for the moment.
Also, the 'nf' thing did not have a lazy ByteString instance, so for the
blaze stuff, I used L.unpack to turn the output back into a String -- which
is not really 'fair'. (And would also be bad if the tests actually contained
utf-8, and not just an ascii subset of it).
That said, my first attempts at using blaze to speed up HSP do not seem to
have worked :p
I think that 'speeding up' HSX is going to be somewhat dependent on what you
are trying to do with it. If you are just writing templates by hand, and the
data you are adding in is String data, then I think the current HSX stuff is
probably doing a descent job. Everything starts as String, and ends as a
String. Then if you want you can convert that String to a ByteString, etc.
The default instances for HSX would probably not perform as well if you had
a lot of data you wanted to splice in that was already pre-encoded utf-8
bytestrings. If that is your case, though, you could just implement an
alternative XML data type and matching monad, and use those with hsx
instead. Though, you still have to be careful. It is not enough to have just
utf-8 encoded bytestrings, they would also need to already have any special
html characters escaped (such as ). You can't just read utf-8 values out of
database and stick them straight into the html output.
Another option might be to implement a instance of XMLGen that does not have
an intermediate type -- it just goes directly to String, Text, ByteString,
or whatever you want. I am not sure how much overhead the intermediate type
is really causing though. One thing that slows the hsx html rendering down
is that it has to check each tag and see if it is one of the special tags
that has no close tag. (Such as meta, input, img, etc). Or if it is one of
the tags where the content is rendered as as CDATA instead of PCDATA, such
as script and style. And the only way to do that is to pattern match on the
tag name.
I have attached all three files I used to benchmark to this message.
Certainly making hsx/hsp faster would be nice (though it doesn't seem
especially slow to start with). And it would also be nice if you could use
use a mixture of hsx+blaze combinators.
- jeremy
ps. I also added,
Re: [Haskell-cafe] Re: [web-devel] Google Summer of Code: BlazeHTML RFC
On 05/29/2010 08:05 PM, Gregory Collins wrote: Matt Parkermoonmaster9...@gmail.com writes: Q3: Which HTML version would you preferably use? HTML 5. google summer of code should be about pushing the new and exciting. Yes, definitely, this should be the default IMO. +1 -- Jochem Berndsen | joc...@functor.nl ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [web-devel] Google Summer of Code: BlazeHTML RFC
+1 for HTML5. Also, I suggest focussing on the html serialization of HTML5. The xml serialization (XHTML5) is only useful in an XML environment. For such environments pure xml libraries are more appropriate. Besides, I like html syntax better. On 30 May 2010 16:27, Jochem Berndsen joc...@functor.nl wrote: On 05/29/2010 08:05 PM, Gregory Collins wrote: Matt Parkermoonmaster9...@gmail.com writes: Q3: Which HTML version would you preferably use? HTML 5. google summer of code should be about pushing the new and exciting. Yes, definitely, this should be the default IMO. +1 -- Jochem Berndsen | joc...@functor.nl ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [web-devel] Google Summer of Code: BlazeHTML RFC
I'm a heavy hsp user. Could hsp benefit from this project by using blaze as a back end instead of whatever it's using now? IIUC, Hsp uses hsx (via the preprocessor program trhsx) to convert xml-containing hybrid hsp/xml/html files into compilable haskell. I expected hsx uses XHTML (which iiuc is what blaze would replace) on the backend but I don't see it listed in the dependencies at http://hackage.haskell.org/package/hsx-0.7.0 so I guess it doesn't and uses something internal rather than xhtml. (Right?) My question as regards BlazeHTML is if there could be any performance win/tie in for the hsp/hsx toolchain. FWIW, wrt to blaze sclv commented on reddit The idea is rather that this would be a replacement for the html combinator library, as distinct from templating (hamlet, hstringtemplate, bravo, chunks, press, co) and as distinct from the *sp model of inlined code (hsp). Edit: Ideally, and generally for Haskell libs, the choices of persistence layer, html generation library, dispatch model, and server layer are largely orthogonal. Strong typing makes any ad-hoc plumbing a breeze. http://www.reddit.com/r/haskell/comments/bxa0a/blazehtml_a_blazingly_fast_html_combinator/ thomas. 2010/5/30 Tom Lokhorst t...@lokhorst.eu: +1 for HTML5. Also, I suggest focussing on the html serialization of HTML5. The xml serialization (XHTML5) is only useful in an XML environment. For such environments pure xml libraries are more appropriate. Besides, I like html syntax better. On 30 May 2010 16:27, Jochem Berndsen joc...@functor.nl wrote: On 05/29/2010 08:05 PM, Gregory Collins wrote: Matt Parkermoonmaster9...@gmail.com writes: Q3: Which HTML version would you preferably use? HTML 5. google summer of code should be about pushing the new and exciting. Yes, definitely, this should be the default IMO. +1 -- Jochem Berndsen | joc...@functor.nl ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [web-devel] Google Summer of Code: BlazeHTML RFC
Hey Thomas, Yes, hsx/hsp could get a performance gain by using BlazeHtml as a backend. However, I'm not sure if it is possible to change the backend without changing the user API (but I do hope so). Kind regards, Jasper Van der Jeugt On Sun, May 30, 2010 at 5:58 PM, Thomas Hartman tphya...@gmail.com wrote: I'm a heavy hsp user. Could hsp benefit from this project by using blaze as a back end instead of whatever it's using now? IIUC, Hsp uses hsx (via the preprocessor program trhsx) to convert xml-containing hybrid hsp/xml/html files into compilable haskell. I expected hsx uses XHTML (which iiuc is what blaze would replace) on the backend but I don't see it listed in the dependencies at http://hackage.haskell.org/package/hsx-0.7.0 so I guess it doesn't and uses something internal rather than xhtml. (Right?) My question as regards BlazeHTML is if there could be any performance win/tie in for the hsp/hsx toolchain. FWIW, wrt to blaze sclv commented on reddit The idea is rather that this would be a replacement for the html combinator library, as distinct from templating (hamlet, hstringtemplate, bravo, chunks, press, co) and as distinct from the *sp model of inlined code (hsp). Edit: Ideally, and generally for Haskell libs, the choices of persistence layer, html generation library, dispatch model, and server layer are largely orthogonal. Strong typing makes any ad-hoc plumbing a breeze. http://www.reddit.com/r/haskell/comments/bxa0a/blazehtml_a_blazingly_fast_html_combinator/ thomas. 2010/5/30 Tom Lokhorst t...@lokhorst.eu: +1 for HTML5. Also, I suggest focussing on the html serialization of HTML5. The xml serialization (XHTML5) is only useful in an XML environment. For such environments pure xml libraries are more appropriate. Besides, I like html syntax better. On 30 May 2010 16:27, Jochem Berndsen joc...@functor.nl wrote: On 05/29/2010 08:05 PM, Gregory Collins wrote: Matt Parkermoonmaster9...@gmail.com writes: Q3: Which HTML version would you preferably use? HTML 5. google summer of code should be about pushing the new and exciting. Yes, definitely, this should be the default IMO. +1 -- Jochem Berndsen | joc...@functor.nl ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [web-devel] Google Summer of Code: BlazeHTML RFC
Q3: Which HTML version would you preferably use? HTML 5. google summer of code should be about pushing the new and exciting. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [web-devel] Google Summer of Code: BlazeHTML RFC
Matt Parker moonmaster9...@gmail.com writes: Q3: Which HTML version would you preferably use? HTML 5. google summer of code should be about pushing the new and exciting. Yes, definitely, this should be the default IMO. G -- Gregory Collins g...@gregorycollins.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
