What’s the deal with this website?

21 Feb 2008

See http://www.updike.org/blogg/ or

darcs get http://www.updike.org/blogg/

to get the code for my Haskell Web Framework (working title). Not cleaned up or Cabal’d or anything but it may prove useful to Haskellers out there. Available under GNU GPL v2.

27 Mar 2006

Code for this Haskell Web Framework (HWF) was posted here. Available under GNU GPL v2.

17 Mar 2006 emails

Various packages

I checked your web site and I understand that you are working on some
kind of web framework/wiki system in Haskell.

I am looking for something of that ilk for some new web applications
that I want to create and I have been researching a number of
Haskell-based web frameworks (HAppS, WASH, Flippi, etc.).

I saw some of these and thought they looked really cool. I think HAppS is supposed to be a real strong performer and allow use of databases of all kinds. On the other hand, my software is about simple text files as structured data so things are all maximally hackable at all times, but performance (i.e. hundreds or thousands of connections) is not the main goal (or even possible).

WASH looks really neat, especially since I believe there is an entire webserver written in Haskell doing all the work! In addition, they have a really cool CGI programming lib that allows you to create really short Haskell programs that do all the complicated threading of client state across server calls, which is pretty elegant. My software does this all by hand which makes it delicate. I hope some day to do things more the WASH/CGI way (monad for threading state, generating HTML and JavaScript glue for you, etc.).

I think I saw Flippi a while ago and thought it was neat that someone had a working Wiki-clone but I didn’t like the CamelCase link syntax and other things like that, so I made my own to deal with all my nit-picky design requirements.

I wondered if you are using any of those or if you are writing
your own and in the latter case if you plan to make it publicly 
available.

I haven’t really used those packages; for me doing it myself is a better way to learn and understand, but it takes a lot longer and everything grows gradually. Right now, mostly I am porting functionality over from my old all-Python/CGI version of my website with large feature improvements and aesthetic changes. Before, everything in Python was string based and hacked together to generate the pages. But now everything in my Haskell code is all structure-based (Document types, etc.) and then pretty-printed to XHTML. Basically, this is a single Haskell CGI program (a binary called index.cgi) that gets requests from Apache and then spits out pages. Nothing too exciting (except all these plans I have in my head...), but of course I like it because it’s my own personal jamboree of features (or, it will be, when I get to them...).

I wouldn’t mind posting the code if you care to look through it, but it is in need of some rewriting and refactoring and spring cleaning to update it to the nice version floating around inside my head... you probably know how that goes... In other words, it’s not in a developer-friendly library format, but you could hack at it and see where you get...

Boring details

In terms of features I am a bit more proud of, I like the XHTML/XML pretty-printing part because I can keep things very structured (in the Haskell code) and still have it generate really well formatted XHTML. In practice I noticed that other libs, e.g. the XML/HTML lib in HaXml, didn’t allow things like HTML comments (which are a necessity for PNG transparency in IE, i.e. conditional loading of JavaScripts) and XML dictates that <tag></tag> is the same as <tag /> but the morons at Microsoft wrote a parser for IE that breaks when the <head> of your page contains <link blah /> instead of <link blah></link> (same for <script>...</script> v. <script />). My point is that I’ve had to add special cases along the way to deal with IE’s idioticies, but the nice thing is that the higher level code where the pages are built doesn’t have to worry about this.

In terms of ideas of where to go with this thing, besides gluing together all these planned features, I really wish I could make a single library that let the developer build webpages at a really high level in Haskell and have it compile to XHTML+CSS+JavaScript all at once (like WASH/CGI but a lot more features and proven complex/beautiful pages instead of simple vanilla pages), but that’s a long way off. Basically, my approach is a lot lower level right now than I would wish, i.e. web things break easily and I have to maintain standards compliance manually as I add new features.

I guess the overarching design goal for my approach is to move a lot of the complexity and power of the website into the parser and markup capabilities (which is also slated for a full redesign/rebirth). Right now the content is all contained in specially marked up text files and the program converts these to nicely formatted pages. These pages are editable through the browser (I have a simple login system but I’m the only user). Part of the reason I made this fancy system (especially a featureful parser) is that I want a way to write all kinds of documents (articles, webpages for projects and things, math notes, Haskell source code itself as a document, links, quotes, etc.) and have "ideal" (standards compliant + human readable) HTML as well as publication quality printer formatted documents (i.e. LaTeX/PDF) all generated from a single source text file. The catch (why I don’t just input everything in LaTeX and use one of many TeX2HTML converters, or vice versa with HTML) is that HTML is far too verbose and not-high-level-enough, and LaTeX is better but still too verbose, i.e. for italics HTML is

<i>blah</i>

v. TeX which is

{\it blah}

v. my parser which reads in

//blah//

and spits out either of the above when needed. (But if you have a single / anywhere in your text that is correctly treated as a single slash character so you don’t have to escape it when you write casually.) So, in a sense, I want the marked up text files to feel like a sort scripting language of their own, but still really high level (i.e. structure- and document- and content based instead of like PHP where things are string based (low level) and so forth).

Back to the email

More in general, as I am very new to Haskell, I wondered if you could
give me some advice on the best tools/approaches to Haskell-based web
development.

(Well, I probably confused and overwhelmed you with too many details but it was fun to write out my ideas.) My advice would be to decide what you want more:

  • a working system soon with lots of features but a larger time investment of learning the APIs and reading manuals (in which case try WASH, HAppS, etc.) (which may not in the end have a wiki-system or web framework to your liking, so you’d have to do the work of learning these systems and implementing your own desired framework on top, that is, if it doesn’t already exist in these systems... not sure), or
  • understand what’s going on at all levels and controlling it, but taking a while to get enough functionality to have really useful software (I’m not quite at the state of true usefulness yet; I’m really really close, but not there yet, e.g. I’ve been needing to implement ’Add new page’ for weeks but I’ve been busy at work and been sick).

