[Ur] Function `queryL1` returns type `transaction (list $fs)` - How can I get the `list $fs` part and pass it to `List.mapX` - which expects type `list`?

[Stefan Scott Alexander]

Hello Istvan,

Thank you for this helpful overview of monadic transactions in general and
in Ur/Web. There are many explanations of monads all over the web, and I
appreciate you taking the time provide one here which is a bit more adapted
to the conceptual and syntactical errors in my previous coding attempts,
and to the specifics of my use case involving using SQL to generate an XML
widget.

In particular, your recommendation to look at the Sql demo is very helpful.
I had been focusing more on the Crud demos (in particular the Crud2 demo -
because it had a very simple data-bound Widget), but reviewing the Sql demo
I see that it has several pertinent examples of "running" an SQL
transaction to build some XML which might be more useful in this case.

I have read a bunch of monad tutorials for Haskell over the past year or
so, mainly as background to try to learn Ur/Web, and [return] was always
pretty straightforward, while the sort of "piping" performed by the [bind]
was something that I would just barely grasp and then it would slip away
from my understanding again - a few days after reading it, the concepts
would be completely gone from my memory again.

Your reminder that in most cases "unboxing" can never be done is helpful,
and your specific example of taking the output from SQL to use to build XML
is also very helpful.

Also presenting the signature of [bind] is very helpful, reminding me of
how t1 and t2 are never really "exposed" on their own (although somehow
behind the scenes [bind] manages to provide a t1 for input to the function
in the "middle").

===

Note re my reliance on Crud2 demo

I think that there is also a specific, probably unsatisfiable requirement
due to my decision to base my data-bound <select> widget code directly on
the Crud2 demo. I did this because Crud2 already had a (kind of) data-bound
<select> widget, so I figured it could serve as a basis.

But the Widget in the Crud demo has only two, pre-established values: True
and False, which the function Show converted to "Ready!" and "Not Ready" -
ie, the Crud2 demo builds the <select> widget based on data which exists
without the need to "run" a transaction! It just the two pre-existing,
pre-known values True or False, which can be obtained and used to built the
widget *without* using a transaction. So the signature for the
Widget-building function in the Crud2 does not use / accept a transactional
type - and so all my attempts to jam transactional values into there didn't
work.

I think this reliance of mine on the Crud2 demo led to two problems:

(a) type errors in all the versions of my code

(b) my misguided desire to think about "unboxing" the transaction result.

Now I see that I will probably have to alter the signature of the
Widget-building function so that it uses a transaction. Intuitively, this
makes sense to me now: The contents of the Widget are, after all,
determined by an SQL SELECT transaction, so the signature of the
Widget-building function really should use a transactional type.

===

Your reminder to look at the Sql demo is very helpful in this regard, since
it has several examples of SQL SELECT transactions being "run" and then the
results being used to build some XML - similar to what I'm trying to do to
build a data-bound <select> widget.

Finally you also covered several other important points, reminding me of
the correspondence between the [bind] function and the syntactic sugar
involving [<-] and [;], reminding me to rely more on the [bind] form for
understanding, and clarifying the "pipelining" going on. I have read this
stuff over and over in various monad tutorials, but hearing it applied to
the specific case of taking the transaction resulting from the SQL call and
using its output to create a second transaction that will output some XML -
the concreteness of hearing it stated this way helps me to get a better
understanding of what needs to be done.

I'm going to study the Sql demo more now, and think about how the SQL is
used to build the XML using transactions, and see how this could be applied
to the case of generating the individual <option> elements of a data-bound
<select> element.

Thank you for trying to specifically address the points where I was getting
confused - this has been a big help and encouragement!

- Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.impredicative.com/pipermail/ur/attachments/20150720/9e5a6f9f/attachment-0001.html>