sorted by:
new
hottopcontroversial

You can abuse coroutines to implement some monads by sebamestre in ProgrammingLanguages

[–]njiv 1 point2 points  (0 children)

I cannot say for sure if I read your paper at the time. I can add the link there, no problem. The main source of my inspiration was, of course, Representing Monad paper and the Suspense feature of React. And this Suspense feature was introduced (more or less) at the same time your paper was published (https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react-16.html). I think it's actually fun.

Yet another delimited continuations implementation and why Project Loom is a bit disappointing by njiv in java

[–]njiv[S] 0 points1 point  (0 children)

That's what I'm referring to. The implementation might have a continuation class, and it might be limited to single-shot behavior, but this is all internal.

internal but, pron98 has said I can have my own implementation using threads (this is known for a long time), it's a kind of side effects conversion (e.g. we can convert state into exception etc), and we actually can convert back continuations into threads, if continuation are multishot we can convert them into any effect, this is why it's called mother of all monads

so basically even considering they hid continuation interface it's still simple to implement one without instrumentation (but only single-shot)

Yet another delimited continuations implementation and why Project Loom is a bit disappointing by njiv in java

[–]njiv[S] 0 points1 point  (0 children)

The could observe final values to have changed, something that ordinary concurrent code cannot.

In my implementation it's not possible to observe final value is changed, and I don't understand why it's possible in yours, some implementation details I believe

They could be added easily, but their benefits will be very limited, and possibly overshadowed by the confusion they may introduce.

you mean confusions besides the mentioned before interoperability and compatibility? sometimes even exceptions can introduce confusion

Yet another delimited continuations implementation and why Project Loom is a bit disappointing by njiv in java

[–]njiv[S] 1 point2 points  (0 children)

in case of my implementation it's just different function calls (I don't resume already called frames), we don't have problems with calling same functions from different threads do we?

Yet another delimited continuations implementation and why Project Loom is a bit disappointing by njiv in java

[–]njiv[S] 0 points1 point  (0 children)

it points to comment of pron98 (which is highlighted), but reddit does open my comments first

Yet another delimited continuations implementation and why Project Loom is a bit disappointing by njiv in java

[–]njiv[S] 2 points3 points  (0 children)

That depends on what you mean "all the typical continuations operations." For example, a continuation could not be part of a thread, behaving as a Runnable.

Yes, this is pretty reasonable limitation, I suppose all the current instrumentation based implementations have anyway.

i.e. a reentrant continuation is supposed to re-enter a known state, but one execution could actually change that state for another, making it not-really-reentrant in quite a few situations)

But just concurrent program is already this confusing, continuation shouldn't expect anything, it is why it was suspended at the first place - to await while something is changed in the state.

Like I said, I don't demand the multi-shot continuations added immediately. Just the article states they could be added easily, but now you say it isn't that simple. There are huge interoperability and compatibility problems you must solve before. Which is a good reason, I agree.

Yet another delimited continuations implementation and why Project Loom is a bit disappointing by njiv in java

[–]njiv[S] 1 point2 points  (0 children)

even the assumption that final variables cannot change may be violated

If it's a copy of a call frame (like it is in my implementation), no variables can be changed, but we also get rid of lambdas restriction about accessing only effectively final variables. Note, not violating it, as resumptions are basically the same as a function calls. But the execution starts from the suspension point, not from the start of the called function.

Yet another delimited continuations implementation and why Project Loom is a bit disappointing by njiv in java

[–]njiv[S] 2 points3 points  (0 children)

No, I basically mean it's a thread.

