WASH/CGI

WASH/CGI is a comprehensive web application framework for Haskell whose focus is to abstract away the creation and processing of HTML forms. Using Haskell’s type system, WASH/CGI can determine the expected type for form inputs and automatically validate them, re-displaying the form with appropriate error messages if necessary. To further aid development, it provides pure-functional wrappers over both cookies and server-side persistent state and uses the type system to guarantee that, in most cases, all application pages are valid XHTML.

Though WASH/CGI and Continue programs share a similar structure — user interactions can occur at arbitrary points in the code — WASH/CGI relies, not on continuations, but on saving a log of past inputs and replaying the web application from the beginning for each interaction, referring to the log when necessary. As Haskell programs are deterministic, this strategy gives consistent results, but with the cost of duplicate computation. WASH/CGI conserves server resources by saving the log in a hidden form field, with the consequence that, unlike Continue web applications, WASH/CGI applications cannot maintain environment state when user interaction takes place through hyperlinks. (Though it is possible to use JavaScript to make hyperlinks that act like form submission buttons, this trick does not work for situations such as our e-mail verification example.) For security reasons, the contents of the hidden form field are encrypted, though the strategy the authors claim to use — one-time pads — would require that the webserver keep, byte-for-byte, the same amount of data present in the clients, completely eliminating any resource savings gained by storing state in hidden form fields.

---

Highlights

• Type system used to ensure page validity
• Inputs from form fields are validated and given types
• Stores “session” data in hidden form fields
• Neat use of static type inference to avoid declaring types or validators for form fields
• The once operator neatly deals with transactional stuff by collapsing the result of a series of interactions into just the result
  

Drawbacks

• Needs a whole separate system (decision trees) to deal with forms where not all fields are validated. (Example: choose between two payment methods w/ radio button, don’t need to validate the unselected method’s fields)
• Has to invent an entire persistence layer to compensate for Haskell’s pure-functional nature.
• OMG, this can’t be practical: the entire program is replayed with each new input
• A true one-time pad has to be the same length as the data it’s encrypting, so there’s no space savings if that’s what they’re actually doing
  

Opinions and Speculation

• Seems much more interested in form interactions
• Authors claim that mismatched input form names is a “common source of errors.” I disagree. It’s a problem easily solved by defining a string constant that’s your input form name, and using it when you create the form and when you extract values from the request. While a mechanism for automating it is as helpful as pretty much any little abstraction, it is not a huge deal and not worth the loss of human control over form field names. Using well-known form field names helps users who use programs that automatically fill out forms (inserting name, e-mail address, home address, etc.)
  
• This is totally indecipherable type systems and semantics