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.
_______________________________________________
Ur mailing list
[email protected]
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
