- web-devel - Haskell.org

Lazy simpleHTTP
by Henning Thielemann 14 Dec '08

14 Dec '08

I have HTTP-3001.0.4 and I like to check the HTTP response headers before downloading the entire document. I hesitate to do a HEAD request first and then a separate GET request, because there is a (little, but not zero) chance, that the document changes between both requests. I hoped that simpleHTTP is lazy enough, so that I can check the rspHeaders field of the HTTP response and that only touching rspBody would download the document content. Unfortunately simpleHTTP downloads the entire document before I can access the HTTP header. To be honest, I would also like to fetch the content of the document lazily. Actually, if simpleHTTP would behave lazy, I suspect this requires using unsafeInterleaveIO internally, which is considered a hack. Is this the reason why simpleHTTP is not lazy? Or do I just need a lazy Stream type for this purpose?

4 9

Network.Browser.splitMany - bug?
by Henning Thielemann 05 Dec '08

05 Dec '08

I don't know whether this is a bug or a feature: *Network.Browser> splitMany ',' "abc,def,ghj" ["abc",",def,gh"] According to the name and the comment "Removes delimiters" I propose: *Network.Browser> splitMany' ',' "abc,def,ghj" ["abc","def","ghj"] with splitMany' :: Eq a => a -> [a] -> [[a]] splitMany' delim = uncurry (:) . foldr (\c ~(str,rest) -> if c==delim then ([], str:rest) else (c:str, rest)) ([],[])

1 0

HaskellWiki: Category:Web
by Henning Thielemann 28 Nov '08

28 Nov '08

I wondered why there was still no category for web applications on the Haskell Wiki, so I have initialized one: http://www.haskell.org/haskellwiki/Category:Web

1 0

Where do you start?
by Artyom Shalkhakov 24 Nov '08

24 Nov '08

Hello, I'd like to share some links, gathered with much help from other mailing list subscribers. There seem to be plenty of ways to get the job done for a Haskell web developer, aside from using more common languages. :) First, the do-it-yourself way. There are CGI/FCGI [1], [2] bindings, so you can use your binaries with almost any webserver. A very nice templating engine [3] is also available. If you wish to embed (X)HTML in Haskell, you can use either the combinator libraries [4], [5] or [6] (which is highly experimental). Low-level libraries like [7],[8] can be used for database connectivity, while [9] is for those who would like to construct their queries using combinators. You can also take a look at lightweight frameworks like [10], [11]. Finally, in the near future we'll hopefully have a very robust and high-performance HTTP web-server [12] which is going to be very simple to start with. And about the frameworks out there. There are a few all-in-one frameworks ([13], [14]) available for those who can dive into the code, because their documentation is quite lacking. (Of course, you can help out the authors by proposing some!) If you're interested in HAppS, there is a tutorial to help you [15], and you can take [16] as a reference. I'm very grateful to all the people who responded to my inquiry! Regards, Artyom. [1] CGI, <http://hackage.haskell.org/cgi-bin/hackage-scripts/package/cgi> [2] FCGI, <http://hackage.haskell.org/cgi-bin/hackage-scripts/package/fastcgi> [3] HStringTemplate, <http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HStringTemplate> [4] Text.Html, a combinator library <http://hackage.haskell.org/cgi-bin/hackage-scripts/package/html> [5] Text.Xhtml, a combinator library <http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xhtml> [6] VXML <git://mawercer.de/vxml> [7] Takusen <http://darcs.haskell.org/takusen/> [8] HDBC <http://software.complete.org/software/projects/show/hdbc> [9] HaskellDB <http://haskelldb.sourceforge.net/> [10] HVAC (Haskell View and Controller) <http://community.haskell.org/~sclv/hvac/> [11] Kibro <http://hackage.haskell.org/cgi-bin/hackage-scripts/package/kibro> [12] Hyena: <http://github.com/tibbe/hyena/tree/master>, <http://www.galois.com/blog/2008/09/12/left-fold-enumerators-a-safe-expressi…> [13] HAppS, the Haskell Application Server <http://happs.com/> [14] Turbinado, an early stab at Ruby On Rails <http://turbinado.org/> [15] Real World HAppS: The Cabalized, self-demoing HAppS Tutorial <http://happstutorial.com/> [16] Gitit, a wiki written using HAppS and git <http://github.com/jgm/gitit/tree/master/>

2 1

Where do you start?
by Артем Шалхаков 20 Nov '08

20 Nov '08

