[Ur] obtain signal's value on a server side

[Timothy Beyer]

At Wed, 4 Mar 2015 22:39:21 +0400,
Sergey Mironov wrote:
> 
> 2015-03-04 16:47 GMT+03:00 Adam Chlipala <adamc at csail.mit.edu>:
> > The current compilation strategy just doesn't support signal computation on
> > the server.  Sorry!
> >
> > What's the use case?  Maybe I can talk you out of it. :)
> 
> Well, here is the case:
> 
> I use state monad (xmlw) wrapped around transaction to mix xml
> rendering and transaction actions, for example, to allocate source and
> use it immediately. It opens some possibilities, and one of them is
> the easy signal wiring. I define [mapsig] function like following
> 
> fun mapsig [t1:::Type] [t2:::Type] (s : source t1) (f: t1 -> t2) :
> MT.state xbody (source t2) =
> def <- get_default_value_of s;
> s2 <- lift (source def);
> push_back_xml
>   <xml>
>   <dyn signal={v <- signal s; return <xml><active code={set s2 (f v);
> return <xml/>}/></xml>}/>
>   </xml>;
> return s2
> 
> where [push_back_xml] adds xml snippet to the state which will be
> converted to a page later, and [lift] lifts the transaction action up
> to the xmlw monad. This function would allow me to define some signal
> math in a compact and readable way:
> 
> s1 <-source 1;
> s2 <- mapsig s1 (fn x => x + 3);
> s3 <- mapsig s2 (fn x => float(x) * (pow 10.0 3.0));
> 
> and so on. Unfortunately, we have not got [get_default_value_of] to
> query the s. I tried to use [get] without success, you know the rest.
> 
> 
> Hm. I think I know a workaround now. I can define my own version of
> sources like this:
> 
> datatype sourceDef x = SourceDef of (source x * x)
> 
> fun source v = s <- Basis.source v; return (s*v)
> 
> and then re-define all the default API for them, including [set],
> [get], [current], [signal] plus write an additional [get_def]
> returning the second element of a pair. Having signals defined this
> way makes it possible to call [get_def] in the first line of [mapsig]
> body. I would prefer to weaken restrictions of the [Basis.get] if it
> doesn't break any invariants, but I think I'm also fine with this
> solution.
> 
> Regards,
> Sergey
> 
> _______________________________________________
> Ur mailing list
> Ur at impredicative.com
> http://www.impredicative.com/cgi-bin/mailman/listinfo/ur

This monad sounds really useful, recently I have used a poor workaround for the above.

In my case, I define a function that takes various signals as inputs (with an abbreviation for the "signal" function to save space), and returns signal xbody, but it isn't as concise as I would prefer.  I still write the <dyn signal={fn (signal foo) (signal bar)}/> portion as well.

What I really want to avoid are functions that take sources as arguments unless they mutate that respective argument, which I have managed to do thus far, at the expense of a bit more verbosity.

Regards,
Tim