jhc looks interesting. It's an optimizing Haskell compiler "...that aims to produce very efficient code as well as explore novel compilation techniques in an attempt to make them practical."
Two things from the site that interested me were:
- Produces 100% portable ISO C. The same C file can compile on machines of different byte order or bit-width without trouble.
- No pre-written runtime. other than 20 lines of boilerplate all code is generated from the Grin intermediate code and subject to all code simplifying and dead code elimination transformations. As a result, jhc currently produces the smallest binaries of any Haskell compiler. (main = putStrLn "Hello, World!" compiles to 6,568 bytes vs 177,120 bytes for GHC 6.4)
Alessandro Colomba has announced the release of version 0.33 of SISCweb.
SISCweb is a continuation based web server written in SISC, a Scheme implementation that runs on the JVM.
New features mentioned in the release announcement include:
- A new module siscweb/image provides procedures to send images from java.awt.image.RenderedImage objects or from files.
- A new API wraps and "scheme-ifies" all methods on the Request, Response, Session and ServletContext objects. This makes it easier to access POST data through a scheme input port, or to set the response buffer size, or set Java or Scheme session attributes, for example.
- A new procedure forward/dynenv/store! can be used in place of the @href-p attributes or plain forward/store! when one desires to capture the dynamic environment of a closure, e.g. SRFI-39 parameters. Because SISC 1.13 solves a few serialization bugs, it is now possible to use SRFI-39 parameters in place of session attributes for tracking state. This is particularly useful in event-based programming (e.g. AJAX). See the Counter example code (no pun intended).
- Improvements to response writing improve performance for markup, graphviz, images.
- Improvements to XML/XHTML output.
- A new (backwards-compatible) API for siscweb/config.
- Updated documentation throughout.
- Some internal refactoring.
I've written in the past about the ways of pushing events from the server to the web browser. Recently a this model of usage has had a term defined for it called 'Comet'.
My plan was to have a library that modelled a web page as an asynchronous Erlang process. Other Erlang processes can send it messages using the standard Erlang constructs and the clients browser would process these messages. I put a proof of concept here.
This model of usage is becoming more and more popular evidenced by the number of Ajax based chat applications as well as the new 'Comet' term. The latest release of the Java based DWR library has added functoinality similar to the message passing example mentioned above.
DWR 2.0 allows what they are calling 'reverse ajax'. A simple to use API that enables the web server to call javascript functions on the browser.
The big new feature is Reverse Ajax: DWR 1.x allowed you to asynchronously
call Java code from Javascript. DWR 2.0 builds on this to allow you to
asynchronously call Javascript code from Java. Reverse Ajax makes writing
interactive applications much easier. Reverse Ajax makes writing interactive
applications much easier. It can use polling or Comet (long-lived HTTP)
queries.
Haskell gets more interesting every day. In the Haskell Weekly News was an announcement of HAppS, a Haskell Application Server. A nice list of features:
- HTTP Application Server
- Performs better than Apache/PHP in our informal benchmarks (thanks to FastPackedString), handles serving both large (video) files and lazy (javascript) streaming, supports HTTP-Auth, and more.
- Mail delivery agent with integrated DNS resolver
- Stop worrying about making sure a separate local mail server or DNS is up and running to delivery your mail. HAppS takes care of making sure your mail is delivered as long as your application itself is running and makes sure no outbound mail is lost even with unplanned restarts.
- XML and XSLT
- Separate application logic from presentation using XML/XSLT. With HAppS, you can have your application output XML (via HTTP or SMTP) and handle style/presentation via separate XSLT files at runtime. HAppS takes care of doing server side XSLT for outbound mail and HTTP user-agents that don't support it client side.
- SMTP Server
- Handle incoming email in your application without worrying about .procmail or other user level inbound mail configuration hackery. Just have the HAppS.SMTP listen on port 25 or have the system mail server SMTP forward mail for your app to some internal port.
- Monadic ACID transaction service
- Write apps as a set of simple state transformers. MACID write-ahead logging and checkpointing make it easy for you to guarantee application integrity in the face of unplanned outages. MACID even guarantees that your side effects will be executed at-least-once if they can complete within a timelimit you define.
- Session Service
- Define bits of per-user application state that automatically expire after time limits you define. No more manual housekeeping of session data!
- (Experimental) Table and Index
- Do relational operations safely on in memory Haskell Data.Set(s) rather than dealing with an external SQL relational database. Define custom indices for your Haskell datatypes (e.g. geographic/geometric types). Use in combination with MACID for a robust relational DBMS customized for your application.
Isaac Jones writes about the release of Hafs, a Linux filesystem written in Haskell.
In the course of developing a web server for an embedded operating system,
Galois Connections had need of a filesystem which was small enough to alter
to our needs and written in a high-level language so that we could show
certain high assurance properties about its behavior. Since we had already
ported the Haskell runtime to this operating system, Haskell was the obvious
language of choice. Halfs is a port of our filesystem to Linux.
