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

[Sergey Mironov]

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