[Ur] rpc calls from signals?

[Karn Kallio]

I think the GUI library has something that might suit your case.  The 
sourceL.ur and sourceL.urs listed here:

http://hg.impredicative.com/gui/file/d32fb0f7b137

I think implement the change listener Adam mentioned.



> 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.
> 
> _______________________________________________
> Ur mailing list
> Ur at impredicative.com
> http://www.impredicative.com/cgi-bin/mailman/listinfo/ur