I am new to haskell, and now working on embedding haskell into html. Thus we will write webapp using haskell as server-side language like php. Here I explain my plan and ask some questions, looking for experienced ones to discuss with. It is not proper embedding lines of haskell code into html (like php). Because we would not know what to output, as it is not a procedural language as php. I think the proper way is using a single tag containing a haskell expression (usually a function name) each time of needing haskell. I call it "hasp" standing for "HASkell Page" :). It should look like: <html> <head><title><?hasp genTitle?></title></head> <body> ...some html... <?hasp getDataFromDB?> ...some html... </body> </html> And the functions ("genTitle", "getDataFromDB") should be implemented in "/same_dir_to_hasps/hs/same_name_to_each_hasp.hs" . It just like the templates in php. There are two possible ways to implementing the mechanism: compiled-CGI, and interpreting(or Just-In-Time Compilation) 1. Complied-CGI: use a preprocessor to combine the hasp templates and hs implementations, then compiled by ghc to generate cgi-bins. That should be easy for me to implement. 2.Interpreting (or JIT-Compilation) I prefer this method because modern web-scripting programmers should be familiar with it. The browser request for somepage.hasp, and Apache knows giving it to hasp interpreter to handle. I am facing to the dilemma between interpreting or JIT-Compilation. The best situation is a perfect haskell interpreting procedure written in haskell. I am trying hs-plugins, and I hope it will help me a lot. Or any other "haskell interpreting procedure written in haskell" you can tell me? The trouble about JIT-Compilation is that hasp-handler must call ghc through OS shell commandline using System.Cmd, and that is not proper in Apache cgi handler(lots of stuff to configure). BTW, if the "haskell interpreting procedure written in haskell" does not work well, I could use cmdline "ghc -e some_expr file.hs" to evaluate the expr, though an ugly way. And in that case, we would face to the problem of "external cmd of CGI" again. -- Sincerely, Forest Liu(�����S)