Thanks for the link! I hacked a rudimentary continuations plugin for ErlyWeb. I wrote about it at http://yarivsblog.com/articles/2008/02/17/seaside-style-programming-in-erlyweb/. I'd love to get people's feedback on it.
Yariv On Feb 15, 2008 8:47 PM, Kevin A. Smith <[EMAIL PROTECTED]> wrote: > > This paper: > > http://siscweb.sourceforge.net/docs/queinnec-inverting.pdf > > helped me have the "aha!" moment using continuations and the web. If > you're comfortable reading Scheme, siscweb has a decent implementation > of continuation-based web programming, too. It might be good source > for ideas. > > --Kevin > > On Feb 13, 2008, at 9:12 PM, jm wrote: > > > > > macrocreation wrote: > >> Yariv, > >> > >> I suggest you have a look at seaside. Continuations not only make the > >> code development easy, but you can suddenly start to develop "true" > >> components and they are straightforwardly embeddable - the complexity > >> of mixing and matching components becomes additive rather the > >> geometric if that makes sense. > > > > This is the argument I've heard in favor of it as well. > > > > The bit that made the most sense to me why you'd want to do this is > > not > > the reduction in code size (I don't think there is), but the ability > > to > > think and code dirictly in a process flow manner instead of a finite > > state machine's transitions. FSMs cause problems as they grow larger > > and > > more complex as it gets harder to fit it all in one's head at the > > sametime. > > > > Consider this bad ASCII art, adopted from "Inverting back the > > inversion > > of control or, Continuations versus page-centric programming" > > > > get post post > > ----->[get num1]----->[get num2]---->[display num1 + num2] > > > > > > using the current erlyweb we'd have something like, ignoring error > > cases, > > > > -module(traditional) > > > > > > add(A) -> > > case Method of > > 'GET' -> > > generate_num1_form(A); > > 'POST' -> > > F = get_fields_from_form(A), > > %% uses client to store num1 as hidden field in 2nd form > > case proplists:lookup(num1, F) of > > none -> {ewr, traditional, add}; > > N1 -> case proplists:lookup(num2) of > > none -> generate_num2_form(A, N1); > > N2 -> generate_sum_page(A, N1, N2) > > end > > end > > end. > > > > > > What would this look like in an Erlang/Erlyweb with continuation? I'll > > leave this for someone else as this what I'm trying to work out. In > > psuedo code > > > > add(A) -> > > N1 = get_num1(A), > > N2 = get_num2(A), > > generate_sum_page(A, N1, N2). > > > > > > get_num1(A) -> > > generate_num1_form(A), > > break/resume > > F = get_fields_from_form(A), > > proplists:lookup(num1, F). > > > > > > get_num2(A) -> > > generate_num2_form(A), > > break/resume > > F = get_fields_from_form(A), > > proplists:lookup(num2, F). > > > > > > which is really just the previous code turned inside out. The bit I'm > > stumbling on at the moment is error control and branching of flow > > (case/if) and how it fits into this. > > > > Regardless, I can't understand why continuations would use so much > > memory. The only things I can think of are > > 1) The estimate I heard was wrong. > > 2) The estimate I heard was for large applications > > 3) This is due to saving the full stack for each call (post/get) and > > then keeping the old stacks around for a long time. > > > > I keep seeing not stacks but changes in state forming a tree of > > changes. > > ie, erlyweb taking snapshots of the values of functions at the > > break/resume points but not the entire stack and these for the node > > of a > > state tree in time. > > > > Lasty, thanks to [EMAIL PROTECTED] for recommending a couple of > > papers > > I'm only half through the first one as I'm not formilar with scheme. > > In > > searching I also found this archived message which seems to indicate > > some relevent papers, > > > > http://www.cs.brown.edu/pipermail/plt-scheme/2007-April/017628.html > > > > Jeff. > > > >> I can't explain the gist of my argument - its one of those matrix > >> things - when it sinks in you go "Wow!". > >> > >> Why am I still programming in erlang? I really like the scalability > >> and a lot of my applications need lots of concurrent processes. > >> > >> I have been told any system that supports first class function > >> objects > >> with lexical closure is able to support continuation passing style > >> - I > >> think it would even be easier with erlang considering you don't have > >> to worry about variable mutations and the like. > >> > >> hafeez > >> > >> > >> On Feb 13, 8:32 pm, "Yariv Sadan" <[EMAIL PROTECTED]> wrote: > >>> Dang, I actually realized I just overlooked something big: my > >>> examples > >>> didn't use real closures -- just anonymous functions. With framework > >>> support, those functions could be used as closures and their > >>> environment data could be accessible in subsequent actions without > >>> the > >>> controller's using the session store explicitly. I should have > >>> thought > >>> a bit harder before voicing my skepticism :) (However, I believe > >>> some > >>> of the disadvantages I listed still hold true.) > >>> > >>> Yariv > >>> > >>> On Feb 12, 2008 10:35 PM, Yariv Sadan <[EMAIL PROTECTED]> wrote: > >>> > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "erlyweb" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/erlyweb?hl=en -~----------~----~----~----~------~----~------~--~---
