#lang web-server is brilliant. This #lang is, in my view, a really excellent example of Racket's take on language-oriented programming. I find that the performance of continuations is just fine, given my limited use of them, and after a while you get used to the limitations and just program around them.
One thing that always bothers me about #lang web-server, though, is that there are a lot of provisos in the documentation. I'm talking about section 3.2, "Usage Considerations", of https://docs.racket-lang.org/web-server/stateless.html, in the part after "However, there are some considerations you must make." Here a couple of questions: + " [#lang web-server] will create an immense number of lambdas and structures your program did not normally contain. The performance implication of this has not been studied with Racket." This seems to me like an interesting research question. Has this question been taken up? I've tried taking a look on Google Scholar for any follow-up. I looked at citations of Jay's "Automatically RESTful web applications" and "The two-state solution: native and serializable continuations accord", but nothing stuck out to me (...which is not to say that there may have missed something). + Some limitations of #lang web-server seem don't seem obviously necessary, at least to someone who's not very familiar with the precise details of the underlying program transformations. You get used to them, but you wonder if there's some accessible world in which they work. For example: "You may not use parameterize <https://docs.racket-lang.org/reference/parameters.html#%28form._%28%28lib._racket%2Fprivate%2Fmore-scheme..rkt%29._parameterize%29%29>, because parameterizations are not serializable." Is that inherently so (that is, there's no way around that, no matter how clever you tweak the program transformations on which #lang web-server rests), or is that just a conequence of the particular approach taken (maybe it's possible, but no one has done it yet). Has there been any fresh thinking about these limitations? Jesse -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/593786e4-7aca-4fe9-8b29-e58b9ff555dbn%40googlegroups.com.