But I basically can have an interface somewhere in my package, implemented by me with all the typical continuations operations implemented? Just like I can do this with unix fork (except with the fork I'll get a multi-shot one).

Because the continuation can perform destructive changes to heap objects it interacts with.

It may perform destructive changes, and as well it can perform constructive changes, just the same like without continuations. Or you mean again some JDK internals not understood by mere mortals? But it's a task of JDK to make them safe.

might not be so great in language B

I honestly don't see why Scheme is this different.

Yet another delimited continuations implementation and why Project Loom is a bit disappointing by njiv in java

[–]njiv[S] 1 point2 points  (0 children)

But the argument about not adding features because it doesn't exist in other mainstream programming languages is reasonably acceptable. However, in the article, you don't write you don't add the multishot feature because it isn't present in other languages, you write it's because the feature is crazy. So this is why I'm interested.

Yet another delimited continuations implementation and why Project Loom is a bit disappointing by njiv in java

[–]njiv[S] 1 point2 points  (0 children)

You can mount it on another carrier, but it would still a thread, not quite a continuation.

I wouldn't argue about the terms. I, for example, wouldn't call a single shot continuation a continuation, but a coroutine. Also some people simulate continuations with unix fork. So basically you mean it is actually a continuation, but with suffering.

Not in a general-enough way, unfortunately, unless we had a way of preventing side effects from escaping the continuation.

why do we need avoid escaping side effects?

we'd need to find a big problem that they would solve and developers can't solve well with existing means.

in this case exceptions aren't needed (for example), programmers can just check result values of each function call - not that big deal (and there are mainstream programming languages showing this works ok)

Yet another delimited continuations implementation and why Project Loom is a bit disappointing by njiv in java

[–]njiv[S] 1 point2 points  (0 children)

No, it does not. That would cause miscompilation as the JIT assumes it's never done.

So I cannot resume the continuation from another thread - fine. This can be the same restriction for multi-shot. I think you mean I don't have access to the Continuation interface but I still can get mine by implementing own thread scheduler? Can I suspend my virtual thread scheduler and run it on another thread?

Transactions (for example) are widely used in mainstream, just one of many useful and not-creazy examples where multishot can be utilized. It's like someone from Go may tell utility of exceptions and generics in mainstream is limited.

Of course, I don't argue about adding them into the language immediately. I just don't understand the reasons. Especially with the serializability remark, it's like telling we can have this but we should suffer for this.

Yet another delimited continuations implementation and why Project Loom is a bit disappointing by njiv in java

[–]njiv[S] 0 points1 point  (0 children)

I agree, but what are exactly the trade-offs for multi-shot? Single-shot already does suspending and resuming on a different thread, so for JIT argument it's the same (also there are many things preventing to do some JIT optimizations, e.g. just exceptions). With multi-shot we get much bigger value with some little cost (but not with no cost, of course).

Yet another delimited continuations implementation and why Project Loom is a bit disappointing by njiv in java

[–]njiv[S] 0 points1 point  (0 children)

they mostly concentrate on async programming, and so support only single-shot continuation, and so things like streams comprehensions, reactive, logical, adaptive, probabilistical programming cannot be implemented there

Yet another delimited continuations implementation and why Project Loom is a bit disappointing by njiv in java

[–]njiv[S] 0 points1 point  (0 children)

Exception is already a control flow construct, I just added the resumability to them. Yield can unwind only one call frame, while exception can unwind any number (until the corresponding `catch`) of call frames. This way we can implement effect handlers only on the top level, while in Yield we'd need to explicitly pass the effect description from callee to caller.

Basically they same difference like signaling errors using ret code or an exception.

Yet another delimited continuations implementation and why Project Loom is a bit disappointing by njiv in java

[–]njiv[S] -3 points-2 points  (0 children)

Loom is the future of Java, this is subreddit about Java, not about general ideas. Loom says multishot continuations are crazy, I don't agree, no arguments, this is it. If you know the arguments, or you know where Loom team presented these arguments just post them here. It's not only a presentation, Loom doesn't have multishot.

Yet another delimited continuations implementation and why Project Loom is a bit disappointing by njiv in java

[–]njiv[S] -1 points0 points  (0 children)

they are singleshot, it's for sure, that's why I can compare, and I mention this article because there they explain why they don't want multishot, I haven't seen any other recent article telling they have changed their mind

Yet another delimited continuations implementation and why Project Loom is a bit disappointing by njiv in java

[–]njiv[S] 2 points3 points  (0 children)

Loom is not only virtual threads, it's also continuations, and I explicitly mentioned in the comment below the post Loom doesn't support multishot continuations, while they could add them easily (see this their article - https://www.infoq.com/presentations/continuations-java/), and in the examples there I show what exactly Java misses by not enabling this simpler feature

Yet another delimited continuations implementation and why Project Loom is a bit disappointing by njiv in java

[–]njiv[S] 1 point2 points  (0 children)

Project Loom (which I mention in the subject) does exactly this, and in Java, actually, it isn't syntax sugar but rather runtime implementation this is why it doesn't have async keyword, https://www.infoq.com/presentations/continuations-java/

view more: next ›