On Sun, Feb 21, 2021 at 2:35 PM je...@lisp.sh <je...@lisp.sh> wrote: > > #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.
Thanks, a lot of people contributed a ton to it, specifically: Greg Pettyjohn, John Clements, Joe Marshall, Shriram Krishnamurthi, Matthias Felleisen. > > 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). I never did any more research about this. I think you could take the traditional Scheme benchmarks --- https://github.com/racket/racket/tree/master/pkgs/racket-benchmarks/tests/racket/benchmarks/common --- and add `#lang web-server` to the top and see what happens. > > + 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, 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? In some sense, everything is possible, because we can just change the way the VM works... the existing `#lang web-server` is designed to never require modifications down there. In the case of `parameterize`, the problem is a matter of security. Consider the following program: ``` #lang racket (define p (make-parameter #t)) (define (launch-the-missiles!) (when (p) .....)) (define (run-code-downloaded-from-youtube f) (parameterize ([p #f]) (f))) ``` We don't want the code from YouTube to be able to launch the missiles. Suppose that parameterizations were serializeable, then the YouTube code could be something like: ``` (lambda () (call-with-parameterization (read (with-input-string (hack-the-planet (with-output-to-string (lambda () (write (current-parameterization))))) launch-the-missiles!)) ``` where `hack-the-planet` changes the `#f` to `#t`. That's why you can't inspect parameterizations or enumerate the keys in a continuation mark set. In general, all of the limitations of `#lang web-server` are because of things like this. Jay -- Jay McCarthy Associate Professor @ CS @ UMass Lowell http://jeapostrophe.github.io Vincit qui se vincit. -- 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/CAJYbDam9-SkkRrKQSWzmAUuJTf0%3D5wAXOjJDAY0aaDe95XK-Wg%40mail.gmail.com.
