IRC channel logs
2026-02-18.log
back to list of logs
<pukkamustard>can an actor become (bcom) something else when handling a promise? <pukkamustard>something like this: (define-actor (^mutate-on-promise bcom) (lambda () (on (<- another-actor) (lambda (value) (bcom (^cell bcom value)))))) <pukkamustard>also, how can I become a read-only cell? `(bcom (cell->read-only (^cell bcom value)))` doesn't seem to work <dthompson>pukkamustard: you cannot become within an on handler <dthompson>reason being that the 'on' handler procedure is *not* a message to the actor your ^mutate-on-promise procedure. it's a message to a promise resolver object. <dthompson>er, not a message to your ^mutate-on-promise actor, I mean. excuse the word salad. <dthompson>pukkamustard: cell->read-only doesn't return new behavior (a new procedure), it spawns a new actor that is a read-only *proxy* to the given cell <tsyesika>theoretically if we exported `^ro-cell` you could do something like `(bcom (^ro-cell bcom val))` but, that'd not work with aurie <pukkamustard>the read-only cell is more of me just playing around with whatever is in the actor-lib. i guess I could re-define a ^ro-cell <dthompson>pukkamustard: looking at the linked code, I'm not sure becoming a read-only cell is the behavior you really want. <dthompson>correct me if I'm wrong: get-read-capability is intended to return a read-only capability to the caller <pukkamustard>yeah, plus the encoder is finalized. in the sense no more data can be fed to it. <dthompson>okay, so the actor should change its behavior to reject all future messages? <dthompson>I thought that's the value you want to return to the caller? <pukkamustard>both :). but i'm really just playing around and trying to get a feeling what is ergonomic. <pukkamustard>i think you are suggesting, return the read-capability and become an actor that does not do anything? <dthompson>I'm not necessarily suggesting it, I was trying to derive the intended interface from you by making some statements and having you tell me how wrong I am :) <dthompson>here's what I think I understand so far: there's an encoder actor. it can do many different things *until* the get-read-capability method is called. <dthompson>after get-read-capability is called, should it be possible to get the read capability again? <dthompson>if so, I'd recommend changing behavior such that only the get-read-capability method works. <dthompson>so you'd spawn the read-only object, return it, and become a new closure that has a reference to that same object <dthompson>pseudocode: (bcom (read-only-behavior read-only-object) read-only-object) <pukkamustard>but the maybe trickier part: how to bcom while handling a promise? <dthompson>because the handler context is not the actor <pukkamustard>the solution is maybe to make the read-only-object a promise <dthompson>yes that's one way to do things. return the *eventual* capability <dthompson>that preserves atomicity. as soon as the get-read-capability method is called, no other methods can be called. <dthompson>if you wait with an 'on' handler, you open yourself up for bugs where get-read-capability or other methods can be called in the meanwhile <dthompson>the actor model affords you the great power of atomicity *within a single turn* <dthompson>(we should run through a bunch of scenarios like this in our docs and give best practice advice) <dthompson>yw! cool to see eris and goblins coming together :)