I took the latter path because I’m relatively new to Haskell (coming up on a year now, actually...) and this is partly how I’ve been learning Haskell. If I had more time and focus, all these planned features would be implemented and the code would all be clean and readable and I would use this software to write a book/tutorial on how to learn Haskell and build website-building software in the process. And then anyone who wanted could download the software and install and compile it and start playing with making their own webpages and then start hacking them in Haskell/"futuristic high-level scripting language that doesn’t exist yet". Unfortunately I’m not there yet.

Any info/tip will be very gratefully received.

If you want to take the same tack I took, I’ll offer up any code and advice on how to try things.

For example, I would recommend getting a simple static webpage spit out by a Haskell program, like

contenttype = "Content-Type: text/html; charset=utf-8"
httpheader  = contenttype ++ "\n\n"
main = do
   putStrLn httpheader
   putStrLn "Test title"
   putStrLn "

Hello world!

"

and then putting it in a place where Apache can get to it (this isn’t hard but is annoying to get working sometimes, if you have problems I could help you), then point a browser at it and see if it works.

Once you have that, maybe next would be to see if you can make pages in a structured manner in Haskell and have some module to generate the HTML for you (my XHTML module, or a really cool one mentioned recently here. Then try learning about parser combinators and use Parsec (my favorite parser combinator lib) to parse the text files and generate structured documents which then get converted to HTML and sent to the browser by the program you’ve been writing. Something like that.

Thanks in advance for your help in this matter.

Thanks for your questions and I hope I’ve been of help... Please ask more questions if this stimulated your interest or if I’ve made things more confusing instead of less. I’ll post the code soon.

   Jared.

18 Mar 2006 emails

The kind of web framework that I am thinking of is more along the AJAX
model than the CGI one.

I agree; CGI feels very arcane these days :)

So, in essence, a very simple server that
returns raw data in XML or JSON format that is then rendered using
HTML/Javascript or Flash on the client side.

That’s a really great idea. I really want to create more flexible pages using AJAX instead of CGI but I don’t have enough experience developing with it. If you pull anything together (even if it’s simple) let me know. I would love to learn more about it from the Haskell point of view.

So, in essence, a very simple server that
returns raw data in XML or JSON format that is then rendered using
HTML/Javascript or Flash on the client side.

Are you planning on manually writing your HTML/JavaScript? You could try to make the same program that serves the XML requests generate the HTML and centralize the functionality together to keep your web apps more modular.

I think it would still be neat but it would be even cooler if you could write all the client and server code in a single Haskell program and then the Haskell AJAX/framework/server library would generate all the client side stuff (JavaScript and HTML, etc.) and server side code too, and you’d never have to touch the JavaScript/HTML.

CRAZY FUTURISTIC IDEA

on my list of things to work on (you’re welcome to attack it and think about it too):

This is something I think would place Haskell head and shoulders above all other programming languages: if you could just write applications in high-level Haskell code and it generated all the glue to make all the calls to the server and such; bascially it wouldn’t matter which parts were client or server side, your program would just run in a browser much the way people write software with GUIs and don’t worry anymore about the low level details of mouse interaction, displaying menus, etc.

If you check out the source code examples in http://www.informatik.uni-freiburg.de/~thiemann/haskell/WASH/WASH-CGI-gallery.html you’ll see what I’m talking about. The code is really simple and high-level, and all the glue is generated for you.

Now, to take it a step further, it would be really cool if you could make programs like the examples in http://www.md.chalmers.se/Cs/Research/Functional/Fudgets/Intro/ especially something like http://www.md.chalmers.se/Cs/Research/Functional/Fudgets/Intro/ex8.html but on the web. Notice how short the code is! But instead of running a program on your computer, this (hypothetical) AJAX package would spit out a webpage that looked like that calculator, and then when you clicked the buttons it would send the events to the server and the server would handle them, compute some calculations, and then send it back using AJAX magic. You could write powerful, flexible web applications and spend time on the program logic instead of the glue.

Part of the problem here has to do with program state and session management as well as scale (many users per program instantiation instead of the usual single user). I still think that not enough AJAX web stuff is high enough level (as in, really really short and program logic based instead of all the low level web glue, etc.). In comparison, this ideal AJAX framework would be more like a compiler from web app language to HTML and JavaScript (instead of to machine language or bytecodes like most compilers).

I had been thinking along these lines for some time but I didn’t mention it in the context of AJAX before but while I’m thinking some grandiose thoughts, I might as well imagine things being really awesome! (In addition I was thinking it would be cool to compile Haskell to JavaScript so then you could actually write arbitrary things in Haskell and run them in browsers! YHC is a really recent Haskell ccompiler with small bytecodes and I want to write a JavaScript runtime system so ultimately we could run Haskell compilers and Haskell code anywhere. At first things would be pretty slow but I’m sure it would get faster with time and new technology. It seems I have too many half finished ideas, which is why I’m sticking with CGI for now instead of jumping into AJAX but I still want to do that when I finish all these other projects along the way.)

More links

By the way, I found some more leads on Haskell web framework stuff:

This recent thread talks more about your general question of Haskell and web frameworks stuff.

Someone on the thread mentioned this project. This software looks like a really good place to start playing with things. I’d forgotten about it but you should check it out if you haven’t already...

   Jared.