[Ur] rpc calls from signals?

[Daniel Patterson]

I was kind of expecting that, but I do think it is a common thing and
so probably useful to support in some way (though probably best done
somewhat separately).

The main reason I wanted to have them connected is to re-use the
runtime checks that are looking for changes - having a check running
every N milliseconds seems really pointless when the javascript
runtime already knows when values are changing.

Would there be a way to set up an event listener for changes on a
source? I can obviously create a "changed" source for each source I
have, and then flip it on when the source changes, and off in the
thread that is making rpc calls, but ideally that thread wouldn't even
be woken up unless the change had happened. Though maybe I'm bean
counting given how fast even phones are these days... (and indeed I'm
only concerned about phones, and primarily for the sake of battery
life, not responsiveness).

On Mon, Mar 11, 2013 at 10:47 AM, Adam Chlipala <adamc at csail.mit.edu> wrote:
> On 03/11/2013 10:20 AM, Daniel Patterson wrote:
>>
>> Is there a way to call remote procedures in signal handlers? I looked
>> through the manual and basis.urs and couldn't find anything.
>>
>> The use case isn't particularly strange: I want to persist client side
>> changes on the server, ideally only making rpc calls when something actually
>> changes. I can spawn a thread that checks periodically if the value has
>> changed (that's what I ended up hacking together), but at that point I'm
>> replicating imperatively what FRP is supposed to eliminate!
>
>
> I would actually consider it a bug if what you ask were possible!  The
> [signal] monad is meant to rule out side effects, and RPCs can cause
> arbitrary side effects, not just locally but out in the real world.  There
> would need to be some kind of type system, etc., to recognize RPCs that are
> suitably pure.  Imagine the consequences of the "launch missile" RPC running
> every time the runtime system decides that some DOM subtree needs
> recomputation. ;)
>
> Why not implement a general library for change listeners?  Certainly there
> is some duplication with FRP, but at the same time I would expect it's
> pretty straightforward to implement.  You could create a new abstract type
> that encapsulates a [source] plus change listeners.