IRC channel logs
2024-09-09.log
back to list of logs
<RussetParrotBear>Is there a command to identify the current vat in the repl, like `,which-vat` or similar? <dckc>dpk, "if you don’t like that you can do a prefixing import" yeah, but the rest of the scheme community won't. <dckc>fr33domlover, I expect a method handler can 1) make a promise, 2) make an async call that will later resolve the promise 3) return the promise <dckc>I might have done that myself lately... <dckc>I did it in a couple procedures. I can't imagine the same thing doesn't work in a method handler. <dckc>after all, a method handler is a procedure, IIUC <dthompson>RussetParrotBear: if you use ,enter-vat then the current vat's name is printed in the prompt. <dthompson>fr33domlover: yes it can do something async that will be resolved later. in that case the actor returns a promise. <fr33domlover>Thanks dckc, dthompson. So if I call such a method (using <-) it returns a Promise that resolves to a Promise? ^_^ <dthompson>fr33domlover: no it would resolve to the value within the promise <fr33domlover>dthompson: If I far-call a method that returns a number, I get a promise, right? Which will resolve to a number. So I can do use `on` and decide what do to with the number when I receive it. But if I far-call a method that itself returns a promise-of-a-number - then if I use `on`, doesn't the handler receive a promise-of-a-number? On which again it <fr33domlover>can use `on` and now finally react to the actual number being received? <fr33domlover>f :: Number -> Number | (on (<- f 3.14) (... work with the number ...)) <fr33domlover>f :: Number -> Promise Number | (on (<- f 3.14) (... we got a promise, if we again use `on` we can get the number itself ...)) <dckc>in JS, a Promise<Promise<T>> is indistinguishable from a Promise<T> <dckc>hm. maybe not entirely indistinguishable. But I hope you get the idea. they all collapse. When you await the resolution, you're sure to get something that's not a promise. <dckc>I'm pretty sure (on ...) works the same way <jfred>oh yeah I think I've taken advantage of that a few times but hadn't thought through why it worked that much <dckc>There was a small war fought over collapsing Promise<Promise<T>> to Promise<T>. It breaks the monad laws. <dthompson>might make more sense if you think about the call happening across the network. each side needs their own promise.