Hello, I'm interested in Haskell web programming. Quick googling took me to HAppS, HVAC, WASH and do-it-yourself blog posts. I tried HVAC, which doesn't build on GHC 6.10.1 (if somebody's interested, I'll post some compiler complaints). I really like its approach, though. Then I tried to DIY: wired Haskell to Lighty using FastCGI. This approach works, but leaves very much to desire: XHTML combinators don't really give you compile-time validation, so what is the point of writing it in code? I had thought I'd need some templating, so I tried HStringTemplate to find that it doesn't build on my GHC (BTW, this templating engine has some neat concepts, which I like :-)). Then I turned to HAppS, which is painfully slow to build on my development machine, and I think it is too monolithic. Besides, it looks like it depends on mostly experimental GHC features, and lacks documentation! I'm not a Haskell Jedi, so I think there's no way I can make it to work. I found out that WASH uses CGI, which is sooo retro. Is it just my misunderstanding, maybe? There's also a question regarding which DBC library to use. Hackage has Takusen, HaskellDB, HDBC, HSQL. So which one? I'd be very glad if somebody gave an advice to a noob Haskell web programmer. :) Regards, Artyom.

4 3

Ocaml has an ocaml virtual machine in JS now
by Marc Weber 18 Nov '08

18 Nov '08

:-) We already have a haskell to javascript compiler.. It's not an interpreter though.. ----- Forwarded message from Vincent Balat <vincent.balat(a)pps.jussieu.fr> ----- m: 0 (Mail was not recognized as spam) X-GMX-UID: Y5UUIa4CZDI5lllf82Y2BshxemhmYwEo Status: O Content-Length: 1017 Lines: 27 [Mail from Benjamin Canou redirected to the list] Hi, O'Browser is an implementation of the OCaml virtual machine in JavaScript, designed to run in web browsers. It features a runtime library compatible with OCaml's standard one (including OOP and concurrent threads) and bindings of some JavaScript functions to manipulate the DOM primitives. The distribution is available at [1] and an online version of the tutorial is reachable at [2]. Please note that this is an early version, in particular the DOM interface module is neither pretty nor well typed. However, it can already be used to create little applets or scripts (as in the tutorial [2], the examples of the distribution [3] or my webpage [4]) and we'll be glad to receive your comments or bug reports. Have fun. Benjamin Canou. [1] http://www.pps.jussieu.fr/~canou/obrowser-0.1.tar.bz2 [2] http://www.pps.jussieu.f ----- End forwarded message -----

1 0

The Real Monad Transformer or is Haskell.org hijacked?
by Henning Thielemann 13 Nov '08

13 Nov '08

On Tue, 3 Apr 2007, Henning Thielemann wrote: > It was argued that people avoid Haskell because of terms from Category > theory like 'Monad'. This problem can now be solved by a wrapper which > presents all the WWW without monads! Start e.g. at > http://saxophone.jpberlin.de/MonadTransformer?source=http%3A%2F%2Fwww%2Ehas… > Of course the tool is written in Haskell, that is, Haskell helps solving > problems which only exist because of Haskell. > Bug reports and feature requests can be tracked at > https://sourceforge.net/projects/parallelweb The produced content has not changed very much, but the interface is much more friendly now. You can now enter the world of the Real Monad Transformer e.g. at: http://www.haskell.org.monadtransformer.parallelnetz.de/haskellwiki/Categor… Good luck! Henning

2 1

VXML - validating XHTML library
by Marc Weber 13 Sep '08

13 Sep '08

Hi @ll. Those of you reading the haskelcafe mailinglist already know that I've been working on vxml. It's a library letting you write XHTML code validating the result at compilation time against a given dtd. How does it work? Given a doctype like this : <!ELEMENT root (y*,z)*> <!ELEMENT y EMPTY> <!ELEMENT z EMPTY> results in a set of state transformation rules. A new empty root tag starts with the State1. From that on it's fed with either y or z (using functional dependencies) resulting a new state 1 or 7. If you add an subelement y the state changes to 7 which is not endable forcing you to add another element. etc.. State 1 endable : True y -> St 7 z -> St 1 State2 :7 endable : False y -> St 7 z -> St 1 Use this on a xhtml dtd and you'll get about 500 different states and a lot of instances. Luckily most elements are described this way: (PCDATA|div|form|...)* this means that the sate does not change after an element which should enable you to use foldr functions or such without type hackery (? I have to verify this).. Validation errors are denoted this way: * wrong element (1): "No instance for (Consume State4 (Elem B_T) st')" * more elements expected (1): "No instance for (ElEndable Root_T State4)" * invalid attribute: "No instance for (AttrOk Root_T AAttr_A)" * duplicate attribute: "No instance for (Text.XML.Validated.Types.DuplicateAttribute A_T AAttr_A)" * missing required attributes: "No instance for (Text.XML.Validated.Types.RequiredAttributesMissing Root_T (HCons (A RootAttr_A) HNil))" Using ghc head you can rebind >>= and >> and use a do like notation: #if (__GLASGOW_HASKELL__ > 608) #include "vxmldos.h" tDo $ runHtmlDoc $ vdo head $ title $ text "text" body $ vdo script $ X.type "text/javascript" >> text "document.writeln('hi');" h2 $ text "That's a headline, hello and how do you do?" -- br e eg a <br/> is not allowed here div $ vdo onclick "alert('clicked');" styleA "color:#F79" text "text within the div" div e return "That's nice, isn't it?" resulting in: returned value : "That's nice, isn't it?" xml : <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html><head><title>text</title></head><body><script type="text/javascript">document.writeln('hi');</script><h2>That's a headline, hello and how do you do?</h2><div onclick="alert('clicked');" style="color:#F79">text within the div</div><div/></body></html> where vxmldos.h includes some macros rebinding >>=, >>, return and lift If you want to jump in, test and give some feedback you're welcome. Grab the code from git://mawercer.de/vxml If you feel there is some documentation missing just ask. Sincerly Marc Weber

