Christopher Done wrote:

...

webwire is an experimental web framework based on the functional reactive programming library netwire.  It uses WAI under the hood and right now features only a subset of the very basics of what you need to write web sites

Are you going to provide any examples?

Soon, yes. Right now I'm focussing on finishing the basics. As soon as I have preliminary form support, I'm going to write an example application. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/

Michael Snoyman wrote:

Nice to see another project taking advantage of WAI and Shakespeare. I look forward to seeing some example code as well, though I personally am very wary of continuation-based frameworks.

AFRP uses continuations under the hood, so you can view webwire as continuation-based to some extent. But out of interest, why are you wary? This is highly experimental work, and I see some problems coming: * Lower performance, though that can be fixed. Right now I'm getting up to about 8000 requests per second using apachebench with -n 10000 and -c 1000, which is probably not enough for high volume sites. * Sessions are a runtime-only phenomenon. This is a more serious problem, for which I don't currently have a general solution, though for most applications specialized solutions can be written. * FRP and netwire in particular have a steep learning curve. If you see any further potential problems, I'd be very grateful, if you'd let me know. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/

Michael Snoyman wrote:

I'm not sure what you mean by runtime-only, could you clarify?

The session is inherently bound to its current continuation, and the continuation is a function, i.e. cannot be serialized. This is a generalization, which comes with the price that sessions are lost, as soon as you quit the program. In other words: Applications desiring to save the state need to capture it as something serializable to be able to restore sessions (at least partly) later on.

The reason I'm wary of continuation-based frameworks is that (at least from what I've seen) they are purposely non-RESTful. I know REST is a buzzword, but the other way to put it is: you're going to end up working against most of what HTTP is doing. There are good reasons why HTTP is stateless, and that shouldn't be circumvented lightly.

Yes, this is indeed a problem with the traditional explicit continuation approach. However, webwire solves this problem mostly, because continuations are implicit and bound to the current resource. You will see the effect of continuations mostly in global or resource-specific stuff like authentication, forms, sessions, etc. In other words: What FRP buys you here is that you can write your applications in a dialog style. Resource URIs need to be managed by the application developer and are not in any way dealt with by webwire.

I don't want to go too far on this right now, as I'm not an expert on cont-based frameworks, and I'm certainly not sure how webwire works. But from what I've seen in the past, you end up with ugly URLs and bad caching behavior. I think web developers *should* have to think about the fact that a page request is an inherently stateless operations, and storing state data should be a huge exception[1], not the norm.

As noted above, the URI problem is not an issue in webwire. And as for the caching, one really great thing about the FRP approach is that you can actually infer the change rate of a resource to some extent. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/

Daniel Patterson wrote:

I'm also excited to see examples. Even simple ones!

Alright, I have written some examples: http://haskell.org/haskellwiki/Webwire

Based on my understanding of FRP (which may have little bearing on what webwire actually does, just what I hope it does), what makes it really different is that it is relatively stateless itself - that's kind of the point, that you model your system as a bunch of data sources, and you can change them with pure functions, and when you do that they will be updated anywhere you are using them without any explicit imperative stuff. I'm not sure how that translates to a server-side applications (the only web examples I know of have been javascript-based), or webwire itself so I'm curious to see how this works.

Interestingly it's quite the opposite. Wires in netwire are inherently stateful, but offer an interface, which hides that state almost completely. Wires are essentially time-varying functions. In fact, a stateless wire is simply a function or a computation in the underlying monad. What makes FRP so great is that you observe this statefulness in terms of data dependencies. Very little imperative programming, yet high performance and an incredible expressivity. See in the examples how quickly I was able to write an application, which limits the average request rate over the last ten requests for every session individually. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/