On Sun, Feb 21, 2021 at 2:35 PM [email protected] <[email protected]> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAJYbDam9-SkkRrKQSWzmAUuJTf0%3D5wAXOjJDAY0aaDe95XK-Wg%40mail.gmail.com.
