[Ur] Interplay between the signal monad and the transaction monad

Mon Aug 17 08:14:10 EDT 2015

On 08/17/2015 01:51 AM, Stefan Scott Alexander wrote:
> (1) Can you use a call to `set`, `get` or `rpc` - or `source` or 
> `current` - (all of which return a *transactional* type) on one of the 
> semicolon-separated lines of the code inside the `signal` attribute of 
> a `<dyn>` tag?

No.  These are in the [transaction] monad, which is different from the 
[signal] monad.

> (2) Are the two collections of operations below fundamentally 
> different / Do they have totally different meanings:
>
> (a) the `;` and `return` and `<-` used in the code of the `signal` 
> attribute of a `<dyn>` tag
>
> (b) the `;` and `return` and `<-` used in the code of the `on_` event 
> attribute of a `<ctextbox>`, `<cselect>` etc. tag?

They're the usual overloaded operations of the [monad] type class.

> (3) What I'm kindof getting at here is this more general question:
>
> We have seen "semicolon-separated" code patterns (for monadic 
> syntactic sugar) such as the following, which can occur in various 
> locations:
>
>   ... <- ... ;
>   ... ;
>   return ...
>
> We also know that there are two monads in Ur/Web: the transaction 
> monad and the signal monad.

There are more monads than that just in the standard library, and it's 
always possible to define your own new ones.

> Question: Is it possible / Does it make any sense to "freely mix"
>
> - operations which return "transactional" types (eg: `set`, `get, 
> `rpc` - or `source`, `current`)
>
> - with operations which return "signal" types (eg: the operation 
> `signal` - or also possibly a function called on an argument of type 
> `signal` - see [Note 1] at the end of this message)
>
> within a *single* occurrence of such a "semicolon-separated" code pattern?

No, and for good reasons.  Transactions are allowed to have all sorts of 
side effects, while signals must be pure to make sense.

> (a) what *contexts* they can be used in - eg, either:
>
> - in the `signal` attribute of a `<dyn>` tag, the above code pattern 
> represents a sequence of "signal operations", versus
>
> - in the `on_` event attribute of a `<ctextbox>`, `<cselect>`, 
> `<body>` etc. tag the above code pattern represents a sequence of 
> "transactions";

The type of the context completely determines the answer to your question.

> (b) what *operations* can be used in them - eg:
>
> - in the `signal` attribute of a `<dyn>` tag, the above 
> "semicolon-separated" code pattern would only allow using the 
> operation `signal` (which returns something of type `signal t`) - plus 
> maybe other functions called on a "variable" assigned to a value 
> returned by a previous call to such a `signal` operation (See [Note 1] 
> at the end of this message)
>
> =versus=
>
> - in the `on_` event attribute of a `<ctextbox>`, `<cselect>`, 
> `<body>` etc. tag, the above "semicolon-separated" code pattern would 
> only allow using operations such as `set`, `get`,  `rpc` - or `source` 
> or `current` - all of which return a *transactional* type.

Again, the type of the context completely determines the answer.

>   ls <- signal lss
>
> So it would seem that `ls` is of type `signal t` (according to page 44 
> of the manual).

No, look more carefully at the type of [bind] (which [<-] desugars to).  
Since [signal lss] has some type [signal t], [ls] gets type [t].

P.S.: I think essentially all your questions should be answered by any 
tutorial on monads in Haskell.