<div dir="ltr"><div><font face="monospace, monospace">Hello Istvan,</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">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.</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">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.</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">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. </font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">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. </font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">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").</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">===</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">Note re my reliance on Crud2 demo</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">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. </font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">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.</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">I think this reliance of mine on the Crud2 demo led to two problems:</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">(a) type errors in all the versions of my code</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">(b) my misguided desire to think about "unboxing" the transaction result.</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">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.</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">===</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">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.</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">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.</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">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.</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">Thank you for trying to specifically address the points where I was getting confused - this has been a big help and encouragement!</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">- Scott</font></div><div><font face="monospace, monospace"><br></font></div><div><br></div></div>