Hacker News Reader

Comment by remontoire | Hacker News Reader

This approach to webdev (continuations) could be so cool. I just wish there was a framework on the level of django/rails so that I could feel comfortable using it for a large product.

View on HN

The Lift web framework in Scala is somehow similar in that aspect. It has been used on multiple bigger sites like foursquare. I really like the approach compared to MVC.

Racket does stateful and stateless servers, and the continuations are either stored on the server or the client per which type you choose to implement [1].

  [1]  https://docs.racket-lang.org/web-server/

Paul Graham's startup (way back) did this and he claims it was a competitive advantage. These days it doesn't feel like this approach offers enough.

Not just way back; HN uses continuations. (Not in many user-visible places any more, but every link on the front page used to be one—expired "next page" continuation links were a frequent source of grumbling.)

Note that you don't have to expire continuations, necessarily—you could actually persist them statelessly (i.e. without server-side state), by shipping their encoded representations to the client embedded into HMAC-signed links. You're basically giving the server a raw bytecode-eval endpoint, and then making sure that it only accepts code you yourself wrote. Kind of a crazy strategy compared to the standard predeclared REST API, but interestingly flexible.

> their encoded representations

What's an example of such a representation?

Now that you mention it, I can't think of very many languages that define a language-standard persistent encoding of a continuation on a closure. One that I can think of is Erlang.

Here's the relevant section of the Erlang "External Term Format encoding" spec: http://erlang.org/doc/apps/erts/erl_ext_dist.html#id95269

Said spec is nominally "about" the wire protocol Erlang nodes use to communicate with one another in a distributed system. But the ETF format defined there is much more general, and is used all over the place (e.g. when persisting values in Erlang's DETS tables to disk.) It's what you get when you call Erlang's global term_to_binary/1 function.

Erlang's ETF could probably be most closely compared to Python's "pickle" format. (Though, sadly, you can't pickle a lexical closure in Python.)

That's interesting; I didn't know that any language did that.

I really like your design idea, and it would be fun to think of an application for which it was the best fit.

Even Erlang's approach is sort of a hack. As can be seen from the format spec, Erlang doesn't actually encode the AST of the closure; instead, they ship a reference to a symbol-table ref in a module. Erlang's closures are all implicitly hoisted out into their own gensym'ed functions and then exported from their module to allow for this. Each node assumes the other nodes in the same distributed system all have access to the same modules (not that they all necessarily have it loaded, but that they can load it Just-In-Time when dereferencing the closure) and so the export-table reference can be turned back into a handle on the closure at the receiving end by looking it up in its module.

What this all means is that, although Erlang nodes can rehydrate closures from other nodes that are running the same code, they can't rehydrate arbitrary closures defined and serialized at your personal REPL running different code. (Which defeats half the purpose; you can't then use dehydrated closures as an arbitrary query/callback/RPC syntax between Erlang-based microservices, unless they all share code.)

On the other hand, there's nothing explicitly stopping the Erlang Run Time System from supporting the full version, where a closure is dehydrated as its AST (plus free vars, as in ETF encoding.) And so this is exactly what Elixir does. Yet another reason Elixir is an interesting language.

So what's encoded are the closed variables along with the gensym'ed name of the closure (effectively a pointer to the code)? If so, that's pretty useful. For some cases it's better than serializing the code, because then you don't have to pass a copy of the code around everywhere, only the state that you don't keep a copy of.

Never used it but Tir (https://github.com/mongrel2/Tir), which runs on top of mongrel2, allows you to use continuation style if you wish to do so.

Tir is currently without a maintainer and won't even install from the rocks file in the repository.

The FAQ doesn't mention anything about this -- can you explain how Seaside uses continuations?

It uses continuations to hide the asynchronous nature of web requests and allows the flow between pages of a web app to be written in an imperative style.

"Inverting back the inversion of control" describes the idea (in Scheme) https://pages.lip6.fr/Christian.Queinnec/PDF/www.pdf

Paul Graham used the idea in ViaWeb - and apparently got a patent on some aspect of it https://web.archive.org/web/20060323211251/http://paulgraham...

IIUC HN uses them too.

There are a couple of continuation-based web frameworks for Ruby (Borges, Wee), but they're old and abandoned as far as I know.

I suspect it didn't catch on because (1) people are afraid of continuations, and (2) web apps are typically designed in at least a pseudo-REST-like style, so the paradigm of "asking" the user (like "await" in ES6) isn't needed very often.

But it's a cool thing to be able to do, especially for funnel-type flows, and other types of more complex session-based interactions.

I wonder if there are any JavaScript inversion of control things for client side code. I've been working for the past week on a signup funnel with React and Flux, and it's just a big explicit state machine... which kind of works, but is also kind of tedious.

I think 'Ajax' killed continuation based web servers. See Avi Bryant's thoughts in this area from back then: https://web.archive.org/web/20060610180033/http://smallthoug...

There were client side JavaScript continuation like things. Back in the mid-2000's there was Narrative JavaScript. I used it to implement threads and Alice ML style futures/promises on the client side: https://bluishcoder.co.nz/2006/06/05/more-concurrency-in-nar...

There's also Nagare in Python: http://www.nagare.org/trac/wiki/NagareTutorial

IIRC it uses Stackless Python, not the standard interpreter, and I don't know how active its development is.

Reply on news.ycombinator.com