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

Mon Aug 17 01:51:30 EDT 2015

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!

###
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.impredicative.com/pipermail/ur/attachments/20150817/a723c223/attachment.html>