the future of #lang web-server

[je...@lisp.sh]

#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, 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

[Jay McCarthy]

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.

[jackh...@gmail.com]

Could you cryptographically sign the serialized form or something like that?

[Jay McCarthy]

That's a cute idea. We do something like that already when sharing the serialized continuation with the world, but Racket could conceivably do that when it `read`/`write`s things, although it would be very odd.

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/0854aacf-b390-4bc7-8b7a-6b114c19bb5cn%40googlegroups.com.