I apologize in advance if any of these questions are poorly-phrased or ill-defined.
They just involve some general things I've been noticing and pondering while reading code examples involving sources and signals. (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? I haven't seen any examples of the above, so I suspect it is not allowed. The types of these operations are declared on pages 44-45 of the manual: http://www.impredicative.com/ur/manual.pdf (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? (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. 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? (4) In other words, are there actually *two* totally different "versions" of this "semicolon-separated" code pattern: ... <- ... ; ... ; return ... which merely happen to have similar-looking syntax, but which actually have fundamentally different rules and meanings regarding: (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"; (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. --- [Note 1] I'm very curious about these two lines of code: https://github.com/urweb/urweb/blob/master/demo/increment.ur#L8 https://github.com/urweb/urweb/blob/master/demo/batch.ur#L37 especially the second one. The second one calls {show' ls} after calling ls <- signal lss So it would seem that `ls` is of type `signal t` (according to page 44 of the manual). However, the definition of (auxiliary) function `show'` https://github.com/urweb/urweb/blob/master/demo/batch.ur#L23-L33 appears to expect an argument of type `t` (ie, a `Nil` or a `Cons`) - *not* an argument of type `signal t`. 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`. 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! Why does the compiler allow this? My guess is: 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. Thanks for any confirmations or denials of these questions and conjectures! ###
_______________________________________________ Ur mailing list [email protected] http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
