Let other people think about those problems

.. and then you get problems which you can't solve without changing language semantics and hacking compiler code

I don’t think so. With my Scala experimentation it all worked pretty smoothly so long as you didn’t try to serialize things that couldn’t be serialized.

Really? Did you try Scala JS as well?

No, the requirement would be that the continuation would be easily serializable, both for JVM and JS

If not it would be a runtime error

That’s all I’m asking for, provide serialization compatibility between JVM and JS

That's very complicated thing. To reach this goal you should make both backends to generate similar code. I mean, up to similar order of try/finally blocks, invocations, etc

Well, really only the data needs to be compatible, right? Not the code?

The code!

The code has to be compatible. You are serializing a computation!

You are serializing the state at a particular moment in a computation, state is data

State is tightly coupled with code

How are you going to denote the suspension point?

Do you work on the coroutines code?

How are you going to denote local variables? Synthetic variables (like variables generated for

for

statement)?

I work on coroutine code for JS

So then you should tell me how to solve the problem 🙂

There's no easy soltion. The only solution is to make JVM and JS backend fully compatible regarding the generated code. It's not a short-term goal, it might be even non-goal, and it's a damn hard thing, that I'm not sure worth something.

I won’t argue with you that it’s hard, you are far more qualified than I am to make that determination

But I’ve built a lot of websites, and I’m familiar with today’s frameworks for building webapps, React, all of that, and it’s really awful.

In the future I think people will be able to build webapps without having to think too much about what runs in the browser, and what runs on the server - any more than they need to worry about what CPU register a particular variable is stored in.

To get to that future I think we’ll need continuations that can migrate between browser and server

They'll have to think! I asked: what about security?

Perhaps an explicit designation of which functions cannot be executed on the client

@Trusted

What if the can be executed with certain parameters?

What about functions that client calls from server?

Or maybe @Untrusted would be better 🙂

Well, isn’t that really about whether you can trust that code will do what it’s supposed to?

And eventually you realize that your abstraction is leaking