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. On Thu, Feb 25, 2021 at 3:28 AM [email protected] <[email protected]> wrote: > Could you cryptographically sign the serialized form or something like > that? > > On Monday, February 22, 2021 at 8:59:29 AM UTC-8 [email protected] > wrote: > >> 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/0854aacf-b390-4bc7-8b7a-6b114c19bb5cn%40googlegroups.com > <https://groups.google.com/d/msgid/racket-users/0854aacf-b390-4bc7-8b7a-6b114c19bb5cn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAJYbDamn8SVqi6Zo3wnHMQL-NLNr1VM4AC4pqpVVyA%2B18HnQNw%40mail.gmail.com.
