
<div dir="ltr"><div>I apologize in advance if any of these questions are poorly-phrased or ill-defined. </div><div><br></div><div>They just involve some general things I've been noticing and pondering while reading code examples involving sources and signals.</div><div><br></div><div><br></div><div>(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?</div><div><br></div><div>I haven't seen any examples of the above, so I suspect it is not allowed.</div><div><br></div><div><div>The types of these operations are declared on pages 44-45 of the manual: <a href="http://www.impredicative.com/ur/manual.pdf">http://www.impredicative.com/ur/manual.pdf</a> </div></div><div><br></div><div><br></div><div>(2) Are the two collections of operations below fundamentally different / Do they have totally different meanings:</div><div><br></div><div>(a) the `;` and `return` and `<-` used in the code of the `signal` attribute of a `<dyn>` tag </div><div><br></div><div>(b) the `;` and `return` and `<-` used in the code of the `on_` event attribute of a `<ctextbox>`, `<cselect>` etc. tag?</div><div><br></div><div><br></div><div>(3) What I'm kindof getting at here is this more general question: </div><div><br></div><div>We have seen "semicolon-separated" code patterns (for monadic syntactic sugar) such as the following, which can occur in various locations:</div><div><br></div><div>  ... <- ... ;</div><div>  ... ;</div><div>  return ...</div><div><br></div><div>We also know that there are two monads in Ur/Web: the transaction monad and the signal monad.</div><div><br></div><div>Question: Is it possible / Does it make any sense to "freely mix"</div><div><br></div><div>- operations which return "transactional" types (eg: `set`, `get, `rpc` - or `source`, `current`) </div><div><br></div><div>- 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) </div><div><br></div><div>within a *single* occurrence of such a "semicolon-separated" code pattern?</div><div><br></div><div><br></div><div>(4) In other words, are there actually *two* totally different "versions" of this "semicolon-separated" code pattern:</div><div><br></div><div>  ... <- ... ;</div><div>  ... ;</div><div>  return ...</div><div><br></div><div>which merely happen to have similar-looking syntax, but which actually have fundamentally different rules and meanings regarding:</div><div><br></div><div>(a) what *contexts* they can be used in - eg, either:</div><div><br></div><div>- in the `signal` attribute of a `<dyn>` tag, the above code pattern represents a sequence of "signal operations", versus</div><div><br></div><div>- in the `on_` event attribute of a `<ctextbox>`, `<cselect>`, `<body>` etc. tag the above code pattern represents a sequence of "transactions";</div><div><br></div><div>(b) what *operations* can be used in them - eg:</div><div><br></div><div>- 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)</div><div><br></div><div>=versus=</div><div><br></div><div>- 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.</div><div><br></div><div>---</div><div><br></div><div>[Note 1]</div><div><br></div><div>I'm very curious about these two lines of code:</div><div><br></div><div>  <a href="https://github.com/urweb/urweb/blob/master/demo/increment.ur#L8">https://github.com/urweb/urweb/blob/master/demo/increment.ur#L8</a></div><div><br></div><div>  <a href="https://github.com/urweb/urweb/blob/master/demo/batch.ur#L37">https://github.com/urweb/urweb/blob/master/demo/batch.ur#L37</a></div><div><br></div><div>especially the second one.</div><div><br></div><div>The second one calls </div><div><br></div><div>  {show' ls}</div><div><br></div><div>after calling</div><div><br></div><div>  ls <- signal lss</div><div><br></div><div>So it would seem that `ls` is of type `signal t` (according to page 44 of the manual).</div><div><br></div><div>However, the definition of (auxiliary) function `show'` </div><div><br></div><div>  <a href="https://github.com/urweb/urweb/blob/master/demo/batch.ur#L23-L33">https://github.com/urweb/urweb/blob/master/demo/batch.ur#L23-L33</a></div><div><br></div><div>appears to expect an argument of type `t` (ie, a `Nil` or a `Cons`) - *not* an argument of type `signal t`.</div><div><br></div><div>Usually the compiler is very picky about types - it complains if you give it a value of type `transaction xml` when it was expecting a type of `xml`. </div><div><br></div><div>But here we have a function which expects a value which is apparently of type `t` (eg `Nil` or `Cons`) being called on an argument of type `signal t` - and the code compiles and runs fine!</div><div><br></div><div>Why does the compiler allow this? </div><div><br></div><div>My guess is: </div><div><br></div><div>Such a call is *only* allowed within a "semicolon-separated" code pattern of the "signal" type - ie, inside the code of the `signal` attribute of a `<dyn>` tag.</div><div><br></div><div><br></div><div>Thanks for any confirmations or denials of these questions and conjectures!</div><div><br></div><div>###</div><div><br></div><div> </div></div>