2 3

Re: [Haskell-cafe] What is the maturity of Haskell Web Frameworks
by Sterling Clover 04 Jun '08

04 Jun '08

> > hvac sounds interesting but at that time at least it was not clear > whether it was stable or would continue to be maintained. > > xhtml and HStringTemplate were overkill for what I wanted, so I > wound up > just using the FastCGI and CGI toolkits themselves. They are > surprisingly nice, and with a little bit of wrappers around them for > things like validating forms, have worked exceptionally well. > I'm in a position now where I can make a reasonable promise that hvac will not only be maintained but undergoing continued development. I just, for example, hooked in some basic postgresql support yesterday (although the changes are not tested/pushed to the repo yet). (Speaking of which, I noticed that the HDBC postgresql bindings don't set seState on an error -- is this intentional, or something that should be fixed up?) As such though, I also can't promise that hvac as it stands is officially stable, although most work I imagine that will be done on it will consist of extensions rather than API-breaking changes. I've also been working on a lightweight testing API for programs using the CGI monad, integrated with quickcheck. Although this project isn't "final" yet either, there's a working repo at http:// code.haskell.org/~sclv/cgicheck/ if anyone wants to play with it/use it. I plan to use this quite a bit to test hvac, and any applications produced using it. Additionally, the hvac code now has a nice, though also incomplete orm/dsl-type library for database access (also built on top of HDBC). When I feel more confident/polished in the code there, I plan to split it out and hackage it as well. Of course, folks with a little time/inclination who play with these things a bit and put them through the paces are a big help in working out the kinks such that I feel they're closer to "release- quality" (even if that "release" *is* only 0.1). :-) Relatedly, I'd be very interested in developing a single common library for encoding/escaping/decoding/unescaping of common web formats (urls, javascript, basic xss escaping, rss-valid character escapes to html-valid ones, etc.) that uses a lightweight invertible combinator approach as described in Pierce's work on lenses (various papers at http://www.seas.upenn.edu/~harmony/) such that the encode/ decode methods are correct-by-construction bijections. There are various encoding bits scattered among the Haskell web libraries at the moment, each with varying degrees of correctness and conformance. It would be nice to direct energy here to a single centralized project, which would have some upfront architecture, and then, unfortunately, probably no small degree of spec-translation. If anyone else is interested in working on such a thing, I'd be delighted for ideas/collaboration (or better yet, if someone just picked up the idea and ran with it themselves!) (hmm... maybe galois has some internal libraries it wouldn't mind sharing as a partial basis?) Regards, Sterl.

1 0

Re: [Haskell-cafe] Re: RFC: A standardized interface between web servers and applications or frameworks (ala WSGI)
by Michaeljohn Clement 13 Apr '08

13 Apr '08

Adam Langley wrote: > On Sun, Apr 13, 2008 at 4:59 AM, Johan Tibell <johan.tibell(a)gmail.com> wrote: >> * Using a different set of data types would work better. > > Give that this is Haskell, I'd suggest more types ;) > > HTTP headers aren't just strings and, at the risk of tooting my own > horn, I'll point to the Headers structure in [1]. That is one of the things I don't like about Network.HTTP, which also enumerates header fields. It is inconvenient to have to look up the names in the data type, when the standard field names are already known, and it makes using non-RFC2616 headers less convenient. Automatic parsing of header fields also makes unusual usage inconvenient, (for example the Range header support in [1] is a profile of RFC2616.) I think those kinds of features belong in frameworks; they will be more of an annoyance than a help to anyone that is writing to the WSGI layer. > Likewise, URLs have > lots of structure that should just be handled in one place [2] Yes, I think should be parsed to the level of granularity specified by RFC 2616 (i.e. scheme, host, port, path, query string) and anything more (like parsing query strings) should be handled by frameworks. > > [1] http://darcs.imperialviolet.org/darcsweb.cgi?r=network-minihttp;a=headblob;… > [2] http://darcs.imperialviolet.org/darcsweb.cgi?r=network-minihttp;a=headblob;… > > > AGL > -- Michaeljohn Clement

1 0