On Wed, Feb 16, 2005 at 04:33:29AM +0000, John Goerzen wrote:

On a related note, Wash seems to be preserving all sorts of unnecessary "state" from previous screens a user visited.

You do know that the current version of WASH rebuilds the continuation by repeating all the previous steps, don't you? Until WASH can keep the continuations on the server, it will have to pass all those parameters. This is necessary.

I don't understand why it doesn't pass only the parameters to the next screen; that should be easily determined to be all that is necessary.

It would be, I there was a server-side continuation store. Perhaps you don't see the whole power of continuation based approach to web programming. I will give you an example - when I use WASH, I often pass first-class functions to from screen to screen, for example as a way of telling the screen what to do next (a continuation), or as the most convenient way to do something. It would be quite difficult to pass those functions as form parameters, so they are being rebuilt each time from the log.

On that same topic, I've used Wash's unsafe_io some places with no ill effects.

Are you sure your IO actions will always yield the same result? If so, the you can safely use unsafe_io. Otherwise you should let was save the result of them in the log by using io.

(Note that this has no relationship to unsafePerformIO, which is a different beast entirely.) Can anyone tell me why unsafe_io in Wash is unsafe, and in which situations it could blow up in my face?

If you I actions can give different results when called for the second, third, ..., nth time. Best regards Tomasz -- Szukamy programisty C++ i Haskell'a: http://tinyurl.com/5mw4e

On Wed, Feb 16, 2005 at 07:16:50AM +0100, Tomasz Zielonka wrote:

On Wed, Feb 16, 2005 at 04:33:29AM +0000, John Goerzen wrote:

...

On a related note, Wash seems to be preserving all sorts of unnecessary "state" from previous screens a user visited.

You do know that the current version of WASH rebuilds the continuation by repeating all the previous steps, don't you? Until WASH can keep the

Yes. What I don't understand is why. If I have a submit button, and it is passing one value to the next function, and that value is from an entry form on the screen, why would I care about all the previous state? That's my confusion. It seems unnecessary.

Perhaps you don't see the whole power of continuation based approach to web programming. I will give you an example - when I use WASH, I often pass first-class functions to from screen to screen, for example as a way of telling the screen what to do next (a continuation), or as the most convenient way to do something. It would be quite difficult to pass those functions as form parameters, so they are being rebuilt each time from the log.

Yeah, that's a neat feature. I'm using it some places, too. It's probably true that I don't understand fully how to exploit it yet. (I wish that I could return something other than () from a screen too.) I just want a way to pass only what I need. Passing lots of stuff is going to make my applications painful for modem users, which unfortnuately make up a large part of the user base.

Are you sure your IO actions will always yield the same result? If so, the you can safely use unsafe_io. Otherwise you should let was save the result of them in the log by using io.

Excellent, thanks. -- John

On Wed, Feb 16, 2005 at 08:27:31AM -0600, John Goerzen wrote:

...

You do know that the current version of WASH rebuilds the continuation by repeating all the previous steps, don't you? Until WASH can keep the

Yes. What I don't understand is why. If I have a submit button, and it is passing one value to the next function, and that value is from an entry form on the screen, why would I care about all the previous state? That's my confusion. It seems unnecessary.

That's the simplest way to rebuild the state of the process if you can't leave anything on the server (like a process or a continuation).

Yeah, that's a neat feature. I'm using it some places, too. It's probably true that I don't understand fully how to exploit it yet. (I wish that I could return something other than () from a screen too.) I just want a way to pass only what I need. Passing lots of stuff is going to make my applications painful for modem users, which unfortnuately make up a large part of the user base.

You can, you just have to use the continuation passing style. For example, if you want screen to return a value of type LotsOfStuff, you instead create a function that takes the continuation as parameter: screen :: (LotsOfStuff -> CGI ()) -> CGI () screen cont = do ask $ do ... submit ... f ... where f (F4 a b c d) = ... let stuff = ... cont stuff Of course, you have to call it appropriately: otherScreen = do .. screen (\stuff -> ...) See my contributed WASH example. It's not on the WASH website yet, probably because it requires some changes in the library. It should be easy to make it work with the current WASH release - just import CGI instead of GuaranteedCGI, and fix the types involving WithHTML. I can do this, if you're interested. You can also test the app at this address http://212.186.92.25/~tomek/TreeEdit.cgi It should be available from 08:00 to 24:00 CET. I would like to hear what you think - both about the code and the app. Best regards Tomasz -- Szukamy programisty C++ i Haskell'a: http://tinyurl.com/5mw4e

On Thu, Feb 17, 2005 at 08:06:51PM +0000, John Goerzen wrote:

On 2005-02-16, Tomasz Zielonka wrote:

...

example, if you want screen to return a value of type LotsOfStuff, you instead create a function that takes the continuation as parameter:

I think I get it. The log for the "stuff" need never escape the continuation, right?

...

See my contributed WASH example. It's not on the WASH website yet, probably because it requires some changes in the library. It should

Where can I find the source? It does sound interesting.

I attached it to one of my messages. Perhaps it was removed by some overzealous anti-virus program? Check in the mailing list archives: http://www.haskell.org//pipermail/haskell-cafe/2005-February/009152.html Best regards Tomasz -- Szukamy programisty C++ i Haskell'a: http://tinyurl.com/5mw4e

On Wed, Feb 16, 2005 at 07:31:07AM +0100, Tomasz Zielonka wrote:

...

verbatim. Any ideas?

I have never used table_io. maybe there's a bug in it. Hmmm, it seems to be conceptually wrong. The single purpose of table_io seems to be to avoid keeping the result of an IO action in the log. But how is WASH going to recreate it when it's needed again as in your example?

Ahh, I think I understand what you're saying... table_io is not supposed to be unsafe; that is, it should work without saving data in the log even if the input would be different on a different session. But yes, if the validation fails, there would be no way to do that save re-reading the input. It sounds like, in my case, unsafe_io would be better. My input should never change across a single session. The next question is this: the I/O really only needs to be done once. Once the user has selected an item, that's enough. If my understanding is correct, on each subsequent screen in my application, Wash will follow through the entire call history, and will run the I/O again even if not needed. Is that correct? Or does the unsafe_io prevent that? Thanks for all your help. I appreciate it and apologize for being so dense about Wash. -- John